A common misconception is that MCP servers automatically perform pii/phi redaction when they query a PostgreSQL database. In reality the server forwards the raw result set, and any downstream consumer sees exactly what the database returns.
Most teams deploy MCP‑enabled services with a single database credential that lives in the application configuration. Engineers grant the service broad read rights, and the service can issue arbitrary SELECT statements. When a query returns columns that contain patient identifiers, credit‑card numbers, or other regulated fields, those values travel unmasked across the network and appear in logs, monitoring dashboards, and developer terminals. The exposure is hard to detect because the same credential is reused for many workloads, and the database itself does not enforce column‑level redaction.
Why the existing identity layer is not enough for pii/phi redaction
Modern identity providers let you issue short‑lived tokens, enforce group membership, and require multi‑factor authentication. That solves the "who can connect" problem, but it does not address "what data leaves the database". An MCP server can still issue a query that pulls a full customer record, and the response will be streamed back unchanged. Without a guard on the data path there is no audit of which rows were accessed, no inline masking of sensitive fields, and no way to block a dangerous SELECT before it runs.
The missing piece is a Layer 7 gateway that sits between the MCP server and PostgreSQL, inspects each statement, and applies policy before the data ever leaves the database.
How hoop.dev provides pii/phi redaction for Postgres
hoop.dev implements a native wire‑protocol proxy for PostgreSQL. The MCP server points its client to the hoop.dev gateway instead of the database host. The gateway authenticates the request via OIDC or SAML, extracts group membership, and creates a just‑in‑time identity that is scoped to the specific operation.
Once the connection is established, hoop.dev evaluates every SQL statement against a set of guardrails. If a query attempts to read a column marked as sensitive, hoop.dev applies inline masking. The masking engine redacts values such as Social Security numbers, medical record identifiers, or credit‑card digits before the rows are sent back to the MCP server. The original values never traverse the network beyond the database, and they never appear in logs or monitoring tools.
In addition to masking, hoop.dev records each statement at command level. The audit log captures the user identity, the exact SQL text, timestamps, and the outcome of the masking step. Because the gateway sits in the data path, it can also block statements that match a dangerous pattern, such as DROP TABLE or massive full‑table scans, and route them for human approval when required.
All database credentials are stored inside the gateway. The MCP server never sees the password or IAM token, eliminating credential sprawl. The combination of just‑in‑time access, inline pii/phi redaction, and recorded session logs turns a raw PostgreSQL connection into a compliance‑ready data pipeline.
Getting started
To try this flow, deploy the hoop.dev gateway using the Docker Compose quick‑start. The composition includes OIDC configuration, a default masking policy, and a sample PostgreSQL connection. After the gateway is running, point your MCP server’s database URL to the gateway endpoint. The documentation walks you through defining which columns should be masked and how to tune guardrails for your workload.
For detailed steps, see the getting‑started guide and the learn section that explains masking policies, audit logging, and just‑in‑time access.
FAQ
- Can hoop.dev redact data for databases other than PostgreSQL? Yes, the same masking and guardrail model applies to all supported wire‑protocol connectors, including MySQL, MSSQL, and MongoDB.
- Does hoop.dev store the original unmasked data? No. The gateway only sees the raw rows inside the database process, applies redaction, and forwards the filtered result. The original values remain in the database storage layer.
- How does hoop.dev integrate with existing CI/CD pipelines? The gateway is configured declaratively; you can version masking policies alongside your infrastructure code and apply them automatically when the gateway starts.
Ready to see the code and contribute? Get the source on GitHub.
