PCI DSS v4.0 applies to every system that stores, processes or transmits cardholder data, and to everything connected to it. If an AI agent can see a full card number, the agent, its model endpoint, context, logs and tools all enter scope. The better design keeps agents out of scope: they see only tokens and masked numbers.
What does PCI DSS require, in plain words?
PCI DSS is the security standard the card brands require of anyone handling payment card data. It protects two kinds of data. Cardholder data includes the primary account number (PAN), with the cardholder name and expiry date when stored alongside it. Sensitive authentication data includes the card verification code, full track or chip data, and PINs.
The core rules are easy to state and hard to meet:
- Do not store sensitive authentication data after authorisation, even encrypted.
- Store as little cardholder data as possible, and render the PAN unreadable wherever it is stored.
- Mask the PAN when displayed, so only people with a business need see more.
- Restrict access to cardholder data by need to know, with unique IDs and strong authentication.
- Log and monitor every access to system components in the cardholder data environment.
- Develop software securely, manage vulnerabilities and test security regularly.
- Manage third-party service providers that touch the data, with clear division of responsibilities.
Version 4.0 added targeted risk analyses for some requirements and a customised approach that lets an entity meet a requirement's objective in its own way, with evidence.
Who does it apply to?
Merchants, issuers, acquirers, processors and service providers that store, process or transmit card data, and any system component within or connected to the cardholder data environment. Banks issuing cards, payment firms acquiring merchants and businesses taking card payments all qualify.
A model provider that receives card numbers inside prompts becomes a third-party service provider for PCI purposes. That is rarely what anyone intended when they connected a support agent to a chat channel.
What happens when the system is an agent that acts?
Agents pull data from many places and pass it to many others. That makes scope spread fast.
Consider a support agent that helps a customer dispute a charge. If it queries the card system and receives the full PAN, the PAN enters the agent's context. From there it can reach the model provider, the conversation transcript, the observability traces, any cache and the evaluation sets built from past conversations. Each becomes part of the cardholder data environment and needs every control that implies.
Now consider the same agent working with a token. It receives a card reference and a masked number showing only the last digits. It can identify the card to the customer, raise the dispute and freeze the card through the card management system, all without seeing the PAN. Scope stays where it was. We make that case in our answer to whether an agent should ever see full card numbers, and the answer is almost always no.
Actions on cards also carry their own limits, separate from PCI. Freezing a lost card is routine depth 3 work. Raising a spending limit is not, as our piece on whether an agent can change card spending limits explains.
How do you meet PCI DSS with agents in the picture?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Keep scope small | Agents receive tokens and masked PANs only; card system returns no raw PAN to agent tools | Tool response schemas and integration tests |
| No sensitive authentication data stored | Agent channels block entry of card verification codes; detected values are dropped before processing | Detection rules and blocked-input logs |
| PAN unreadable where stored | Transcripts and logs redacted at write; periodic scans for card numbers | Data discovery scan results |
| Need-to-know access | Agent's connections scoped to the card operations it is certified for | Permission records per agent and capability |
| Logging and monitoring | Every agent call to the card system logged with identity and purpose | Append-only action log |
| Third-party management | Model provider and agent platform assessed for PCI responsibility if any card data can reach them | Responsibility matrix and provider attestation |
| Secure development and change | Agent brief, tools and connections change only through reviewed releases | Change records and pre-release tests |
The integration point is where most of this is won or lost. Our playbook on how to connect an AI agent to your card management system covers token-only interfaces and capability scoping. For what happens to data inside prompts and transcripts, see PCI DSS and card data in agent prompts and logs.
Acquirers using agents in onboarding face a related question. Merchant applications include bank details and identity documents rather than card data, but the agent should not need access to the acquiring platform's card flows at all. Our playbook on merchant onboarding for card acquiring with an agent shows the split.
What will a qualified assessor ask?
- Can any agent receive a full PAN from any tool, channel or file?
- Show us the data flow for a card dispute handled by the agent.
- What happens when a customer types a card number into chat?
- Where are agent transcripts stored, and how do you know they hold no card numbers?
- Is the model provider in scope, and what is their responsibility?
- Which agent actions on cards are allowed, and who approved each?
What does PCI DSS not cover?
PCI DSS protects card data. It does not decide whether an agent should freeze a card, raise a limit or refund a charge; those are conduct, fraud and operational risk questions. It does not govern personal data beyond card data, which falls under data protection law. It does not address agent-specific risks such as prompt injection or excessive agency, which the OWASP Top 10 for LLM Applications covers. For the wider limits on banking agents, see what AI agents in banking may and may not do.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Does tokenisation take an agent fully out of PCI scope?
It removes the agent from the cardholder data environment if it never receives raw card data and cannot detokenise. Connected systems may still need some controls, so confirm scope with your assessor.
Can an agent take a card payment over chat?
It should hand the customer to a secure payment page or a hosted field that keeps the card number away from the agent. The agent then receives only a token and the result.
Is the model provider responsible for PCI if card data reaches it?
It becomes a service provider in scope, but your organisation remains responsible for its own compliance. The cleaner answer is to make sure card data never reaches it.