- The PCI Security Standards Council published advisory guidance on AI in payment environments. It says a suitable person should accept responsibility for AI output and that some actions need human approval.
- It advises against giving one AI system card data access, outside contact and untrusted input together. Where a workflow needs all three, it says to split the duties among agents.
- Leaders should ask for an AI inventory, access controls the AI cannot override, and defined shutdown triggers and rollback procedures.
An AI agent can read, decide and act faster than any employee. It cannot be held to account. New guidance from the PCI Security Standards Council targets that gap. Its answer is old-fashioned: have a person take responsibility.
What the Council published
The Council released Security Considerations for AI Systems. It covers two things. One is how to protect data given to AI in payment environments. The other is how to defend against attacks that use AI. Industry stakeholders helped develop it.
The advice is not binding. Existing PCI requirements take precedence. Even so, it signals how the body behind card-data rules is thinking about AI.
Gina Gobeyn, the Council's Executive Director, said the guidance "provides a practical starting point for secure AI implementation."
A person takes responsibility for the output
The Council says a suitable person should formally take responsibility for what an AI produces. Firms should also decide which actions need a human to approve them.
The guidance sets out two ways to work. In one, a person approves every task. In the other, the AI acts within set limits while people monitor it. No one signs off on each step.
The second way still needs rules. Before running an AI like this, a firm should write down what it may do and when approval is needed. It should also set what triggers a shutdown and how changes get undone. A person stays ultimately responsible.
One case is stricter. If an agent can reach cleartext cardholder data, the Council recommends explicit human approval for any action that touches it.
Three things that should not share one system
The most useful advice for executives concerns combinations. The Council says to avoid giving one AI system all three of these: sensitive data, contact with the outside world, and open input from sources you do not trust.
Consider why. An agent that reads outside text can be handed instructions hidden in that text. This is called prompt injection. Suppose the same agent can see card data and send messages out. A planted instruction could then move data out. Remove any one of the three, and that path narrows.
That explanation is ours, not the Council's. Its own remedy is plain. If a workflow needs all three, split the work among agents with different permissions.
Banks have long split duties so that one person cannot both start and approve a payment. In effect, the Council applies the same logic to software that acts. That comparison is ours, not the Council's.
Controls the AI cannot override
The Council wants access limits enforced by controls outside the AI. Examples are identity-management policies and network isolation. A model told to behave is not a control. A permission it cannot override is.
The data advice follows the same idea. Data-loss prevention should work independently of the AI. AI systems should not handle unprotected passwords or cryptographic keys. Credentials belong in secrets-management tools. They should stay out of prompts, AI context, outputs and logs.
One point matters for audits. Encrypted or tokenized data can look safe. But if the AI can also use a tool that decrypts or detokenizes it, treat that as access to the readable data.
Faster attackers, and reviewers who trust too much
The Council warns that AI can speed up three things: finding vulnerabilities, building exploits and social engineering. Its defenses are familiar. Limit services and permissions. Isolate legacy systems. Use phishing-resistant authentication. Contain the damage from breaches.
It also names a human weakness. People can trust AI output too much and miss its mistakes. The Council says review processes should allow for this. A person in the loop helps only if that person still checks.
AI-written code and patches need security and functional testing. Reviewers should look for embedded credentials, unsuitable dependencies and new weaknesses. They should also check that a fix addresses the underlying problem.
One example splits vulnerability management across agents. Some find issues, some plan patches, some test changes and some deploy approved updates. Permissions follow roles. Rollback is tested before deployment.
Questions to put to your team
Ask for a list of every AI system near payment data. The Council suggests recording the models and versions, where each is hosted and what it connects to. It also suggests data-use and retention policies, and who the system is for.
Ask who has formally accepted responsibility for each system's output. A team name is not a person.
Ask whether any one system combines card-data access, outside communication and untrusted input. If so, ask how the duties will be split.
Ask what stops an agent from going beyond its scope if the model misbehaves. A good answer names identity or network controls. A prompt instruction is not an answer.
Ask what shutdown triggers and rollback procedures are defined for any agent that acts without approval for each step. Testing rollback is the Council's advice in its patching example.
Ask about shadow AI and vendors. The guidance calls for an acceptable-use policy and technical controls against unapproved tools. It also wants provider contracts that bar training on your data, show subcontractors and set breach-notice terms.
Finally, ask whether incident response drills cover prompt injection, model poisoning and actions outside approved scope.
The lesson here is simple. As software gains the power to act, the scarce resource becomes a person willing to answer for it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Help Net Security.
