MCP gateways: what they mean for your audit trail (on Postgres)

Missing or incomplete audit trails let attackers erase their footprints and make post‑mortems impossible.

Today many teams rely on MCP gateways to route traffic from AI assistants or custom runtimes into PostgreSQL. The gateway abstracts the database endpoint, allowing developers to invoke queries without embedding credentials in code. In practice, the connection is often opened with a long‑lived service account and left running for weeks. Engineers share the same endpoint, and the gateway does not emit a unified log of who ran which statement. When a rogue query modifies or deletes rows, the only evidence may be a fleeting console output that disappears after the session ends. The result is a blind spot: you know something happened, but you cannot prove who, when, or what data was touched.

This situation satisfies a basic prerequisite – the request reaches PostgreSQL through an MCP gateway – but it leaves the critical control plane untouched. The gateway still forwards the raw SQL payload directly to the database engine. No inline masking runs, no just‑in‑time approval step intercepts risky statements, and no session recording persists after the connection closes. In other words, the request bypasses any enforcement layer that could generate a reliable audit trail.

Why the audit trail matters for Postgres

Regulators, auditors, and security teams require a reliable audit trail that records who accessed what data and when. An audit trail must capture the identity of the caller, the exact statement executed, and the response returned. For PostgreSQL, this means logging SELECT, UPDATE, DELETE, and DDL operations with enough context to reconstruct the impact. Without a trustworthy audit trail, you cannot demonstrate compliance, investigate incidents, or enforce least‑privilege policies. The gap becomes especially dangerous when AI‑driven agents generate queries on‑the‑fly, because the originating code may not retain any human‑readable history.

Placing the enforcement layer in the data path

To close the gap, the enforcement point must sit between the identity source and the PostgreSQL endpoint. This is the only place you can observe every packet, apply policy, and record the interaction before the database processes the request. hoop.dev fulfills that role. It acts as a Layer 7 gateway that proxies the connection, inspects each SQL command, and writes a complete audit entry for every session. Because the gateway owns the credential used to talk to PostgreSQL, the client never sees the secret, and the database cannot be reached directly without passing through the gateway.

When a user or an AI agent initiates a connection, hoop.dev verifies the OIDC token, extracts group membership, and maps that to a policy that defines what statements are allowed. If a statement matches a risky pattern – for example, a DROP TABLE or a mass UPDATE without a WHERE clause – hoop.dev can block it outright or route it for manual approval. Approved statements continue to the database, while blocked ones generate an alert and are recorded as denied attempts. Every response, including result sets that contain sensitive columns, can be masked in real time, ensuring that downstream logs never expose PII.

Because the gateway records each request and response, you obtain a durable audit trail that includes:

• Timestamp of the session start and end.
• Identity of the caller (user, service account, or AI agent).
• Full SQL statement sent to PostgreSQL.
• Outcome – success, failure, or blocked by policy.
• Any inline masking applied to result rows.

These records are stored outside the PostgreSQL process, so even a compromised database cannot tamper with the audit trail. The logs are available for replay, enabling investigators to replay a session exactly as it happened, or to export evidence for compliance audits.

Getting started with hoop.dev for PostgreSQL

The first step is to deploy the hoop.dev gateway in the same network segment as your PostgreSQL instance. The official getting‑started guide walks you through a Docker Compose deployment, OIDC configuration, and how to register a PostgreSQL connection. Once the gateway is running, update your client connection strings to point at the hoop.dev host instead of the raw database endpoint. From that point forward, every query flows through the data path where hoop.dev enforces policy and writes the audit trail.

For deeper insight into masking rules, approval workflows, and session replay, explore the feature documentation. The docs provide examples of policy expressions for PostgreSQL and show how to configure just‑in‑time approvals for high‑risk statements.

FAQ

What happens if an AI agent issues a query that contains a sensitive column?

hoop.dev inspects the response before it reaches the client. If the policy marks the column as sensitive, the gateway masks the value in the result set, and the masked value is stored in the audit trail. This prevents accidental leakage while still preserving a record of the access.

Can I still use native PostgreSQL tools like psql?

Yes. Because hoop.dev proxies the wire protocol, any standard PostgreSQL client works unchanged. The only difference is the host and port you point to – they now resolve to the hoop.dev gateway.

Is the audit trail tamper‑proof?

The trail is written by hoop.dev outside the PostgreSQL process. Even if the database is compromised, the recorded logs remain intact because they are stored in a separate location managed by the gateway.

By moving the enforcement and logging responsibilities into the data path, you gain a reliable audit trail that can satisfy auditors, support incident response, and reduce the risk of hidden data manipulation.

Explore the open‑source code on GitHub to see how the gateway is built and contribute improvements.