PostgreSQL wire
Relays authentication, preserves the upstream role by default, blocks unsafe statements, and rewrites eligible reads for masking.
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.
Protocol-aware architectureEach access path reaches the same policy intent
Local deploymentWIRE PROXY
LOCAL MCP
REST FILTER
Shared policy modelSurface-specific controls
SHARED POLICY
POSTGRESQLWhy 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.
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.
Supabase REST
Forwards JWT and apikey headers, preserves upstream RLS, masks JSON or CSV, and blocks leaky filters on protected columns.
How it fits
Choose the path that matches the caller.
The policy intent is shared, but the evidence and bypass conditions are surface-specific.
| Decision | PostgreSQL wire | MCP server | Supabase REST |
|---|---|---|---|
| Best for | Apps, ORMs, psql, BI tools | Local AI tool calls | Browser and service HTTP clients |
| Identity available | Upstream database role | Local agent metadata plus database auth | Forwarded JWT/apikey and selected role |
| Distinct boundary | TLS termination and direct DB URLs | Process-local budgets and labels | Original PostgREST URL and other Supabase products |
How it works
A visible enforcement sequence.
Route
Point the client at the appropriate Safe Boundary endpoint.
Parse
Interpret SQL or PostgREST structure instead of relying on regex.
Enforce
Block, mask, or observe according to configured policy.
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 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.