PCI SSC wants human sign-off on AI agent card data actions

The PCI Security Standards Council (PCI SSC), the industry body behind the payment card security standards that merchants and processors must follow, has released new guidance on running AI systems in payment environments. One recommendation stands out: AI agents that can see cleartext cardholder data should get explicit human approval before taking any action involving that data.

The document, titled Security Considerations for AI Systems, was developed with industry stakeholders. It covers governance, deployment, access controls, testing and how PCI standards apply to AI. It also addresses defenses against attacks that use AI. The recommendations are advisory only, and existing PCI requirements take precedence.

"As AI is increasingly used in payment environments, there is an obligation for all parties to ensure the technology is used responsibly," said Gina Gobeyn, Executive Director at PCI SSC. "This additional guidance provides a practical starting point for secure AI implementation."

Least agency and clear ownership

The Council wants organizations to define an AI system's purpose, permissions and data access before they choose or deploy it. It calls this approach "least agency": each system gets only the access and capabilities its tasks require.

A suitable person should formally take responsibility for the AI's output, and organizations should decide which actions need human approval. Access limits should be enforced by independent controls, such as identity-management policies and network isolation, not by the AI itself.

The guidance also warns against giving one AI system sensitive data access, external communications and unrestricted input from untrusted sources at the same time. If a workflow needs all three, the work should be split among agents with different permissions.

Organizations are asked to keep an AI inventory and bill of materials listing models, versions, hosting, integrations, data-use and retention policies, and intended users. An acceptable-use policy and technical controls should help find and restrict shadow AI, meaning tools staff use without approval.

Testing, autonomy and secrets

Safeguards should be tested before broad functional or user-acceptance testing, including adversarial testing to see whether restrictions can be bypassed. Monitoring and revalidation should continue after deployment, and reviewers should be aware that too much trust in AI output can make them miss mistakes.

Besides per-task approval, the guidance describes "monitored autonomy", where AI performs authorized actions under monitoring. In that model, organizations should define permitted actions, approval requirements, shutdown triggers and rollback procedures. A person still remains ultimately responsible.

AI systems should not handle, generate or manage unprotected high-impact secrets such as passwords and cryptographic keys. Credentials belong in secrets-management tools and should stay out of source code, prompts, AI context, outputs and logs. Where random values are needed, a trusted random-number generator should be used.

Encrypted or tokenized payment data is preferred, data-loss prevention should run independently of the AI, and logs should not retain sensitive payment information. For PCI scoping, an AI system with access to encrypted or tokenized data plus tools that can decrypt or detokenize it counts as having access to readable data. Training data is also in scope.

AI-assisted attacks and third parties

The Council notes that AI can speed up vulnerability discovery, exploit development and social engineering. It recommends ongoing vulnerability monitoring, limited services and permissions, isolated legacy systems, phishing-resistant authentication, encryption and breach containment.

AI-generated code and patches should go through security and functional testing, with checks for embedded credentials, unsuitable dependencies, new weaknesses and whether a fix solves the root problem. One example splits vulnerability management among agents that find issues, plan patches, test changes and deploy approved updates, with rollback tested in advance.

External AI providers with access to sensitive data should be assessed as third-party service providers. Contracts should explicitly ban using the organization's data for AI training, give visibility into subcontractors and set breach notification terms. Incident response plans should cover prompt injection, model poisoning, out-of-scope actions and unauthorized AI tools.

Our Take

The guidance is not binding, but PCI SSC documents tend to shape how auditors and assessors think. This suggests organizations deploying AI agents near payment systems may soon face questions about inventories, permissions and approval workflows, even before any formal requirement exists.

The focus on splitting agent duties and keeping secrets out of prompts mirrors problems seen elsewhere, as agentic tools gain wider access to data and systems. The scoping rule on tokenized data paired with detokenization tools is also worth noting, as it could pull some AI deployments into PCI scope that teams assumed were outside it.

It is worth watching whether future PCI DSS versions turn parts of this advice, especially human approval for cardholder data actions, into mandatory controls.