Many assume that an LLM‑driven MCP server can query a database directly and still keep sensitive fields hidden. In reality, a direct connection hands the raw rows to the model, making PII or PHI visible to the AI and any downstream logs.
Why data masking matters for MCP‑driven queries
When an MCP server generates code, retrieves configuration, or answers user prompts, it often needs to read from PostgreSQL. If the response contains credit‑card numbers, health identifiers, or other regulated data, the model may unintentionally embed that information into its output. Masking at the source prevents the model from ever seeing the raw values, reducing the risk of data leakage and simplifying compliance reporting.
Where the control belongs
Identity providers (Okta, Azure AD, Google Workspace, etc.) decide which service account or user is allowed to start a connection. That decision is necessary, but it does not enforce masking. The enforcement point must sit on the data path, between the MCP server and PostgreSQL. hoop.dev provides exactly that gateway.
hoop.dev as the data‑path enforcer
hoop.dev runs a Layer 7 proxy that terminates the PostgreSQL wire protocol. The gateway holds the database credentials, so the MCP server never has access to a password or IAM token. When a query arrives, hoop.dev inspects the result set, applies inline data masking rules, records the statement, and forwards the sanitized rows to the client. Because the masking occurs inside the gateway, the MCP server receives only the redacted values.
Architectural steps for a secure MCP‑to‑Postgres path
- Deploy the hoop.dev gateway in the same network segment as the PostgreSQL instance. The quick‑start guide walks through a Docker‑Compose deployment that includes OIDC authentication, TLS termination, and the masking engine.
- Register the PostgreSQL target in hoop.dev. Provide the host, port, and a service‑level database user. hoop.dev stores this secret and presents it to PostgreSQL on behalf of the MCP server.
- Define data masking policies for the columns that contain sensitive data. Policies can target column names, data types, or regex patterns. When a result row matches a policy, hoop.dev replaces the value with a placeholder before it reaches the MCP server.
- Configure the MCP server to point its database URL at the hoop.dev gateway instead of the raw PostgreSQL endpoint. From the server’s perspective the connection behaves exactly like a normal psql session.
- Optionally enable just‑in‑time (JIT) approvals for high‑risk statements. hoop.dev can pause a DROP TABLE or DELETE until an authorized reviewer grants permission, while still masking all reads.
With this layout, the MCP server gains the data it needs, but every row passes through a gateway that enforces data masking, records the query, and can block dangerous commands. The gateway’s audit log captures the exact SQL statement, the identity that issued it, and the timestamp, giving you a complete evidence trail.
Benefits of using hoop.dev for MCP‑driven access
- Zero‑knowledge credentials: The MCP server does not have access to the database password.
- Inline masking: Sensitive fields are redacted before they ever reach the model, eliminating accidental exposure.
- Command‑level audit: Every statement is logged with identity context, supporting forensic analysis and compliance reporting.
- Guardrails: Potentially destructive statements can be routed for manual approval, reducing blast radius.
- Unified control surface: Masking, audit, and guardrails are managed in a single place rather than scattered across application code.
Getting started
For a step‑by‑step walkthrough, see the getting‑started guide. It covers deploying the gateway, configuring PostgreSQL, and defining masking rules. Detailed feature descriptions are available in the learn section. When you are ready to explore the source code or contribute, visit the repository on GitHub.
FAQ
Can I mask specific columns without affecting the rest of the result set?
Yes. hoop.dev lets you create policies that target individual column names or patterns. Only the matching fields are replaced, while all other columns pass through unchanged.
Does hoop.dev store the PostgreSQL password?
hoop.dev holds the credential in its own secure store, and it never writes the password to the MCP server’s environment. The gateway presents the credential to PostgreSQL on behalf of the client.
How does the audit log help with compliance?
Each query is recorded with the user identity, timestamp, and the exact SQL text. Those logs can be exported to SIEMs or retained for SOC 2, GDPR, or other regulatory audits, providing verifiable evidence of who accessed what data.
