PCI SSC Guidance On Securing AI In Payment Environments: It Is Not Mandatory, So Map Your AI To The Requirements That Are

On 7 October 2026, ahead of its Europe Community Meeting in Edinburgh on 20 to 22 October, the PCI Security Standards Council published additional guidance on securing AI in payment environments. The Council describes it as a practical starting point: how organisations can secure AI systems while keeping their existing controls in place, how to deploy AI in ways that reduce the risk of misuse, how AI fits within the existing PCI standards, and a set of real world use case examples. It was developed with the Global Executive Assessor Roundtable and the PCI SSC Board of Advisors, which matters, because it signals how assessors are likely to think about AI in the cardholder data environment over the next assessment cycle.

The most important sentence in the announcement is the one that will get the least attention. The guidance is not mandatory, and where it differs from a PCI standard, the standard takes precedence. That is the normal status of a PCI information supplement, and it means you cannot pass or fail an assessment against this document. What you can fail is PCI DSS v4.0.1, and every AI tool, model integration and agent that touches, connects to or can affect the security of your cardholder data environment is already in scope for it. The guidance does not create new obligations for AI. It tells you the old ones already apply.

So the useful exercise is not to read the guidance as a checklist, but to use it as a prompt to map your AI estate to the requirements an assessor will test. Start with scope. Requirement 12.5.2 asks you to confirm PCI DSS scope at least once every twelve months and after significant change, and connecting a coding assistant, a support chatbot or an autonomous agent to systems in or connected to the CDE is a significant change. Write down every place AI meets payment data: a support agent that can see order records, a Cursor or Claude Code session with credentials to a production database, a fraud model fed with transaction data, a voice agent built on ElevenLabs that takes card details over the phone. Each one is either in scope, connected to scope, or demonstrably segmented, and you need evidence for which.

Next, treat the AI provider as what it is under PCI DSS: a third party service provider. Requirement 12.8 asks you to keep a list of TPSPs, have written agreements in which they acknowledge responsibility for the account data they handle, perform due diligence before engagement, monitor their compliance status at least annually, and, under 12.8.5, keep a record of which requirements are managed by you, by the provider, or shared. If prompts, transcripts or tool calls can contain primary account numbers, your model vendor belongs on that list. Ask for its Attestation of Compliance, or document why one is not needed because account data never reaches it. A SOC 2 report or an ISO 27001 or ISO 42001 certificate is useful supporting evidence, but none of them is a PCI DSS attestation.

Then look at identity and access, which is where agents create the most new risk. Requirement 7 asks for least privilege, and requirement 8.6 governs system and application accounts that can be used interactively, including how their credentials are protected and how their use is managed. An agent with a database connection string or an API token is exactly that kind of account. Give each agent its own identity rather than a shared service account, scope it to the minimum data and actions it needs, keep its secrets out of prompts and configuration files, and rotate them on the schedule your targeted risk analysis under 12.3.1 supports. If an agent can take an action a human operator could not, that is a finding waiting to happen.

Data handling and logging follow the same logic. Requirement 3 restricts storage of account data and sensitive authentication data, which includes logs, transcripts and vector stores, so a retrieval index built from support tickets that contain card numbers is stored cardholder data whether you meant it to be or not. Requirement 10 asks you to log access to system components and cardholder data and to be able to reconstruct who did what. For an agent, that means recording the tool calls and actions it took against in scope systems, tied to its own identity, not just the chat text. Requirement 6.4.3 on payment page scripts is still in force, and it now applies to checkout pages generated by Lovable, Bolt or v0 as much as to hand written ones, so keep the script inventory and authorisation evidence current.

Bespoke and custom software rules apply to AI generated code too. Requirement 6.2 asks for secure development of bespoke and custom software, including code review before release, and 6.3.2 asks for an inventory of that software and its third party components. Code written by Copilot, Cursor, Claude Code or Devin is bespoke software the moment you ship it. The model is not a reviewer of record, so make sure a qualified human, or a review process you can evidence, signs off changes that touch payment flows, and that your dependency inventory catches the packages an assistant pulled in on its own.

The compliance platforms can help with the evidence, but check what they actually map. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof all ship PCI DSS v4.0.1 frameworks, and several now ship ISO 42001 and AI governance modules alongside them. What most do not do automatically is connect the two: they will not tell you that a new AI integration changed your CDE scope, or that an agent identity is an application account under 8.6. Ask your vendor whether its PCI framework can tag AI systems and agents as in scope assets, and whether its TPSP register can hold model providers with their attestation status. If not, keep that mapping yourself and link it as evidence.

A short plan before your next assessment. Read the PCI SSC guidance and note which of its use cases resemble your own. List every AI system and agent that touches or connects to the CDE, and record the scope decision for each under 12.5.2. Add model and agent vendors to your TPSP register with a responsibility matrix under 12.8.5. Give every agent its own least privilege identity and log its actions under requirement 10. Check transcripts, logs and vector stores for account data under requirement 3. And if you are attending Edinburgh, the sessions on AI agents in the cardholder data environment and on accountability between human and machine are the best preview of the questions your assessor will ask next year. Our PCI DSS requirements pages and AI governance guides cover each of these requirements in more detail.