PCI DSS AI Crosswalk
Purpose: Let a team that runs AI systems in or near a cardholder data environment find the wiki controls and test cases behind each point of the PCI Security Standards Council's AI guidance, and the PCI DSS requirements that guidance applies to AI.
Audience: Payment security and compliance teams, QSAs and ISAs preparing for an assessment, security architects, AI platform owners at merchants and service providers.
Using the two together: Use PCI DSS for the requirements and the PCI SSC supplement for how they apply to AI. Use this wiki for the controls, evidence and test cases that show each point is in place. The supplement is guidance only, and so is this page: neither changes what a PCI DSS assessment requires.
About the guidance and this page
Security Considerations for AI Systems is an information supplement from the PCI Security Standards Council, version 1.0, dated September 2026. It covers two things: securing AI systems that entities in scope of PCI standards deploy, and defending payment environments against attackers who use AI. It does not cover AI that makes payments (agentic commerce), and it does not cover the use of AI in PCI assessments, which PCI SSC addresses in a separate document, Integrating Artificial Intelligence in PCI Assessments Guidelines. The supplement states that it does not replace or supersede requirements in any PCI SSC standard, and that requirement references are to the versions current when it was published; it names PCI DSS v4.0.1.
Earlier, on 11 September 2025, PCI SSC published a blog post, AI Principles: Securing the Use of AI in Payment Environments, with high-level principles. The supplement is the longer guidance.
The supplement's main ideas, in its own terms:
- Limits of AI use. At a minimum an AI system should not have access to cleartext high-impact secrets, generate random data or high-impact secrets, make decisions no human is accountable for, share credentials or act in ways that are not uniquely identifiable, or reach systems it does not need.
- Least agency. Give an AI system only the access, data and ability to respond to input that its tasks need.
- The lethal trifecta. No AI system should combine access to sensitive data, exposure to untrusted content and external communication. Work that needs all three is split across agents, each with only one or two.
- Human in the loop or over the loop. Per-action approval may be replaced by approval of an agent's scope and functions, but a named, suitable person stays accountable, and the supplement lists the questions to answer first. For cleartext cardholder data it advises keeping per-action approval.
- An AI system is not a person. It stores rather than remembers, so anything that may not be stored in cleartext should not be given to it in cleartext; and it should be treated as a potential malicious insider, scoped by the network and system constraints it actually runs under, not by its prompt.
- Scope follows reach. An AI system that receives or can reach account data is in scope of PCI DSS; one that holds only tokens or encrypted data may be out of scope, but not if it can also reach the detokenisation system or key service.
Verify before use. The supplement's content and the requirement numbers in the first table were read from a copy of the PDF that the wiki maintainers received on 29 October 2026 [Verified against that copy]. Its publication was reported by Help Net Security on 9 October 2026 [Reported]; the copy in the PCI SSC Document Library could not be reached from the environment used to write this page, so check that your copy matches it. Requirement numbers marked [Recalled] are not cited by the supplement and come from this wiki's own reading of PCI DSS v4.0.1; check them against the standard before relying on them. The mapping is this wiki's own judgement and has not been reviewed by PCI SSC.
Match is Direct when the wiki has a control and at least one test case for the point as it applies to AI, Partial when it covers only part, as the notes explain, and Gap when the wiki does not cover it.
PCI DSS requirements the supplement applies to AI
These are the requirements the supplement cites by number, followed by the ones it refers to without a number.
| Requirement | What the supplement says for AI | Main wiki controls | Test cases | Match | Notes |
|---|---|---|---|---|---|
| 1.2.4 (data-flow diagrams) | Add AI deployments to the data-flow diagrams, including the data stores AI operation creates, and give no AI system access to data the entity has not classified and mapped. | AI-CTRL-017, AI-CTRL-011 | TC-L10-035, TC-L07-042, TC-L08-040 | Direct | AI-CTRL-017 now names the AI-created stores (logs, transcripts, caches, retrieved context, tool results, scratchpads, orchestration state). |
| Requirement 3, and 3.3.1 (no storage of sensitive authentication data after authorisation) | Use tokens, truncated or encrypted card data where possible; never give AI systems sensitive authentication data, even encrypted, or PIN blocks; anything that may not be stored in cleartext is not given to an AI system in cleartext. | AI-CTRL-017, AI-CTRL-002 | TC-L08-005, TC-L10-034, TC-L10-035 | Direct | The supplement also names the PCI PIN and PCI KMO standards for PIN blocks; the wiki does not map those standards. |
| 6.2.3 and 6.2.3.1 (code review) | AI may be used for code review otherwise done manually, with ongoing validation of its effectiveness and functional and security checks in the pipeline. | AI-CTRL-034, AI-CTRL-004, AI-CTRL-033 | TC-L14-024, TC-L05-034, TC-L14-022 | Direct | New case TC-L14-024 measures an AI reviewer against seeded flaws. |
| 6.5.1, with 6.2.4 (change procedures) | Its Example 1 shows how agent-made patches can meet each element of the change procedure: reason, security impact, approval, testing, and a way back to a secure state. | AI-CTRL-033, AI-CTRL-022, AI-CTRL-025 | TC-L14-023, TC-L06-034 | Direct | 6.2.4 appears only in the 6.5.1 table, for bespoke software, which the example does not address. |
| 8.4.2 (MFA into the CDE) | An AI system cannot perform MFA; where it accesses the CDE from outside, use at least device-bound and ideally cryptographic credentials, time-bound, and never reusable by others. | AI-CTRL-015, AI-CTRL-016 | TC-L09-027, TC-L09-002, TC-L09-003 | Direct | Whether a given credential design satisfies 8.4.2 is for the assessor. |
| 12.5.1 (inventory of system components) | Add AI deployments to the component inventory. | AI-CTRL-011, AI-CTRL-031 | TC-L05-008, TC-L09-001, TC-L16-001 | Direct | |
| 12.5.2 (scope confirmation) | Always review AI systems when confirming PCI DSS scope. | AI-CTRL-011, AI-CTRL-017 | TC-L10-035 | Direct | The supplement's Example 2 shows an agent holding encrypted card data in and out of scope depending on isolation. |
| 12.8.x (third-party service providers) | Any external party that provides or hosts part of an AI system with access to sensitive data is a third-party service provider and 12.8.x applies in full. | AI-CTRL-014 | TC-L16-011, TC-L16-010, TC-L10-025, TC-L05-036 | Direct | The supplement lists the terms: responsibility for account data, a bar on training with entity data, sub-processor visibility, breach notification and due diligence on a set cycle. |
| 12.10.x (incident response) | Include AI failure scenarios in the incident response plan and its tests: prompt injection, model poisoning, action outside defined scope, shadow AI with sensitive data. | AI-CTRL-035 | TC-L17-018, TC-D12-001, TC-D12-013 | Direct | |
| Targeted risk analysis (not numbered in the supplement; 12.3.1 [Recalled]) | Review AI system performance at least quarterly, or at a frequency set by targeted risk analysis; validate before go-live and after any change; pin third-party model versions. | AI-CTRL-034, AI-CTRL-037, AI-CTRL-031 | TC-D08-019, TC-L16-013 | Direct | |
| Logging (not numbered; Requirement 10 [Recalled]) | Log AI systems in enough detail to validate, investigate, attribute and reconstruct AI-assisted actions, without storing account data. | AI-CTRL-008 | TC-L06-028, TC-L08-040 | Direct | |
| Penetration and segmentation testing (not numbered; 11.4.x, including 11.4.5 [Recalled]) | Include the controls that isolate AI systems in penetration and segmentation testing scope. | AI-CTRL-027, AI-CTRL-034 | TC-L10-035, TC-L06-026 | Partial | The wiki tests isolation itself; it does not cover the organisation's penetration testing programme. |
| Payment page scripts (not numbered; 6.4.3 and 11.6.1 [Recalled]) | Authorise, inventory and monitor for tampering any AI system implemented within a payment page, like other page scripts. | AI-CTRL-031, AI-CTRL-014 | TC-L05-036 | Direct | |
| Vulnerability scanning (not numbered; 11.3.1 and 11.3.2 [Recalled]) | Quarterly scans remain required; the supplement recommends continuous scanning and a rapid triage process because AI speeds up exploitation. | AI-CTRL-037 | TC-L14-023 | Partial | Register risk AI-R55 names this. The wiki sets remediation and exception time limits through AI-CTRL-037 and governs AI agents that patch; it does not cover scanning programmes themselves. See Where the wiki stops. |
Of the 14 rows, 12 are a direct match and 2 are partial.
Guidance themes to wiki controls
Securing the use of AI
| Theme (supplement section) | What it asks | Main wiki controls | Test cases | Match | Notes |
|---|---|---|---|---|---|
| Limits of AI use | The five things an AI system should not do (see above). | AI-CTRL-017, AI-CTRL-016, AI-CTRL-015, AI-CTRL-045 | TC-L10-034, TC-L09-002, TC-L01-022 | Direct | |
| AI system inputs and functional limitations | Models cannot reliably tell instructions from data, guardrails can be bypassed, and output is non-deterministic and drifts. | AI-CTRL-005, AI-CTRL-034 | TC-L07-005, TC-D08-019 | Direct | |
| Requirements, scoping and threat modelling | Define purpose, data, users and systems first; set guardrails from a threat model. | AI-CTRL-011, AI-CTRL-033 | TC-L01-002, TC-L01-005 | Direct | |
| Adaptation and provenance | Consider where the model, tools and harnesses come from, how they were trained, and whether training leaves sensitive data in model artefacts that retention and disposal rules then cover. | AI-CTRL-031, AI-CTRL-029, AI-CTRL-042 | TC-L13-006, TC-L12-008, TC-L13-019 | Direct | |
| Evaluation of deployment controls | Validate guardrails with adversarial and red-team testing before functional and user acceptance testing, and monitor closely while testing. | AI-CTRL-034, AI-CTRL-033 | TC-D08-001, TC-L07-024 | Direct | |
| Use, monitoring and revalidation | No AI system is ever finished; assume drift and keep revalidating. | AI-CTRL-034 | TC-D08-019, TC-L16-013 | Direct | |
| Internal and external AI systems | Sending sensitive data to an external AI system reduces or removes control over it; internal systems may suit more sensitive work. | AI-CTRL-007, AI-CTRL-014 | TC-L10-025, TC-L10-014 | Direct | |
| AI inventory and AI-BOM | Inventory approved systems; keep an AI-BOM per system with model and version, harness, data and system access, hosting, data use and retention, users and integrations. | AI-CTRL-031, AI-CTRL-011 | TC-L16-001, TC-L12-019, TC-L06-002 | Direct | AI-CTRL-031 now lists these fields. |
| Shadow AI | Do not rely on policy alone: restrict and monitor AI sites, scan endpoints for local AI and add-ons, allow-list software, watch for MCP traffic. | AI-CTRL-001, AI-CTRL-010 | TC-L04-002, TC-L05-031, TC-L06-003, TC-L06-037 | Direct | |
| Access and containment | Treat any AI system as a potential malicious insider; an AI system with shell access has access to everything that shell can reach. | AI-CTRL-027, AI-CTRL-016 | TC-L06-025, TC-L06-026, TC-L09-007 | Direct | |
| Human in the loop or over the loop | Answer the listed questions before letting an agent act without per-action approval; a suitable human stays accountable. | AI-CTRL-045, AI-CTRL-023, AI-CTRL-025 | TC-L01-022, TC-L06-015, TC-L01-012 | Direct | New case TC-L01-022 checks the record. |
| Credentials constrained outside the AI system | Enforce limits on agent credentials through IAM, brokered access or network controls, not the agent's own configuration; time-bound or device-bound where possible. | AI-CTRL-016, AI-CTRL-022 | TC-L09-003, TC-L09-004, TC-L09-027 | Direct | |
| Multiple agents | Split work so no single agent can complete a harmful task; guard against agents passing on untrusted prompts or colluding. | AI-CTRL-006, AI-CTRL-015, AI-CTRL-022 | TC-L06-039, TC-L06-040, TC-L06-017 | Partial | The wiki tests agent-to-agent authority and message validation. It does not test two compromised agents acting together. |
| Reliability and failure handling | Treat output as untrusted; design review against automation bias; bound autonomy by independent validation and reversibility, for example a tested rollback plan. | AI-CTRL-020, AI-CTRL-045, AI-CTRL-039 | TC-L03-040, TC-L14-023, TC-L06-023 | Direct | |
| Independent egress monitoring | DLP on AI egress that is validated and independent of the AI system; flag high-entropy, unusual structures and images. | AI-CTRL-020, AI-CTRL-017 | TC-L08-044, TC-L08-011 | Direct | |
| High-impact secrets and random values | Never let AI handle, generate or manage keys, key components or passwords; use a known-good random generator; for cryptography, only the keys and functions the agent needs, logged. | AI-CTRL-017, AI-CTRL-016 | TC-L10-034, TC-L09-016 | Direct | |
| Credentials in context | Keep AI credentials in secrets management, never in source code, prompt templates or anything that can reach the context window, output or logs; rotate any that are exposed. | AI-CTRL-016 | TC-L07-039, TC-L09-014, TC-L14-006 | Direct | |
| Account data given to AI | Prefer tokens or encryption; where cleartext is needed, use an internal AI system with input and egress controls, segmentation and protected storage and context. | AI-CTRL-017, AI-CTRL-027 | TC-L08-005, TC-L10-035 | Direct | |
| Categorising AI system risk | Use the lethal trifecta as a quick check, then categorise by autonomy, expected actions, system access and data access, judged by what is possible rather than intended. | AI-CTRL-011, AI-CTRL-037 | TC-L01-005, TC-D09-004, TC-L10-035 | Direct | The supplement gives the CUSTODY framework as one example of a categorisation scheme; this wiki has not reviewed it. The wiki's own check is question A6 of the AI Use-Case Risk Triage. |
| AI system owner | A named person or role approves deployment, defines the tasks and the data types the system may access. | AI-CTRL-011, AI-CTRL-012 | TC-L01-002, TC-L06-047 | Direct | |
| AI in "individual" and "user" roles | An AI agent may count as an individual except where responsibility or sign-off is required, high-impact secrets are involved, or actions cannot be uniquely attributed to it and to an accountable person; do a risk analysis before giving AI a user role. | AI-CTRL-015, AI-CTRL-045 | TC-L09-002, TC-D09-003 | Partial | The wiki has no case that checks that an AI system is barred from sign-off or approval functions. |
| AI-powered robotic systems | Keep robots' vision systems from seeing or recording sensitive data in secure facilities. | AI-CTRL-021 | None | Gap | The wiki does not cover physical or robotic AI. |
| AI software development | Use known-good repositories, check package provenance, and check that AI-written code has no embedded account data, keys or secrets. | AI-CTRL-004, AI-CTRL-031 | TC-L05-019, TC-L16-004, TC-L08-007 | Direct | |
| Large datasets and aggregation | AI used on large datasets such as logs can expose sensitive data or aggregate it in exploitable ways, and brings that data into scope. | AI-CTRL-017, AI-CTRL-018 | TC-L10-035, TC-L11-007 | Partial | The wiki tests access and leakage, not aggregation inference across a large log set. |
| Cleartext card data (Example 4) | Keep per-action human approval; least privilege; device-bound, time-bound, phishing-resistant credentials; no external access or untrusted input; independent DLP; fail-secure shutdown on unusual activity. | AI-CTRL-023, AI-CTRL-025, AI-CTRL-017 | TC-L06-015, TC-L08-044, TC-L09-027 | Direct |
Defending against the malicious use of AI
| Theme (supplement section) | What it asks | Main wiki controls | Test cases | Match | Notes |
|---|---|---|---|---|---|
| Continuous monitoring and rapid triage | Continuous rather than only periodic scanning, and a fast way to triage and rank the higher volume of findings and patches. | AI-CTRL-037, AI-CTRL-033 | TC-L14-023 | Partial | Register risk AI-R55 covers the patch gap. Scanning programmes for systems that are not AI stay outside the wiki; AI agents used for patching are covered by the test case. |
| AI-enabled social engineering and biometric attacks | Defend against phishing, vishing and deepfakes, and attacks on remote video and voice biometrics. | AI-CTRL-021, AI-CTRL-044 | TC-D11-017 | Partial | The wiki tests voice authentication against synthetic voices; it does not cover phishing defence in general. |
| Computationally infeasible controls | Prefer controls that are provably strong, such as cryptography and defined segmentation, over controls that only make attacks tedious. | AI-CTRL-022, AI-CTRL-027 | TC-L09-004, TC-L06-025 | Partial | Deterministic authorisation and isolation follow this idea; the wiki does not state it as a design rule. |
| Minimise blast radius | Build on the assumption of a breach and limit what one compromise can reach. | AI-CTRL-027, AI-CTRL-025 | TC-D12-009, TC-L06-023 | Direct |
Scoping an AI system for PCI DSS
The supplement's examples reduce to a few checks. Use them as a starting point for discussion with your assessor, not as a scoping decision.
- Does the AI system receive or have access to account data, or have unrestricted connectivity to systems that do? If yes, it is part of the cardholder data environment.
- Does it hold only tokens or data encrypted with strong cryptography? Then list every system and identity it can reach. If any of them can detokenise or decrypt, or can grant that access (for example an access management console), treat the AI system as having cleartext access (TC-L10-035).
- If it is isolated from those paths, the isolation controls are in scope and must be shown to work, even if the AI system itself is not.
- Include the data used for training and the data stores the AI system creates, not only the data it reads at run time.
- Where any part of the AI system is run by an external party and can reach sensitive data, that party is a third-party service provider.
Where the wiki stops
The supplement has two halves. This wiki is about the first, securing AI systems, and covers most of it. The second half, defending all systems against attackers who use AI, is recorded as register risk AI-R55, but its treatment is mostly general security practice: asset inventory, continuous vulnerability scanning and triage, patching speed, phishing-resistant authentication, segmentation, encryption and key management in a KMS or HSM. The wiki does not repeat that practice. Use PCI DSS and general security guidance for it.
The wiki also does not map the PCI PIN, PCI KMO, PCI MPoC or other PCI standards that the supplement mentions, and it does not cover AI used in PCI assessments or for making payments.
Attribution
Security Considerations for AI Systems and PCI DSS are publications of the PCI Security Standards Council. This page cites requirement numbers and paraphrases the guidance; it does not reproduce the standard. Publication of the supplement was reported in Help Net Security, 9 October 2026, read on 29 October 2026. The earlier principles are in the PCI SSC blog post AI Principles: Securing the Use of AI in Payment Environments, 11 September 2025, read on 29 October 2026. Get the supplement and PCI DSS v4.0.1 from the PCI SSC Document Library.
Related pages
- Sector Overlays
- Agent Architecture Patterns (the lethal trifecta and the Rule of Two)
- AI Use-Case Risk Triage
- NIST SSDF and SP 800-218A Crosswalk
- ISO/IEC 27001 Crosswalk
- SOC 2 Crosswalk