What the PCI SSC's New AI Guidance Means for Your Cardholder Data Environment

Most payment businesses already run AI somewhere near card data. A support chatbot handles refund requests. A fraud model scores every authorisation. An engineer asks a coding assistant to patch the checkout service. Until this autumn, there was no Council-level answer on how any of that should be handled in a PCI DSS assessment.

The PCI Security Standards Council has now published one. Its PCI DSS AI guidance, an information supplement titled Security Considerations for AI Systems, came out in September 2026, and the Council formally announced it on 7 October 2026 at its Europe Community Meeting in Edinburgh. The document does not add new requirements. What it does is tell merchants, service providers and assessors how the existing ones apply when an AI system sits inside, or next to, the cardholder data environment (CDE).

Below is a practical reading of the guidance for the people who own a CDE: security leads, compliance managers and engineering heads at payment companies, fintechs and e-commerce businesses.

What the PCI SSC actually published

The supplement was written with the Global Executive Assessor Roundtable (GEAR) and the Council's Board of Advisors. It covers four areas:

• AI deployment and use: how to assess the scope and impact of putting an AI system into a payment environment.

• Defending against malicious use of AI: how attackers use AI and what that means for vulnerability management.

• PCI standards and AI use: how existing requirements map onto AI systems.

• Use-case examples: worked scenarios of AI deployed and assessed in payment environments.

The Council is explicit that the document is guidance. Where it differs from a PCI standard, the standard wins. It sits alongside an earlier Council document, Integrating Artificial Intelligence in PCI Assessments, which deals with assessors using AI during their own work rather than with merchants deploying it.

The central position is simple. When AI is used, it is treated like any other technology for scoping purposes. There is no separate AI compliance track. Advisory status should not be read as "safe to ignore". GEAR is a group of senior assessors, and the people who helped write this guidance are the same people who sign Reports on Compliance. Expect QSAs to use it as their reference point when they ask how your AI systems were scoped and controlled.

Scoping: when an AI system enters your CDE

An AI system can land in PCI DSS scope without ever seeing a card number. The guidance asks you to look at four things when scoping it: where it is deployed, how well it is isolated, whether it can reach account data (including data used to train it), and whether it can affect the security of systems that store, process or transmit cardholder data.

One point will catch teams that rely on tokenisation. If an AI system can read encrypted or tokenised data and also has access to a tool that decrypts or detokenises it, the guidance treats that as access to readable data. Tokenisation only reduces scope when the AI cannot reverse it.

An accurate data-flow diagram is still the starting point. Add every AI system, its integrations and its data stores to it, then decide scope the same way you would for a new database or SaaS tool.

Securing AI in payment environments: least agency and access control

The guidance asks organisations to define an AI system's purpose, permissions and data access before choosing or deploying it. It calls the approach "least agency": each system gets only the access and capabilities its assigned tasks need. Anyone familiar with Requirement 7 will recognise the idea, applied now to software that decides its own next step.

Those limits have to be enforced outside the model. A system prompt telling an agent "never read the payments table" is an instruction, and instructions can be overridden. The guidance points to independent controls such as identity and access management policies and network isolation.

The combination to avoid

The most practical line in the document concerns three capabilities that should not sit together in one AI system:

• access to sensitive data

• the ability to communicate externally

• unrestricted input from untrusted sources
  

Put all three in one agent and a single malicious email, web page or support ticket can instruct it to collect card data and send it out. Where a workflow genuinely needs all three, the guidance recommends splitting the work across separate agents with different permissions, so no single agent holds the full chain.

Know what you are running

The Council also recommends an AI inventory, sometimes called an AI bill of materials. For each system it should record the model and version, where it is hosted, what it integrates with, its data-use and retention policies, and who is meant to use it. This fits naturally into the inventory of in-scope system components you already maintain under Requirement 12.

The inventory only works if it is complete. An acceptable-use policy backed by technical controls helps find and block shadow AI, meaning tools staff adopt without approval. A browser extension that summarises customer emails is an AI system in your environment whether or not anyone signed off on it.

AI agents and PCI compliance: where human approval fits

The guidance names a suitable person who formally accepts responsibility for an AI system's output. That person stays accountable even when the system acts on its own. Organisations are also asked to list which actions need human approval before they run.

Two operating models are described:

For agents that can reach cleartext cardholder data, the guidance recommends explicit human approval for any action involving that data. Monitored autonomy is a reasonable fit for an agent that triages alerts. It is a poor fit for one that can issue refunds or export transaction records.

The Council also flags a quieter risk: people trust AI output too much. A reviewer who approves fifty correct suggestions in a row will likely miss the fifty-first. Review processes need to account for that, through sampling, rotation or second-person checks on high-impact actions.

Testing gets an order of operations too. Safeguards should be tested before extensive functional or user-acceptance testing, and that testing should include adversarial attempts to get around the restrictions. Monitoring and revalidation then continue for as long as the system runs, because model behaviour can drift after an update or a change in the data it sees.

Keeping card data, secrets and logs out of the model

AI systems should not handle, generate or manage unprotected high-impact secrets such as passwords and cryptographic keys. Credentials belong in a secrets manager and should stay out of source code, prompts, AI context windows, outputs and logs. When a random value is needed for a password or key, the guidance points to a trusted random-number generator, and those values may need to stay outside the AI system entirely.

On payment data, the advice is to give AI systems encrypted or tokenised data wherever the task allows. Data-loss prevention should run independently of the AI, so a manipulated model cannot switch off the control meant to catch it.

Logs deserve a closer look than most teams give them. Prompt and response logging is useful for investigations, but a log that captures a customer typing their card number into a chat window is now stored account data, with all of Requirement 3 attached. The guidance asks for logs that support investigation without keeping sensitive payment information. In practice that means masking or filtering at the point of capture, before anything reaches the logging pipeline or the AI vendor's retention store.

AI in payment security: defending against AI-assisted attacks

A large part of the supplement is about attackers. The Council's view is that AI speeds up vulnerability discovery, exploit development and social engineering. A weakness that once took weeks to find and weaponise can now be found and tested much faster, and phishing messages read more convincingly.

The response it recommends is ongoing vulnerability monitoring, frequent if not continuous, with a clear process for prioritising findings and patches. A quarterly scan and an annual penetration test still satisfy their own requirements, but they leave long gaps if an attacker is scanning daily with automated tools.

The defensive measures listed are familiar ones, applied with more urgency:

1. limit running services and account permissions

2. isolate legacy systems that cannot be patched quickly

3. use phishing-resistant authentication

4. encrypt sensitive data

5. design the environment so a single breach has limited reach

AI-written code needs the same scrutiny as human code

AI-generated code and patches should go through security and functional testing before release. Reviews should check for hard-coded credentials, unsuitable or unvetted dependencies, newly introduced weaknesses, and whether the fix actually addresses the underlying problem or only the symptom. For bespoke payment software, this sits squarely within the secure development expectations of Requirement 6.

One of the Council's use-case examples shows how AI can help here without holding too much power. Vulnerability management is split across agents: one identifies issues, one prepares a patching plan, one tests changes, and one deploys only approved updates. Each has role-based permissions, and rollback procedures are tested before anything is deployed.

Third-party AI providers and incident response

If an external AI provider can access sensitive data, the guidance says to assess it under the third-party service provider requirements you already apply (Requirement 12.8). Contracts should cover:

• who is responsible for the sensitive information the provider handles

• an explicit ban on using your data to train the provider's models

• visibility into the provider's subcontractors

• breach notification terms

A standard API agreement from a model vendor rarely covers all four out of the box. Procurement and security teams should check before card data, or anything that can reach it, flows to that vendor.

Plan for an agent that goes wrong

Incident response plans and their periodic tests should now cover AI-specific scenarios. The guidance lists prompt injection, model poisoning, an AI system acting outside its approved scope, and unauthorised AI tools reaching sensitive data.

A useful way to frame this for your team is to treat a compromised agent much like a compromised insider account. It holds legitimate credentials, it acts at speed, and its activity can look normal in the logs. Your plan should say how an agent's activity is spotted, how it is shut down, and how its changes are rolled back. Those answers belong in the plan you test under Requirement 12.10, not in a separate AI policy nobody rehearses.

A working checklist for your CDE

If you are preparing for your next assessment, these are the questions to settle first:

• Is every AI system that touches, or can affect, the CDE listed in your inventory and data-flow diagrams?

• For each one, have you recorded its purpose, permissions, data access and the person accountable for its output?

• Are its access limits enforced through IAM and network controls rather than prompt instructions?

• Does any single agent combine sensitive data access, external communication and untrusted input?

• Which actions need human approval, and are agents with cleartext card data access held to approval on every data action?

• Are secrets kept out of prompts, context and logs, and is card data masked before it reaches any AI log or vendor?

• Is AI-generated code reviewed and tested like any other change to payment software?

• Do contracts with AI providers prohibit training on your data and set breach notification terms?

• Does your incident response plan name AI-specific scenarios, and have you tested them?
  
  Accorp Partners is a PCI SSC Qualified Security Assessor firm. Our team can map the AI systems in your environment, test them against the Council's guidance during a gap assessment, and carry that work into your formal RoC or SAQ. Talk to our PCI DSS team about bringing your AI deployments into scope the right way.
  

Frequently Asked Questions

1. Is the PCI SSC's AI guidance mandatory?

No. The Council describes it as guidance, and where it conflicts with a PCI standard, the standard applies. The requirements it points to are mandatory, though, and assessors helped write it, so it will shape how they evaluate AI systems in your environment.

2. Does using a third-party AI model bring the provider into PCI DSS scope?

It does if the provider can access account data or affect the security of your CDE. In that case you assess the provider under the third-party service provider requirements, the same way you would a hosting or payment vendor.

3. Can an AI system be in scope if it never sees card numbers?

Yes. An agent that can change firewall rules, access policies or other controls protecting the CDE can affect its security, and that is enough to bring it into scope.

4. Do AI agents need human approval for every action?

Not always. The guidance allows monitored autonomy for pre-authorised actions with defined limits, shutdown triggers and rollback. For agents that can access cleartext cardholder data, it recommends explicit human approval for any action involving that data.

5. Can we let customers share card details with an AI chatbot?

You can, but the chatbot, its transcripts, its logs and any vendor that stores them then fall within scope. Most businesses are better off routing payments to a hosted payment field or a tokenised flow and keeping card data out of the conversation entirely.