Security model

A strong boundary needs a closed bypass path.

Safe Boundary is a zero-trust-aligned enforcement layer: it makes explicit decisions on routed requests and fails closed in enforce mode. It is not yet a product-wide zero-trust identity and policy system.

Get early access
Review the security model →

Why this exists

Separate enforced controls from deployment guarantees

The current product provides safe defaults: read-only classification, configured masking, dangerous-function denial, inference protection, RLS-safe passthrough, and structured audit. Optional human SSO adds verified certificate identity on the wire path.

Zero trust requires more than a proxy. Direct endpoints must be unreachable to constrained callers, every workload needs verified and revocable identity, credentials must be short-lived, policy must be workload-scoped and versioned, and audit and usage controls must persist across processes. Some of that remains roadmap work.

What it does

Concrete controls, stated precisely.

01

Safe defaults

Enforce mode blocks non-read-only or unparseable SQL, denies dangerous functions, masks configured output, and fails closed on unsafe protected shapes.

02

Credential locality

Wire passthrough does not hold the database password on the live path; MCP connects locally; REST forwards the caller’s JWT to PostgREST.

03

Honest identity provenance

PostgreSQL roles, SSO certificates, Supabase JWTs, and MCP labels retain distinct meanings in the product story and audit.

How it works

A visible enforcement sequence.

  1. 1

    Map

    Inventory every direct and indirect path to PostgreSQL data.

  2. 2

    Route

    Put each constrained caller through the matching enforcement surface.

  3. 3

    Close

    Remove direct credentials and enforce network egress and endpoint restrictions.

  4. 4

    Verify

    Test identity, policy, revocation, logging, and bypass behavior as one system.

Protected when

  • ✓Routed requests on supported wire, MCP, and PostgREST paths
  • ✓Configured fields and structurally unsafe queries
  • ✓Optional human sessions that require Safe Boundary-issued mTLS certificates

Important boundaries

  • —MCP workload identity and database credentials are not yet cryptographically bound
  • —Per-workload signed policy, durable quotas, and universal revocation are not current features
  • —Availability, retention, key management, and bypass prevention depend on deployment design

Continue the story

Related Safe Boundary pages

Deployment and bypass prevention →

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

Why Safe Boundary →

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

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