Card numbers leak into AI agents through the side door: a customer pastes one into chat, a tool returns one in a record, a transcript keeps one forever. Under PCI DSS, every place card data reaches is in scope. Stop it at the edge, redacting before the prompt is built, and prove it by scanning everything the agent stores.
What does PCI DSS require for prompts and logs?
PCI DSS v4.0 does not mention prompts, but its rules apply to them as to any other data store or transmission. Three requirements matter most here.
Sensitive authentication data, such as card verification codes and full track data, must not be stored after authorisation. A transcript holding a verification code breaks that rule outright. The primary account number must be rendered unreadable wherever it is stored, which includes log files, debugging output and backups. And any system that stores, processes or transmits card data joins the cardholder data environment, with all its controls.
The standard also expects you to know where card data lives. In practice that means data discovery: scanning stores for card numbers and acting on what you find.
Who does it apply to?
Any organisation subject to PCI DSS that runs AI agents in channels where card data can appear: issuers and acquirers, payment firms, and merchants with customer service agents. It applies whether the agent was built in-house or bought, and whether the model runs on your infrastructure or a model provider's.
Our companion piece on PCI DSS and agents that handle card data covers the design principle of keeping agents out of scope through tokens. This article is about the leaks that happen even when that principle is followed.
Where does card data enter an agent?
An agent's working memory is assembled from many inputs, and each is a route for card data.
Customer input. People type card numbers into chat because they want help with a card. Some type the verification code too. The agent did not ask; it still received it.
Tool outputs. A legacy card system returns a full PAN in a field nobody thought the agent would read. A ticketing system holds an old ticket where a colleague pasted one.
Documents. A scanned statement or a screenshot uploaded by a customer contains a card number. If the agent reads images, it reads that too.
Agent memory. Summaries, conversation history and retrieval indexes built from past conversations carry whatever was in those conversations.
Then it leaves through more routes: the model provider's request logs, the platform's transcripts, observability traces, error reports, analytics exports and the test sets built from real cases. Our answer on handling personal data in agent logs covers the general case; card data is stricter because the standard is prescriptive.
How do you keep card data out?
Put the controls at the edge, before the prompt is assembled, and check the result where data comes to rest.
| Requirement | Control | Evidence it leaves |
|---|---|---|
| No verification codes stored | Input filter detects codes in card context and drops them before the agent sees them | Filter rules and drop counts |
| PAN unreadable at rest | Card numbers detected by pattern and checksum, replaced with a token or mask before the prompt is built | Redaction logs with counts, not values |
| Tool outputs are clean | Tool responses pass through the same filter; card fields removed from agent-facing schemas | Schema definitions and filter test results |
| Documents are clean | Uploaded images and files redacted before the agent reads them | Redaction records per file |
| Stores stay clean | Scheduled scans of transcripts, traces, indexes and test sets for card numbers | Scan results and remediation tickets |
| Providers see nothing | Model provider receives only redacted prompts | Sampled outbound prompt checks |
| Retention is short | Transcripts kept only as long as needed, then deleted | Retention settings and deletion logs |
Two design choices make the difference. First, redact before the model, not after: a filter on the transcript does not help if the raw number already went to the model provider. Second, tell the customer. When the filter removes a card number, the agent should say it cannot accept card details in chat and offer a secure route, so the customer does not try again.
Customer conversations about suspicious transactions are a common source of leaks. Our playbook on how to confirm suspicious card transactions with customers builds the redaction step into the flow. For which card actions an agent can safely take once data is clean, see our note on card operations work at depth 3.
What will an assessor ask?
- What stops a customer's card number reaching the model?
- Show us a test where a card number and verification code are entered into chat.
- Which stores hold agent transcripts, traces and indexes, and when were they last scanned?
- What did the last scan find, and what happened next?
- Do evaluation and test sets contain real card data?
- Does the model provider retain prompts, and for how long?
What does PCI DSS not settle here?
The standard tells you to protect card data. It does not tell you how to protect other personal data in the same transcripts, which falls under data protection law and its principles on minimisation and retention. It does not cover prompt injection, where hostile text in an input tries to make the agent reveal or move data; the OWASP Top 10 for LLM Applications addresses that. And it does not decide which card actions an agent may take. For the boundaries on banking agents generally, 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.
Where Pryme fits
Pryme Context Protocol stamps every fact reaching an agent with its source, so a redaction step is recorded as part of the input's provenance. Agents connected to card systems receive token-only responses, and the verdict record stores actions without card values. Scans of what the agent keeps can then be checked against a record that should never hold a PAN.
Questions people ask
Is masking the card number in the transcript enough?
Only if the full number never reached the model or any store before masking. Redact at input, then mask anything that still appears, and scan to prove it.
What if a customer reads a card number aloud to a voice agent?
The speech-to-text output is a store like any other. Apply the same detection and redaction to the transcription before it reaches the agent, and avoid taking card details by voice at all.
Can we use real transcripts to test the agent?
Yes, if they are scanned and cleaned first. Test sets built from real cases are among the most overlooked places card data survives.