Upstream PostgreSQL identity
Passthrough keeps the database role and its grants and RLS semantics intact.
Identity and access
Use the identity each surface can prove.
Safe Boundary does not pretend every label is authenticated identity. PostgreSQL roles, SSO client certificates, Supabase JWTs, and MCP attribution each come from a different trust path.
Identity provenanceKeep authentication separate from attribution
Provenance keptPG ROLE · UPSTREAMJWT · POSTGRESTMCP LABEL · LOCAL
Policy contextAuth ≠ attribution
BOUND TOAUDIT SUBJECT
SOURCE
Why this exists
One audit shape, several identity strengths
On default wire passthrough, PostgreSQL authenticates the user and Safe Boundary preserves the role. Optional SSO requires a Safe Boundary-issued mTLS certificate. On REST, PostgREST validates the forwarded JWT. On MCP, agent fields are supplied by local configuration.
A useful audit record says what it knows and how it knows it rather than labelling every caller “verified.”
What it does
Concrete controls, stated precisely.
Verified human session
SAML or OIDC can issue an identity-bearing certificate that the proxy verifies with mTLS.
Agent attribution
MCP records a configured agent ID and environment, but this is not cryptographic workload authentication.
Identity comparison
Do not collapse different identity strengths into one label.
| Decision | Wire role | SSO certificate | JWT | MCP label |
|---|---|---|---|---|
| Established by | PostgreSQL auth | Safe Boundary CA after IdP flow | PostgREST / Supabase auth | Local environment configuration |
| What it proves here | Database role | Verified human proxy session | Forwarded HTTP subject | Useful attribution only |
How it works
A visible enforcement sequence.
Choose
Identify whether the caller uses wire, MCP, or PostgREST.
Preserve or verify
Retain upstream identity or enable the applicable verified path.
Enforce
Apply deployment policy to the routed request.
Label honestly
Record identity provenance with the decision.
Protected when
- ✓PostgreSQL role preservation in passthrough mode
- ✓Optional human mTLS sessions
- ✓Consistent attribution fields in audit events
Important boundaries
- •No universal per-agent or per-application identity plane today
- •Agent registration does not authorize database access
- •Per-identity signed policy and durable workload sessions remain future hardening
Continue the story
Related Safe Boundary pages
Human SSO →
The verified human identity path.
Agent attribution →
The current MCP attribution model.
Security model →
Understand trust boundaries, credentials, identity, and bypass conditions.
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.