Deployment and bypass prevention

A policy boundary only works when callers cannot go around it.

Place the selected enforcement surface in the real data path, keep credentials close to the workload, and use network and secret controls to make the protected route authoritative.

Get early access
Review the security model →

Why this exists

The protected endpoint must become the only usable endpoint

A proxy can make precise decisions on every request it receives and still provide no security if the same caller retains a direct PostgreSQL DSN, a Supabase service_role key, or another unrestricted database tool.

Deployment therefore combines Safe Boundary routing with ordinary infrastructure controls: separate administrative access, restrict network egress, remove broad credentials from constrained workloads, and test that direct paths are actually unreachable.

What it does

Concrete controls, stated precisely.

01

Local data path

Run wire and REST enforcement near PostgreSQL, while the MCP package runs beside the AI client and connects directly.

02

Authorization preserved

Use PostgreSQL passthrough roles or forwarded Supabase JWTs so upstream grants and RLS remain authoritative.

03

Explicit bypass closure

Make direct endpoints and credentials unavailable to the applications, agents, or people governed by the boundary.

How it works

A visible enforcement sequence.

  1. 1

    Separate callers

    Distinguish constrained application and AI paths from controlled administrative access.

  2. 2

    Place the surface

    Deploy wire, MCP, or REST enforcement where the selected caller actually sends requests.

  3. 3

    Remove alternatives

    Rotate direct credentials and restrict DNS, network, secret, and tool configuration.

  4. 4

    Test bypass

    Attempt direct PostgreSQL and Supabase access from the constrained workload environment.

Protected when

  • ✓Callers whose only usable data route crosses Safe Boundary
  • ✓PostgreSQL and PostgREST traffic covered by the selected surface
  • ✓Credentials and query results kept within the chosen deployment boundary

Important boundaries

  • —Safe Boundary does not configure firewalls, secret stores, or workload egress automatically
  • —Administrative access needs its own strong identity, approval, and audit controls
  • —Availability and scaling remain responsibilities of the chosen deployment architecture

Continue the story

Related Safe Boundary pages

Security model →

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

Observe to enforce →

Measure policy decisions on representative traffic before activating enforcement.

Architecture →

See how the three enforcement surfaces share policy and audit semantics.

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