An offboarded contractor’s CI job still holds a hard‑coded Postgres password that it sends through an MCP gateway every night. Because access reviews depend on knowing exactly which identities accessed which data, this hidden traffic undermines the review process. The password never expires, and the nightly job continues to read customer data long after the contractor’s contract ended.
Teams often rely on static database credentials stored in environment variables or secret managers. Those credentials are granted to CI pipelines, batch jobs, or service accounts, and the only review process is a periodic check of IAM roles or group memberships. The actual traffic that reaches Postgres is invisible to auditors because the MCP gateway sits between the job and the database, but the review process does not look through that gateway.
This model creates three blind spots. First, stale or over‑privileged credentials linger indefinitely. Second, there is no record of which non‑human identity executed which query, so reviewers cannot verify the principle of least privilege. Third, sensitive columns travel in clear text across the network, and no one can guarantee that downstream consumers are not leaking them.
Why access reviews fall short without a data‑path control
The precondition we need to address is bringing non‑human identities, CI jobs, service accounts, automated agents, into the access‑review loop. Adding a tag or a label to a service account tells the identity provider who the request is, but the request still reaches Postgres directly. No audit log, no inline masking, and no just‑in‑time approval happen on the way. In other words, the review process still lacks visibility into the actual data path.
Without a control point that sits on the wire, reviewers cannot answer questions such as: Which job queried the payments table yesterday? Did any query return credit‑card numbers? Was a destructive command like DROP TABLE ever issued? The answers remain unknown because the enforcement outcomes exist only where the traffic is inspected.
Introducing hoop.dev as the enforcement point
hoop.dev provides a Layer 7 gateway that proxies every Postgres connection coming from an MCP gateway. It verifies the caller’s OIDC token, then forwards the request to the database while applying policy at the protocol level. Because hoop.dev sits in the data path, it is the sole place where masking, approval, and recording can be enforced.
When a CI job attempts to run a query, hoop.dev records the session, retains a searchable audit trail, and can mask columns that contain personally identifiable information. If the query matches a high‑risk pattern, such as a SELECT that pulls full credit‑card numbers, hoop.dev can pause the request and require a human approver before it proceeds.
How hoop.dev strengthens access reviews
Because hoop.dev captures every statement, reviewers now have concrete evidence for each identity. The audit logs show which service account accessed which schema, what rows were returned, and whether any masking was applied. This data feeds directly into the access‑review workflow, turning a speculative checklist into a fact‑based assessment.
In addition, hoop.dev’s inline masking ensures that even if a compromised job exfiltrates data, the most sensitive fields are already redacted. The just‑in‑time approval workflow forces a privileged user to explicitly consent to risky operations, reducing the blast radius of automated jobs.
The setup phase, defining OIDC clients, assigning service‑account roles, and provisioning the MCP gateway, decides who may start a connection. However, only hoop.dev, positioned in the data path, can enforce masking, logging, and approval. Without hoop.dev, those enforcement outcomes disappear.
Getting started
To see the full implementation details, follow the getting‑started guide and explore the feature documentation on the learn page. The repository contains example configurations for Postgres behind an MCP gateway.
Explore the source code on GitHub to understand how the gateway integrates with your existing CI pipelines.
FAQ
- Can hoop.dev mask data without changing the application code? Yes. Because it operates at the wire‑protocol level, masking rules are applied transparently to any client that talks through the gateway.
- Do I need to change my existing Postgres credentials? No. hoop.dev stores the credential internally and presents a short‑lived token to the database, so existing connection strings remain unchanged.
- How does this affect performance? The gateway adds a minimal network hop, but the audit and masking logic runs in‑process and is designed for low latency.
