Many think that granting an AI‑driven MCP server direct credentials to Postgres automatically satisfies SOC 2, but the audit trail disappears the moment the server talks to the database.
In reality, SOC 2 demands verifiable evidence that every data request is tied to a specific identity, that the request was authorized, and that the response was handled according to confidentiality rules. Auditors look for immutable logs, approval records, and proof that sensitive fields were protected during transit. Without a controlled access point, an MCP server can read or write rows, execute arbitrary SQL, and leave no trace that links the action to a user or a policy decision.
Most organizations deploy MCP (Model‑Control‑Process) servers as a convenience layer for internal tools. The typical pattern is a static database user stored in the server’s configuration, a long‑lived connection pool, and unrestricted network reach to the Postgres instance. This setup satisfies the immediate need for speed, but it violates several SOC 2 trust‑service criteria: the server knows the credential, there is no real‑time approval workflow, and the database cannot prove who initiated a query.
Even when teams adopt modern identity providers, issuing OIDC tokens to the MCP server, enforcing least‑privilege IAM roles, and rotating secrets, the request still travels directly to Postgres. The gateway that could enforce policy lives outside the server process, yet the traffic bypasses any enforcement layer. Consequently, the organization still lacks a single source of truth for who accessed which rows, when the access occurred, and whether any sensitive columns were masked.
Enter hoop.dev, an open‑source Layer 7 gateway that sits in the data path between the MCP server and Postgres. hoop.dev verifies the OIDC token presented by the MCP server, maps the token to a scoped identity, and then proxies the SQL traffic. Because the gateway is the only point where the query is inspected, it can enforce just‑in‑time approvals, block disallowed statements, mask confidential columns in real time, and record the entire session for replay.
How hoop.dev satisfies SOC 2 evidence requirements
Security – logical access controls: hoop.dev records the identity that initiated each connection, the exact timestamp, and the set of permissions granted for that session. Auditors can query the log to see that only authorized roles accessed the database.
Processing integrity – assurance of correct execution: before a statement reaches Postgres, hoop.dev evaluates it against policy rules. If a command attempts to drop a table or export large data sets, the gateway can route the request for human approval or reject it outright, providing a clear approval trail.
Confidentiality – protection of sensitive data: when a SELECT returns rows containing personally identifiable information, hoop.dev can mask those fields on the fly. The masked response is what the MCP server receives, while the original data remains protected in the audit log.
Availability – controlled access windows: hoop.dev’s just‑in‑time model grants temporary credentials that expire with the session. This limits the window of exposure and gives auditors evidence of time‑bounded access.
All of these artifacts, identity‑bound logs, approval records, masking actions, and session replays, are retained by hoop.dev for audit purposes. When an audit is scheduled, the organization can export the relevant logs, attach the session recordings, and present a complete chain of custody that maps every database interaction back to a verified identity and policy decision.
Putting the pieces together
- Setup: Configure your identity provider (Okta, Azure AD, Google Workspace, etc.) to issue OIDC tokens for the MCP server. Define scoped roles that limit the server to the minimum set of SQL operations required for its workload.
- The data path: Deploy hoop.dev as a network‑resident gateway near the Postgres instance. Register the Postgres connection in hoop.dev, supplying the service‑level credential that the gateway will use to talk to the database.
- Enforcement outcomes: hoop.dev records every query, applies inline masking, enforces approval workflows, and makes a replay‑able session archive available for auditors.
By separating identity verification (setup) from policy enforcement (gateway), hoop.dev ensures that the only place where a request can be examined and controlled is the data path. Removing hoop.dev would revert the architecture to the original direct‑connect model, eliminating all of the audit evidence described above.
Getting started
To try this approach, follow the getting‑started guide to deploy the gateway and register a Postgres target. The learn section provides deeper coverage of masking policies, approval workflows, and session replay features.
FAQ
Do I need to change my existing MCP server code?
No. The MCP server simply points its database client at the hoop.dev endpoint instead of the raw Postgres host. All protocol handling remains unchanged.
Can hoop.dev help me prove compliance for other SOC 2 criteria like privacy?
While hoop.dev does not claim any certification, the logs and masking actions it generates can be used as supporting evidence for privacy‑related controls that require data‑handling accountability.
What happens if an auditor wants to see the raw, unmasked data?
The original, unmasked rows are retained in the secure audit store managed by hoop.dev. You can grant read‑only access to the audit store for the audit period, ensuring the auditor sees the true data without exposing it to the MCP server during normal operation.
Ready to see how a Layer 7 gateway can turn an opaque MCP‑to‑Postgres connection into a SOC 2‑ready audit trail? Explore the open‑source repository on GitHub and start building a compliant data access layer today.
