Many teams assume that granting an AI‑driven MCP server direct credentials automatically satisfies PCI DSS, but the standard demands auditable, controlled access to every transaction.
PCI DSS is explicit about who can touch cardholder data, how that access is recorded, and what safeguards must surround the data at rest and in motion. When a machine‑learning model interacts with a PostgreSQL database that stores PANs (Primary Account Numbers), the same rules that apply to a human analyst also apply to the model. The model needs a way to authenticate, it must only see the columns it is authorized for, and every query it runs must be traceable to a responsible identity.
Why the default MCP setup falls short of PCI DSS
Out‑of‑the‑box MCP servers typically receive a static service account credential that is baked into the container image or injected via an environment variable. That approach creates three gaps:
- Unbounded privilege. The service account often has full read/write rights on the entire database, violating Requirement 7 (restrict access to cardholder data).
- No per‑request identity. All queries appear to come from the same service account, making it impossible to satisfy Requirement 10 (track and monitor all access).
- Unmasked data exposure. Responses that contain PANs are streamed back to the model without any redaction, conflicting with Requirement 3 (protect stored cardholder data).
Even if you adopt a non‑human identity – for example, an OIDC‑issued token for the MCP server – the request still travels directly to PostgreSQL. The database sees the request, but there is no gateway that can apply inline masking, enforce just‑in‑time (JIT) approval, or record the session for later replay. The setup therefore satisfies the authentication piece of PCI DSS but leaves the critical audit and data‑protection pieces unaddressed.
How PCI DSS evidence is generated for MCP servers
The missing piece is an identity‑aware proxy that sits on the data path. By placing a layer‑7 gateway between the MCP server and PostgreSQL, you create a single control surface that can enforce the exact controls PCI DSS expects. This is where hoop.dev comes in.
hoop.dev acts as a transparent proxy for PostgreSQL connections. When the MCP server initiates a connection, it authenticates to hoop.dev using an OIDC token. hoop.dev validates the token, extracts the caller’s group membership, and then decides whether to grant a short‑lived credential to PostgreSQL. Because the gateway is the only place the traffic passes, it can apply the following enforcement outcomes:
- Session recording. hoop.dev records every query and response, storing a replay‑able log that maps each statement to the originating identity. This log satisfies the audit‑trail requirement of PCI DSS.
- Inline data masking. Sensitive columns such as card_number can be masked in real time before the data reaches the MCP server, ensuring that the model never sees raw PANs unless an explicit approval is granted.
- Just‑in‑time access. Access tokens are minted for a limited window, and the gateway can require an additional human approval step for high‑risk queries (for example, bulk SELECTs on the payments table).
- Command blocking. Dangerous statements – such as DROP TABLE or DELETE FROM payments without a WHERE clause – can be automatically rejected, reducing the blast radius of a compromised model.
All of these outcomes are produced because hoop.dev sits in the data path; the underlying OIDC setup merely decides who is allowed to ask for a session. If you removed hoop.dev, the MCP server would regain direct access to PostgreSQL, and none of the audit, masking, or approval controls would exist.
Mapping PCI DSS requirements to hoop.dev capabilities
Below is a concise mapping that shows how each relevant PCI DSS requirement is addressed when an MCP server talks to PostgreSQL through the gateway:
| Requirement | What PCI DSS expects | How hoop.dev fulfills it |
|---|
| Req 7 | Restrict access to cardholder data to least privilege | hoop.dev grants only the specific schema or columns needed for the request, and can deny any request that exceeds the defined scope. |
| Req 8 | Identify and authenticate all users | Each MCP request is tied to an OIDC‑issued identity; the gateway enforces that identity for the duration of the session. |
| Req 10 | Track all access to network resources and cardholder data | hoop.dev logs every statement, response, and approval decision, linking it to the originating identity and timestamp. |
| Req 3 | Protect stored cardholder data | Inline masking ensures that raw PANs never leave the database without redaction, and the gateway can enforce encryption at rest for any persisted logs. |
| Req 12 | Maintain a policy that addresses information security for all personnel | Policies are expressed as gateway rules – for example, “MCP servers may only SELECT from the payments view after manager approval.” |
Because the enforcement happens at the gateway, the evidence is generated automatically and can be handed to auditors without any manual log stitching.
Deploying the gateway for MCP servers
To bring these controls into production, follow the high‑level steps below. Detailed instructions are available in the getting‑started guide and the broader learn section:
- Deploy hoop.dev using the provided Docker Compose file or a Kubernetes manifest. The gateway runs alongside the PostgreSQL instance inside your trusted network.
- Configure an OIDC provider (Okta, Azure AD, Google Workspace, etc.) and create a service‑account identity that the MCP server will assume.
- Register the PostgreSQL connection in hoop.dev, supplying the host, port, and a privileged credential that the gateway will use internally.
- Define masking rules for columns that contain PANs, and enable JIT approval for bulk queries.
- Update the MCP server’s connection string to point at the hoop.dev host and to present the OIDC token instead of a static password.
Once the gateway is in place, every request from the model is subject to the policies you defined. The audit logs, masking actions, and approval records are retained by hoop.dev and can be retrieved for audit purposes, ready for the next PCI DSS audit.
FAQ
Do I need to modify my MCP server code to use hoop.dev?
No. hoop.dev speaks the native PostgreSQL wire protocol, so the MCP server can continue using its existing client libraries. The only change is the endpoint address and the addition of an OIDC token for authentication.
Can hoop.dev integrate with my existing SIEM?
Yes. The session logs and approval events can be streamed to standard syslog, HTTP, or cloud‑native logging endpoints, allowing you to correlate them with other security events in your SIEM.
What happens if the MCP server tries to run a prohibited command?
hoop.dev intercepts the statement before it reaches PostgreSQL, returns an error to the client, and records the blocked attempt. This satisfies the requirement to prevent unauthorized changes to cardholder data.
By placing a Layer 7 gateway between AI‑driven tools and your PostgreSQL database, you turn a black‑box integration into a fully auditable, PCI DSS‑compatible workflow. The combination of just‑in‑time credentials, real‑time masking, and session logs that can be replayed for audit gives you the evidence auditors demand without sacrificing the agility of modern machine‑learning pipelines.
Explore the source code, contribute improvements, and see the full feature set on GitHub: https://github.com/hoophq/hoop.
