How can you be sure that every query an MCP server runs against Postgres is captured for later review, and that session recording is enforced?
Most teams grant an AI‑driven service a static database user, store the password in a secret manager, and let the service connect directly to the database host. The connection bypasses any central control point, so there is no guarantee that a query was authorized, no way to replay the interaction, and no evidence that sensitive columns were protected. When a mistake occurs, an unexpected UPDATE or a malformed SELECT, engineers scramble to reconstruct what happened, often finding that the logs are incomplete or the credential was reused elsewhere.
Adding a compliance requirement such as session recording changes the equation. The MCP server must still reach Postgres to fulfill its workload, but the request now needs a mechanism that captures every command, timestamps it, and stores it in an audit trail. The existing setup, even if it includes least‑privilege database users, does not provide a place to enforce that capture. The request still travels straight to the database without a guardrail that can record, mask, or block it.
To close that gap, the enforcement point has to sit on the data path, between the identity that the MCP server presents and the Postgres instance that receives the wire‑protocol traffic. Only a gateway that proxies the connection can inspect each statement, apply policies, and persist a complete session record. This is where a Layer 7 access proxy becomes essential.
Why session recording matters for MCP‑driven Postgres access
Session recording provides three concrete benefits. First, it creates a forensic trail that auditors can query to verify that the MCP server only executed approved statements. Second, it enables replay of a session, which is invaluable for debugging complex AI‑generated queries that may produce unexpected side effects. Third, when combined with inline masking, it ensures that any returned personally identifiable information never leaves the controlled environment, protecting downstream consumers.
These outcomes cannot be achieved by identity federation alone. The authentication layer (OIDC, SAML, or service‑account tokens) tells the system who is connecting, but it does not inspect the payload of the connection. Without a data‑path proxy, the database sees the raw query and the proxy has no opportunity to record it.
Architectural components that make session recording possible
Setup. The MCP server authenticates to the gateway using an OIDC token issued by your corporate IdP. The token conveys the service’s identity and any group memberships that drive policy decisions. This step decides who the request is, but it does not enforce anything on its own.
The data path. A gateway runs as a network‑resident agent inside the same VPC or subnet as the Postgres instance. All traffic from the MCP server is forced through this proxy. Because the gateway terminates the PostgreSQL wire protocol, it can see each SQL statement before it reaches the database engine.
Enforcement outcomes. The gateway records every statement, timestamps it, and stores the full session for later replay. It can also apply inline data masking to redact columns that contain sensitive data before the rows are returned to the MCP server. All of these capabilities exist because the proxy sits in the data path; without it, the database would receive the query unobserved.
How the proxy captures a session
When the MCP server opens a connection, the gateway authenticates the OIDC token, maps the service identity to a database credential that it holds internally, and then establishes a backend connection to Postgres using that credential. From that point onward, every client‑side command passes through the proxy. The proxy writes the command to a session log, applies any configured guardrails (for example, blocking DROP statements), and forwards the allowed statement to the database. Responses flow back through the same path, where masking rules can redact fields such as SSN or credit‑card numbers before they reach the MCP server.
Because the proxy owns the session lifecycle, it can also enforce just‑in‑time access. An operator can approve a high‑risk query on demand, or the proxy can automatically reject commands that exceed a predefined risk threshold. All of these decisions are recorded alongside the query, creating a complete audit trail.
Getting started with session recording for Postgres
To implement this pattern, start by deploying the gateway using the official Docker Compose quick‑start. The compose file provisions the network‑resident agent, configures OIDC authentication, and enables the default session‑recording policy for PostgreSQL connections. Next, register your Postgres instance as a connection in the gateway’s catalog, supplying the host, port, and a service‑level database user that the gateway will use on behalf of the MCP server.
Finally, configure the MCP server to point its PostgreSQL client at the gateway’s address instead of the raw database endpoint. From the MCP server’s perspective nothing changes, it still uses the standard PostgreSQL client library, but behind the scenes every query is now captured, masked, and governed by the gateway.
For detailed step‑by‑step guidance, see the getting‑started documentation. The documentation walks you through deploying the gateway, adding a PostgreSQL connection, and enabling session recording. For deeper insight into policy configuration, refer to the learn section, which explains how to define masking rules and guardrails.
All of the heavy lifting is done by the open‑source gateway; you retain full control over the underlying storage and retention policies for the session logs.
Next steps
- Review your existing database credentials and replace any shared passwords with gateway‑managed identities.
- Define masking policies for any columns that contain regulated data.
- Enable just‑in‑time approvals for high‑risk statements such as schema changes.
- Monitor the session‑recording logs for anomalous activity and feed them into your SIEM.
By placing the enforcement point on the data path, you gain visibility and control that were impossible with direct connections.
Explore the source code on GitHub to see how the proxy is built and to contribute enhancements.
