PCI SSC's AI Security Supplement: Agents, Scope and Human Approval

On 15 September 2026, the PCI Security Standards Council published an information supplement, "Security Considerations for AI Systems," and followed it with a press release on 7 October 2026. The document covers how to deploy and use AI in payment environments, how to defend traditional systems against AI-powered attacks, and how AI fits within existing PCI standards. It is not a new requirement. The Council says plainly that the supplement "serves as guidance and is not to be considered as mandatory requirements," and that PCI standards take precedence if the two ever conflict.

What's affected

The Council developed the supplement with its Global Executive Assessor Roundtable and Board of Advisors. Its blog post lists four areas: AI deployment and use, defending against malicious use of AI, how PCI standards apply to AI, and use-case examples.

The Council's core scoping position is that AI should be treated like any other technology when deciding which PCI requirements apply. Help Net Security's review of the document, published 9 October, lists the specific recommendations:

Agents and permissions

• Define each AI system's purpose, permissions and data access before you select or deploy it, and limit it to what its tasks need, which the supplement calls a "least agency" approach.
• Enforce those limits with independent controls such as identity policies and network isolation, not with instructions to the AI.
• Avoid combining sensitive data access, external communications and unrestricted untrusted input in one AI system. If a workflow needs all three, split it across agents with different permissions.

Human approval

• Decide which actions need human approval. Per-task approval is one option. "Monitored autonomy" is the other, which requires defined permitted actions, shutdown triggers and procedures for reversing changes.
• For agents with access to cleartext cardholder data, the supplement recommends explicit human approval for any action involving that data.
• A suitable person should formally accept responsibility for AI output.

Scope, logs and data

• Scoping should consider where the AI runs, how it is isolated, its access to account data including training data, and its ability to affect cardholder data systems.
• Access to encrypted or tokenized data plus tools that can decrypt or detokenize it should be treated as access to readable data.
• Keep credentials, source code, prompts, AI context and outputs out of logs, while still keeping logs useful for investigations.
• Run DLP independently of the AI system.

Vendors and code

• Assess external AI providers that touch sensitive data under existing third-party service provider requirements. Contracts should forbid training on your data, show subcontractors and set breach notification terms.
• Test AI-generated code and patches for embedded credentials, unsuitable dependencies and new weaknesses.
• Monitor vulnerabilities continuously. The Council's own summary stresses frequent, if not continual, vulnerability management because AI is speeding up vulnerability discovery.

Does this apply to you?

The supplement creates no new obligation. It applies in a practical sense if:

1. You are in scope for PCI DSS and use, or plan to use, AI anywhere that can reach cardholder data or affect systems that do.
2. You build payment software with AI features or use AI coding tools on payment code. Your customers' assessors may use this document to frame questions.
3. You run AI agents in operations, such as support, fraud review or patching, with any path to the cardholder data environment.
4. You are an assessor looking for a common reference on AI in payment environments.

What to do now

1. By 31 October 2026: list every AI system and AI-enabled vendor service that can touch cardholder data or connected systems. Include coding assistants used on payment code.
2. By 15 November 2026: for each agent, write down its purpose, permissions and data access. Remove anything not needed. Confirm the limits are enforced outside the model.
3. By 30 November 2026: decide which agent actions need human approval. For any agent that can read cleartext card data, require approval for actions involving that data.
4. By 31 December 2026: check logs for prompts, context, outputs or credentials that should not be there. Move DLP outside the AI path.
5. At next contract renewal: add no-training clauses, subcontractor visibility and breach notification terms for AI providers that handle sensitive data.
6. Ongoing: treat AI-written code like any other contribution. Scan it for secrets and vulnerable dependencies before merge.

Why it matters

The Council did not write new AI rules into PCI DSS. It said existing rules already apply to AI, and then described how. That is useful, because it removes the argument that an AI tool is out of scope because it is "just a model." If it can reach the data or the systems, it is in scope.

The "least agency" idea is the part to adopt everywhere, not only in payments. An agent with broad standing permissions turns one bad instruction into a breach. Narrow, enforced permissions and a human gate on sensitive actions keep a mistake small.

Try it yourself

Pick one AI feature or agent in your stack. Write down the model, the provider, the data it can read, the tools it can call and the credentials it holds. If you cannot fill in every line, you have found the first gap. An AI bill of materials makes this inventory repeatable.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• PCI SSC: Just Published, Security Considerations for AI Systems (15 September 2026)
• PCI SSC press release: PCI SSC Publishes Additional Guidance on Securing AI in Payment Environments (7 October 2026)
• Help Net Security: PCI SSC calls for human approval of AI agent actions involving cardholder data (9 October 2026)