Safe defaults
Enforce mode blocks non-read-only or unparseable SQL, denies dangerous functions, masks configured output, and fails closed on unsafe protected shapes.
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.
Security modelEnforce the routed path. Close the bypass.
Fail closedPARSED REQUEST→AVAILABLE IDENTITY→CURRENT POLICY→ Decision pointAllow · block · fail closed
ALLOW
BLOCK
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.
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.
Honest identity provenance
PostgreSQL roles, SSO certificates, Supabase JWTs, and MCP labels retain distinct meanings in the product story and audit.
Trust model
Know which control belongs to which layer.
| Decision | Safe Boundary enforces | Your infrastructure enforces | Not current |
|---|---|---|---|
| Examples | Parsed read-only decisions, configured masks, dangerous-function denial | Routing, private endpoints, egress, secret distribution | Universal workload identity, durable quotas, signed per-workload policy |
| Operator action | Review policy outcomes and fail-closed cases | Remove direct credentials and test bypasses | Do not describe roadmap controls as product guarantees |
How it works
A visible enforcement sequence.
Map
Inventory every direct and indirect path to PostgreSQL data.
Route
Put each constrained caller through the matching enforcement surface.
Close
Remove direct credentials and enforce network egress and endpoint restrictions.
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 and validate the policy against representative traffic before you enforce it. That gives the team evidence for each decision, along with explicit bypass controls for the cases that need a deliberate exception.