Regulation

The PCI Security Standards Council (PCI SSC), which writes the Payment Card Industry Data Security Standard (PCI DSS), has published an information supplement called Security Considerations for AI Systems. The Council announced it on its blog on September 15 and in a press release dated October 7. It covers two things: securing AI systems used in payment environments, and defending ordinary systems against attackers who use AI. The Council's key line on scoping is that AI should be treated "no different from any other form of technology" when deciding which PCI requirements apply.

The supplement is guidance, not a new requirement, and where it differs from a PCI standard the standard wins. It matters to any merchant or service provider whose chatbot, coding assistant or agent can see card numbers, because assessors will read PCI DSS in its light. The headline point, as Help Net Security reports it: for agents with access to cleartext cardholder data, the Council recommends explicit human approval for any action involving that data.

Where to read it, and what we could check

The full PDF sits in the PCI SSC Document Library behind a licence agreement, so we could not quote it directly. The Council's blog lists its four areas: approaching AI deployment and assessing its scope and impact, defending against AI-driven vulnerability discovery, how PCI standards apply to AI, and use-case examples. The detailed recommendations below come from Help Net Security's October 9 summary of the document, and most match the AI principles the Council posted in September 2025.

How an AI system lands in PCI scope

PCI DSS applies to the cardholder data environment (CDE), the systems that store, process or transmit card data, and to anything connected to them or able to affect their security. The guidance applies that test to AI in full. According to Help Net Security, scoping should consider how the AI system is deployed, how it is isolated, what account data it can reach, whether it can affect systems handling cardholder data, and what data it was trained on.

A customer service assistant reading tickets where customers paste card numbers is processing card data. A coding agent with write access to the payment service's repository can affect the security of the CDE. A model summarising raw application logs may hold card numbers in its context and in its vendor's retained prompts.

Tokenisation, replacing the primary account number (PAN) with a substitute value, still helps, with one catch. If the AI system can reach tokenised or encrypted data and also has a tool that can detokenise or decrypt it, that combination counts as access to readable data. An agent that holds only tokens but can call your token vault's detokenise API is in scope as if it held PANs.

What the guidance asks for

The Council's 2025 principles already set the direction: AI should not be trusted with high-impact secrets, should not hold formal responsibilities such as key custodian or management approver, should get least-privilege access under Requirement 7, and should be treated as a potential malicious insider in incident response under Requirement 12.10. They suggest payment tokens or single-use PANs for agents that make payments, with limits on amount, frequency, merchant or lifetime.

The new supplement, per Help Net Security, adds these points:

• A "least agency" approach: define each AI system's purpose, permissions and data access before you deploy it, and give it only what its tasks need.
• Enforce those limits with controls that sit outside the model, such as identity and access management policies and network isolation. Data loss prevention should also work independently of the AI.
• Avoid one AI system that combines sensitive data access, external communication and unrestricted untrusted input. If a workflow needs all three, split it across agents with different permissions.
• A suitable person should formally accept responsibility for the AI system's output.
• Credentials and keys stay in a secrets manager, out of source code, prompts, AI context, outputs and logs. Random values come from a trusted random number generator, not the model.
• Logs should support investigations without keeping sensitive payment data.
• Incident response plans and periodic tests should cover prompt injection, model poisoning and actions outside the approved scope.

On human approval, the guidance describes two models. One is approval for each task. The other is monitored autonomy, where the system takes authorised actions without per-action sign-off, but the organisation has defined the permitted actions, which ones still need approval, the triggers that shut the system down and the procedure for reversing its changes. A named person stays responsible either way. For agents with cleartext cardholder data access, Help Net Security reports the recommendation as explicit human approval for any action involving that data; we have only that one report of the exact wording.

What to change in a PCI programme

1. List every AI system that can reach card data or the CDE: vendor chatbots, IDE copilots, browser extensions, agents in the ticketing tool. Record what data each reads, which tools it can call and where its prompts and outputs are stored. Block unapproved tools found in the sweep or bring them into the inventory.
2. Redraw the scope diagram before your next annual scope confirmation under PCI DSS 12.5.2. Mark each AI system as in the CDE, connected or out of scope, with the reason. Check any agent holding tokens for a route to detokenisation, such as a support tool that reveals a full PAN on request.
3. Give each agent its own service account, never a shared admin or a person's login, and manage it under Requirement 8.6, which covers system and application accounts. Scope API keys to the methods the agent needs (Requirement 7), keep them revocable, and store them in the secrets manager, not the prompt or a config file.
4. Build the approval gate into the tool layer, where the model cannot talk its way past it. Any agent action that reads, moves, refunds or exports cardholder data waits for a human approval recorded outside the model, in the change tooling Requirement 6 already expects. If you choose monitored autonomy, document the permitted actions, the kill switch and the rollback, and test the rollback.
5. Make Requirement 10 audit logs show which agent identity ran which tool call, on whose instruction, with what result. Mask PANs before prompts and outputs reach those logs or your AI vendor, and read the vendor's retention and training terms.
6. Add two scenarios to the Requirement 12.10 incident response plan: prompt injection that makes an agent fetch or send card data, and an agent acting outside its approved scope. Name who disables it and how.

AI on the attacking side

The supplement's second half assumes attackers now use AI to find vulnerabilities faster. The Council's blog says this puts the emphasis on frequent, if not continual, vulnerability monitoring and management. Help Net Security adds the defences the document lists: limiting permissions, isolating legacy systems, phishing-resistant authentication, encrypting sensitive data and containing breaches, plus security and functional testing of AI-generated code and patches before they ship.

Our compliance and audit readiness work maps where AI tools sit against your PCI DSS scope before an assessor asks, and our AI-native systems team builds agents with scoped identities, approval gates and masked logging from the start. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: PCI SSC press release (October 7, 2026), PCI SSC blog: Just Published, Security Considerations for AI Systems, PCI SSC blog: AI Principles, Help Net Security, GlobeNewswire.