PCI DSS 4.0 Evidence Mapping for AI Agents
PCI DSS 4.0 fully replaced 3.2.1 on March 31, 2024, and the future-dated requirements landed March 31, 2025. If an AI agent in your stack ever touches the Cardholder Data Environment, Requirements 7, 8, and 10 apply to each governed tool call it makes. Runtime authorization is how those requirements get enforced for non-human identities.
Last updated: May 20, 2026
What is PCI DSS 4.0?
The Payment Card Industry Data Security Standard version 4.0 was published by the PCI Security Standards Council on March 31, 2022. PCI DSS v3.2.1 was retired March 31, 2024; future-dated requirements in v4.0 became fully enforceable on March 31, 2025. PCI DSS v4.0.1 was published in June 2024. The standard applies to any organization that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). Enforcement is contractual through card brands and acquiring banks; non-compliance and confirmed breaches can create material assessments, remediation costs, and acquiring-bank scrutiny.
Why it applies to AI agents
Agents are increasingly deployed in payment workflows: dispute resolution, refund triage, billing reconciliation, fraud review, customer self-service. Even agents that only read masked PANs are subject to PCI DSS controls if they operate inside the CDE or interact with systems that do. The fact that an agent is non-human does not make the requirements looser. Requirement 7.2.5 calls out application and system accounts as a distinct category that needs explicit access management.
The risk is the same risk that drives every other PCI control: an unauthorized action can expose primary account numbers, magstripe data, or CVV2 codes. An agent with broad access to a payments API and prompt injection in its inputs creates breach exposure if the tool path is not governed.
Control mapping: PCI DSS 4.0 requirements to Veto features
The table maps the requirements most directly engaged by AI agent systems operating in or adjacent to the CDE.
| Requirement | Description | Veto feature |
|---|---|---|
| 7.2.1 | Access control model defined for system components in scope | Policy-as-code enumerates allowed tools, arguments, and approval rules per agent identity |
| 7.2.2 | Access assigned based on job classification and least privilege | Role-based policy files separating support, billing, fraud-review, and reconciliation agents |
| 7.2.4 | All user accounts reviewed at least every six months | Policy review reminders; CODEOWNERS-required reapproval of agent policies on a configurable cadence |
| 7.2.5 | Application and system accounts managed with intent and minimum privilege | Per-agent API keys, scoped to project/org; documented intent in policy comments |
| 8.2.1 | Unique ID for each user before allowing access to system components | Unique agent ID and API key per identity; cross-tenant isolation |
| 8.6.1 | Accounts used by systems/applications managed to prevent unauthorized use | Key rotation history; environment-scoped keys; alerting on unusual usage patterns |
| 8.6.2 | Passwords/passphrases for application/system accounts are not hard-coded in code | API keys delivered via secret manager integrations; never embedded in policy YAML |
| 10.2.1 | Audit logs capture all user access to system components and CHD | Governed CDE tool calls can be recorded with agent ID, tool, arguments (PAN redacted), policy, and outcome |
| 10.2.2 | Audit logs capture user identification, type of event, timestamp, success/failure, origin, and affected data | Decision record schema covers the core audit fields per record |
| 10.4.1 | Audit logs reviewed at least daily for security events | Policy-violation views and exports that support your daily review workflow and reviewer sign-off |
| 10.5.1 | Audit log history retained for at least one year, with three months immediately available | Configurable retention and export paths; align hot storage and archive policy with your PCI evidence plan |
| 12.3.1 | Critical technologies have approved use cases, authentication, list of devices, acceptable use | Policy YAML serves as the approved-use document; CI gates restrict unapproved tools |
Evidence Veto provides
A QSA performing a Report on Compliance (ROC) needs documented evidence per requirement. Self-assessment questionnaires (SAQ-A through SAQ-D) need the same artifacts at lower attestation depth.
Access matrices
Per-agent policy YAML enumerates allowed tools and arguments. Reviewable by QSA as the access control model required by 7.2.1.
Decision records
Decision record entries per Req 10.2.1 and 10.2.2 with PAN redaction configured so decision records do not need to become a CHD repository.
Daily review records
Reviewer sign-off on flagged decisions documents the daily log review required under 10.4.1.
Six-month reviews
Policy review timestamps and CODEOWNERS approvals document the periodic access review required by 7.2.4.
Implementation timeline
Card-brand assessments, acquiring-bank action, forensic reviews, and remediation costs can become material after non-compliance or a confirmed breach.
Frequently asked questions
When did PCI DSS 4.0 become mandatory?
Which PCI DSS requirements apply to AI agents?
Can AI agents have access to cardholder data?
What evidence does a QSA expect from an AI agent deployment?
Related evidence resources
If an agent can touch PAN or the CDE, it needs PCI-grade access and log evidence. Make the boundary reviewable.