Bounded PostgreSQL access.
For AI tools, applications, and web APIs.
Apply one set of access rules to AI tools, PostgreSQL connections, and Supabase APIs. Check each request that passes through the boundary, hide configured fields, stop unsafe SQL, keep Supabase's existing row-level permissions where available, and record what each path can establish about the caller.
POSTGRESQLThe problem
AI created new routes to production data.
A careful PostgreSQL role is not enough when an agent can call a different MCP server, a backend holds a broad database credential, or a Supabase client can query protected columns through PostgREST.
Safe Boundary gives each path an enforcement point before data reaches the caller. It complements database grants and RLS; it does not replace them or pretend every caller has verified identity.
Three access paths
Protect the protocol the caller actually uses.
Application SQL
PostgreSQL wire proxy
For ORMs, backend services, psql, BI tools, and other PostgreSQL clients.
APP → PROXY → POSTGRESQL
See this path →
Agent tools
Local MCP server
For AI clients that need query and schema-description tools without an administrative MCP surface.
AI CLIENT → MCP → POSTGRESQL
See this path →
Supabase clients
PostgREST filter
For supabase-js and REST callers that must keep JWT-driven RLS while masking protected values.
CLIENT → FILTER → POSTGREST
See this path →
Not sure where to start? Map the caller’s actual protocol first, then review its specific boundary and bypass conditions.
Policy controls
Do less at the database. Reveal less to the caller.
Read-only enforcement
Parse the statement, block non-read-only SQL and fail closed on input that cannot be classified safely.
Learn more →
Schema-aware masking
Map output to configured catalog columns and return type-compatible masked values.
Learn more →
Dangerous-function denial
Refuse known file, large-object, and cross-database escape functions even inside read-like SQL.
Learn more →
Inference protection
Stop PostgREST filters, sorting, ranges, search, and aggregates from revealing masked values indirectly.
Learn more →
Rollout
Observe first. Enforce with evidence.
The boundary only works when the protected caller cannot go around it. Deployment and credential design are part of the security story, not an afterthought.
Map every path
Inventory database DSNs, Supabase REST URLs, service_role keys, and MCP tools.
Observe real traffic
Forward unchanged requests while recording would-block and would-mask decisions.
Enforce policy
Activate blocking and masking after representative clients pass validation.
Close bypasses
Remove direct credentials and restrict network paths so constrained callers cannot go around the boundary.
Safe defaults today
Zero-trust-aligned enforcement.
Read-only classification, configured masking, dangerous-function denial, inference protection, RLS-safe passthrough, and structured audit are implemented controls. Human SSO can add verified mTLS identity on the wire path.
Do not overclaim
Not yet universal zero trust.
MCP agent labels are attribution rather than verified workload credentials. Policy is not yet signed per workload, quotas are not durable across processes, and direct endpoints must be closed through deployment controls.
Read the security model →Early access
Start with one real PostgreSQL access path.
Validate client compatibility and policy in observe mode, then enforce with explicit bypass controls. Public packaging is still being validated with design partners.