Architecture

Three protected paths. One policy model.

Safe Boundary places enforcement in the data path you choose: a PostgreSQL wire proxy, a local MCP server, or an HTTP filter in front of Supabase PostgREST.

Get early access
Review the security model →

Why this exists

The enforcement point stays close to the data

The wire proxy and HTTP filter run in infrastructure you control. The MCP package runs locally and connects directly to PostgreSQL. Query text and results do not need to traverse a Spectral Core-hosted data path.

Each surface parses the request before execution, applies configured masking and blocking policy, and emits a compatible audit record. The protocol mechanics differ, but the security intent remains consistent.

What it does

Concrete controls, stated precisely.

01

PostgreSQL wire

Relays authentication, preserves the upstream role by default, blocks unsafe statements, and rewrites eligible reads for masking.

02

MCP tool path

Runs as a local stdio server, applies read-only and masking policy, denies dangerous functions, and bounds returned rows and bytes per session.

03

Supabase REST

Forwards JWT and apikey headers, preserves upstream RLS, masks JSON or CSV, and blocks leaky filters on protected columns.

How it works

A visible enforcement sequence.

  1. 1

    Route

    Point the client at the appropriate Safe Boundary endpoint.

  2. 2

    Parse

    Interpret SQL or PostgREST structure instead of relying on regex.

  3. 3

    Enforce

    Block, mask, or observe according to configured policy.

  4. 4

    Record

    Write the decision and available attribution into the shared audit shape.

Protected when

  • ✓Traffic explicitly routed through a Safe Boundary surface
  • ✓Configured sensitive columns and supported response shapes
  • ✓Read paths covered by the PostgreSQL, MCP, or PostgREST parser

Important boundaries

  • —Direct database and Supabase URLs remain bypass paths unless deployment prevents their use
  • —MCP agent names are attribution metadata, not verified workload identity
  • —Policy is currently deployment-wide rather than a signed per-workload bundle

Continue the story

Related Safe Boundary pages

Why Safe Boundary →

See why database permissions alone do not govern every AI-era data path.

Security model →

Understand trust boundaries, credentials, identity, and bypass conditions.

Deployment and bypass prevention →

Route constrained callers through the boundary and close direct access paths.

Test the boundary on a real access path.

Start in observe mode, validate the policy against representative traffic, and move to enforcement with explicit bypass controls.

Get early access