An offboarded contractor’s CI pipeline continues to push code that accesses a payment‑processing microservice built on MCP, and the security team can’t prove whether the contractor ever read cardholder data. The same uncertainty shows up when a newly‑granted service account runs a nightly batch job that writes to the same MCP endpoint. PCI DSS demands a complete audit trail of every interaction with cardholder data, yet most teams rely on ad‑hoc logs that disappear after a few days.
PCI DSS defines a set of technical and procedural controls that must be demonstrable during an audit. Control 10.2, for example, requires “recording of all access to cardholder data,” while Control 3.4 mandates that “sensitive authentication data be rendered unreadable after authorization.” The auditor will ask for concrete artifacts: who initiated a connection, which commands were executed, whether any sensitive fields were exposed, and evidence of any manual approvals that granted elevated privileges.
Generating those artifacts is not a matter of flipping a switch in the application code. The data path that carries MCP requests must be instrumented so that every request can be inspected, logged, and, when necessary, altered before it reaches the backend service. Without a dedicated gateway, the only logs available are the MCP server’s own output, which typically lacks user identity, command‑level granularity, and immutable storage. The result is a compliance gap that can cause audit failures, fines, or even a loss of the ability to process card payments.
PCI DSS evidence requirements for MCP
To satisfy the PCI DSS audit, an organization needs to produce the following evidence for any MCP‑based service that handles payment data:
- Identity‑bound session records: timestamps, user or service‑account identifiers, source IP, and the exact duration of each connection.
- Command‑level audit trails: a line‑by‑line log of every query or API call, including parameters, that were sent through MCP.
- Inline data masking logs: proof that fields such as PAN or CVV were masked in responses before they left the controlled environment.
- Just‑in‑time (JIT) approval records: a signed record showing who approved a privileged operation, when, and under what justification.
- Session replay capability: the ability to replay a recorded session to verify exactly what was seen or typed during the interaction.
Each of these artifacts must be retained for at least one year as required by PCI DSS. The artifacts also need to be searchable so that auditors can quickly retrieve the relevant slice of activity for a given cardholder data set.
Why a data‑path gateway is the only reliable solution
Setup components, such as OIDC identity providers, service‑account roles, and least‑privilege IAM policies, determine who may start a request, but they do not enforce what happens to the request once it leaves the identity system. The enforcement outcomes required by PCI DSS (recording, masking, approval, replay) can only be guaranteed when they are applied at the point where traffic flows to MCP.
When a gateway sits in the data path, it becomes the sole authority that can:
- Capture the full request and response stream, binding it to the authenticated identity.
- Apply real‑time masking to any response fields that match PCI‑defined patterns.
- Pause execution of a high‑risk command and route it to a human approver before it reaches the MCP backend.
- Store an audit log that can be replayed in its original order.
Without that centralized interception point, each MCP node would need to implement its own logging, masking, and approval logic, leading to inconsistent coverage and gaps that auditors will flag.
How hoop.dev fulfills PCI DSS requirements for MCP
hoop.dev is an open‑source, layer‑7 gateway that sits between identities and MCP services. It authenticates users via OIDC or SAML, then proxies every MCP request through a network‑resident agent. Because hoop.dev is the only point where traffic passes, it can enforce all PCI‑required controls.