PCI DSS for MCP servers: securing tool access without losing the audit trail

An assessment is a list of artifacts. The QSA sends an evidence request, and for every MCP server tool that can reach the cardholder data environment, you are expected to hand over specific documents: the access logs, the access-control configuration, the approval records, proof the audit trail is protected. PCI DSS for MCP servers comes down to whether you can produce those artifacts cleanly, or whether each one turns into a story about why the real evidence is somewhere you cannot get to.

An MCP server exposes tools to a model. When a tool, a query tool, an ops tool, reaches a database or service in the CDE, that path is in scope for PCI DSS. So walk the actual artifacts a QSA will ask for, and where each one has to come from.

The artifacts a QSA asks for

• An access log, per identity, for every reach into the CDE. Requirement 10 wants who, what, and when, attributable to a single actor, not a stream of tool calls under one shared server credential.
• The access-control configuration. Requirement 7 wants proof that each tool is restricted to a business need to know, scoped to specific data, not a wildcard grant.
• Approval records for higher-risk access. When a tool reaches sensitive data, who or what authorized it, recorded next to the access.
• Evidence the trail is protected. Requirement 10 wants the audit trail safe from the actors it records. A log inside the MCP server does not clear this.
• Proof of minimum exposure. If tools never need a full PAN, masking records showing they never received one shrink both risk and scope.

The recurring failure is that all five artifacts, if they exist at all, live inside the MCP server or its host, the exact component the QSA is assessing. An audited component cannot be its own evidence custodian.

Produce the artifacts at the boundary

The architectural requirement is that these artifacts are produced and stored at the access boundary, outside the MCP server, where the server cannot shape or lose them. When the boundary between the tool and the CDE is the thing that writes the log, enforces the scope, captures the approval, and applies the mask, the evidence request stops being a scavenger hunt. Every artifact is a query against records that already exist, in a place the audited server does not control.

hoop.dev is built to be that boundary. The databases and services an MCP server's tools reach in the CDE sit behind hoop.dev, a Layer 7 access gateway with a network-resident agent. Tool calls connect through it under a real identity, so the per-identity access log (Requirement 10), the scoped configuration (Requirement 7), the approvals, and the inline masking are all produced on the gateway side, outside the server. hoop.dev generates exactly the evidence for PCI DSS that the QSA's request list asks for. See the getting-started docs for fronting a connection and the learn pages for how access, approvals, and recording fit together.

The evidence request, answered

With the boundary in place, the QSA's list maps one to one onto records you can pull. Access log: the gateway's per-identity session history for CDE connections. Access control: the scope configured for each tool's identity. Approvals: the recorded decisions on higher-risk grants. Trail protection: the records live outside the MCP server, on the gateway side. Minimum exposure: the masking records showing truncated PANs. You hand over artifacts, not explanations.

FAQ

Does hoop.dev make our MCP server PCI DSS compliant?

No. PCI DSS compliance is assessed against your organization, and hoop.dev does not hold a PCI DSS certification. hoop.dev produces the audit artifacts, evidence for PCI DSS, that your assessment hands to a QSA: per-identity access logs, scoped configuration, approvals, and masking records.

Why can't the MCP server's own logs be the artifacts?

Because Requirement 10 expects the audit trail to be protected from the actors it records, and a log inside the MCP server shares the server's trust boundary. It also records tool calls, not the identity and CDE access behind them. Produce the artifacts at the access boundary instead.

hoop.dev is open source. To produce a QSA's evidence artifacts at the boundary instead of inside the server, start from the repository on GitHub.