Do you need reliable audit logging for your MCP servers that sit on PostgreSQL?
Most engineering teams reach a PostgreSQL instance directly from a developer laptop or a CI runner. The connection usually relies on a shared database user, a static password, or a long‑lived IAM credential. Because the client talks straight to the database, the organization has no central record of which statements were executed, who ran them, or what data was returned. If a rogue query extracts personal data or drops a table, the only evidence lives in the client’s memory or in ad‑hoc logs that may have been rotated away.
Introducing audit logging addresses the missing visibility. It captures every SQL statement, timestamps it, and ties it to the identity that issued the request. However, simply adding a logger on the client does not close the gap: the request still travels directly to PostgreSQL, there is no inline masking of sensitive columns, no real‑time approval workflow, and no way to block dangerous commands before they hit the engine. In other words, audit logging fixes the evidence problem but leaves the enforcement surface untouched.
Why audit logging matters for Postgres
Regulatory frameworks and internal policies often require proof that data access was authorized and that any modification to the database can be traced back to an individual identity. Without audit logging, a security review must rely on indirect signals such as network flow records or application‑level logs, which are incomplete and easy to tamper with. A comprehensive audit trail also supports forensic investigations, helps identify insider threats, and enables automated alerting when suspicious patterns emerge.
How hoop.dev adds audit logging to the data path
The missing piece is a control point that sits between the identity provider and the PostgreSQL server. hoop.dev provides exactly that: a Layer 7 gateway that proxies the wire protocol, inspects each command, and records it before it reaches the database.
Setup defines identity but does not enforce
Authentication is performed upstream via OIDC or SAML. The setup phase creates a scoped identity for each engineer or service account, decides which groups may request access, and issues short‑lived tokens. This step determines who may start a session, but it does not decide what the session can do once it is underway.
The data path is the only place enforcement can happen
All traffic is forced through hoop.dev’s gateway. Because the gateway terminates the PostgreSQL protocol, it becomes the sole point where policy can be applied. No command bypasses the gateway, and the database never sees the original client credentials.
Enforcement outcomes provided by hoop.dev
Once the request reaches the gateway, hoop.dev records each SQL statement, the originating identity, and the exact timestamp. The recorded session can be replayed later for audit or compliance purposes. Because the gateway controls the data path, it can also apply additional guardrails such as inline masking of PII columns, blocking of DROP or ALTER commands, and routing of risky queries to a human approver. All of these outcomes exist only because hoop.dev sits in the data path.
Getting started with hoop.dev for MCP and Postgres
Deploy the gateway using the official Docker Compose quick‑start, then register your PostgreSQL instance as a connection. The gateway holds the database credentials, so engineers never handle passwords directly. Identity is verified against your OIDC provider, and the scoped token determines which MCP server can request audit logging for a given session. Detailed steps are available in the getting‑started guide and the broader learn section where you can explore configuration options for audit logging, masking, and approval workflows.
When the gateway is running, any client that points to the hoop.dev endpoint, whether it is a psql client, an application, or an MCP server, will have its queries captured automatically. The audit logs are stored in a secure store managed by the gateway, and they can be exported to your SIEM or compliance platform for further analysis.
Explore the source code, contribute improvements, or file an issue on the public repository: hoop.dev on GitHub.
FAQ
Is audit logging enabled by default?
When you deploy the gateway, audit logging is part of the default policy set. You can tighten or relax the policy, but the baseline captures every statement.
Can I mask sensitive columns without changing my application?
Yes. Because hoop.dev sits in the data path, it can rewrite result rows on the fly, redacting PII before the data reaches the client.
What happens if the gateway goes down?
The gateway is designed for high availability. If one instance fails, another can take over without interrupting active sessions, ensuring continuous audit coverage.
