On 15 September the PCI Council published its first guidance on securing AI in payment environments. The most important line in the PCI AI guidance is printed at the foot of all 26 pages: nothing in it replaces or supersedes any PCI requirement.
Since then the headlines have been running the other way. “PCI now requires human approval for AI agent actions” is not what the document says. It is an information supplement, and an information supplement is guidance. What does have immediate consequences is a quieter sentence about scope, one that can pull new systems into your cardholder data environment without you changing a thing.
- It is guidance, not requirements. Where the guidance and a standard differ, the standard wins.
- It adds no new requirement. It tells you where AI lands inside the ones you already meet.
- An AI system with access to account data, or with unrestricted connectivity to systems that have it, is part of the CDE by definition.
- Passing cardholder data to an AI system is not prohibited. It just brings that system into scope.
- It does not cover payments made by AI agents. That document does not exist yet.
What the PCI AI guidance actually is, and what it is not
It is an information supplement at version 1.0, developed with the Global Executive Assessor Roundtable and the Board of Advisors. It covers four blocks: deploying AI systems, defending against attacks that use AI, how AI sits inside the PCI standards, and five worked use cases.
Three things it is not, which matter just as much.
- It is not a standard. The document repeats that it does not replace, extend or override any existing requirement.
- It is not about using AI in assessments. That is a separate document, “Integrating Artificial Intelligence in PCI Assessments.”
- It is not about payments made by agents. Agentic commerce is explicitly out of scope. The PCI AI guidance covers protecting the data you hand to an AI system, and protecting your environment from attackers who use AI.
The sentence that does change your scope
Here it is: when AI is used, it should be considered no different from any other form of technology when scoping the requirements that may apply. It sounds harmless. It is not.
The PCI AI guidance routes that into Requirement 12.5.2, where you confirm your scope at least annually. From now on, AI systems get reviewed there like any other component. The consequence is written without hedging. An AI system that receives or can access account data is in scope of PCI DSS. If it is instantiated with unrestricted connectivity to systems that hold account data, it is part of the cardholder data environment by definition.
Passing cardholder data to an AI system is nowhere prohibited. What happens is that the AI system comes into scope, and so do the systems it runs on.
The document grounds this in an example worth reading twice. An AI system that only sees encrypted or tokenized data may fall out of scope. But only if it is isolated from the HSM or KMS, from the systems that decrypt, and from the accounts that can use them. In that case the isolation itself is in scope, because you have to prove it isolates. If the AI is not explicitly isolated, if the isolation is insufficient, or if it can reach the access control system, it is in.
There is an operational detail most summaries miss. Those isolation controls belong in the scope of your penetration testing and segmentation testing. Configuring them is not enough, you have to have tested them.
The lethal trifecta, which is the useful shortcut
The PCI AI guidance borrows a concept you can grasp in ten seconds and use to decide quickly. One AI system should not hold all three of these at once: access to sensitive data, exposure to untrusted content, and external communications.
The logic follows. The more sensitive the data it can reach, the further it has to be kept from untrusted content and from the outside world. If a task genuinely needs all three legs, the answer is not closer supervision. It is splitting the task across several agents, each with only what its part requires. That creates two new risks the document names. One, that an agent infects another with malicious instructions that were hidden in the data. Two, that several agents end up colluding toward an outcome nobody wanted.
The Council is explicit that the lethal trifecta is at best a quick tool for thinking about risk. It does not replace a proper risk analysis or threat modeling exercise.
The MFA an AI system cannot do
This is the most concrete point in the whole document. It hits anyone carrying Requirement 8.4.2, which is multi-factor authentication for all access into the cardholder data environment.
An AI system cannot implement MFA. It can hold neither a possession factor nor an inherence factor: it has nothing and it is nobody. What the Council proposes instead is device-bound credentials, ideally cryptographic ones. Device-specific certificates with mTLS, or phishing-resistant device-bound credentials.
Three conditions come with that. The credential has to be attributable to that AI system and no other, never shared or reusable. It has to be time-bound. And an AI system must not be used to get around a place where a person would be asked for MFA.
What an AI system should never do
The guidance consolidates a minimum list of things an AI system should never be able to do. It is explicitly not exhaustive, and each entity is asked to extend it.
- 1 See cleartext high-impact secrets, such as cryptographic keys, key constituent material or passwords.
- 2 Generate randomness or secrets. AI systems are poor at entropy. Where random data is needed, give the system an interface to a known-good generator instead.
- 3 Make decisions no human can be held accountable for.
- 4 Share credentials, or act in any way that is not uniquely attributable to it.
- 5 Reach systems it does not need for the task it was given.
One line in the document summarizes the rest. An AI system does not remember things, it stores them. If something may not be stored in cleartext, it should not be given to an AI system in cleartext.
When the AI belongs to someone else
The guidance is blunt here. Where any part of an AI system is provided or hosted by an external party, and it has access to sensitive data, that provider is a third-party service provider. Requirements 12.8.x apply in full.
That includes a category many organizations have not counted as AI at all: the AI built into other products. Document readers, content creation tools and, above all, chat widgets sitting on the payment page. Those widgets also have to be authorized, inventoried and monitored for tampering like any other payment page script. Those are Requirements 6.4.3 and 11.6.1, which you will recognize if you read what moved in the SAQ A eligibility line.
In practice that means five things. A written agreement that allocates responsibility for the data. An explicit bar on using your data to train models. Visibility of sub-processors, and breach notification terms. And due diligence evidence reviewed on a set cycle.
What to do this week
Five small things, all of them expected by the PCI AI guidance, and all of them applicable to whatever AI you already have running.
- 1 Inventory it. AI systems belong in the component inventory under Requirement 12.5.1 and in the data flow diagrams under 1.2.4. The Council’s rule is flat: no AI system gets access to data the entity has not classified and mapped.
- 2 Count what the AI creates. Prompt and response logs, transcripts, caches, session state, temporary memory, tool results and orchestration state. Each is a data store, and cardholder data gets masked before anything is written.
- 3 Give it an owner and a review. One named person approves the deployment, the tasks it may perform and the data it may reach. Review at least quarterly, or at whatever cadence a targeted risk analysis justifies.
- 4 Go looking for shadow AI. An acceptable use policy, a list of sanctioned tools, and some real means of finding the unsanctioned ones. Policy compliance alone is not a control.
- 5 Put it in the response plan. Requirement 12.10.x asks for a tested plan. Add AI-specific scenarios, such as a successful prompt injection or an autonomous action outside the defined scope, even if neither has happened to you yet.
Where we fit
Almost none of this is solved by buying something. It is scope, inventory and written justification, which is exactly where most assessments come apart. That is the work in PCI DSS consulting inside the wider PCI DSS practice, and it starts from the same place as the checklist that survives a QSA.
Of the requirements named above, logging and monitoring rest on managed SIEM. Agent credentials and access rest on critical access control. Defending against attackers who already use AI is the less discussed half of the document. It comes down to continuous scanning and fast triage, which is vulnerability and exposure management. Talk to the team.
Sources
- PCI Security Standards Council, publication announcement for “Security Considerations for AI Systems”, 15 September 2026.
- PCI Security Standards Council, “Security Considerations for AI Systems,” information supplement version 1.0, September 2026. Scope, the lethal trifecta, Requirement 8.4.2 and the use cases all come from there.
- PCI Security Standards Council, document library, which also holds “Integrating Artificial Intelligence in PCI Assessments.”
- References cited by the guidance itself: ISO/IEC 42001 for an AI management system, and the NIST AI Risk Management Framework.
