No. Almost every card task an AI agent handles works with a token, a card reference or the last four digits, and nothing it does needs the full number. Letting full numbers reach the agent pulls its prompts, logs and model calls into PCI DSS scope and creates a store of card data nobody meant to keep.
Why does the full number matter so much?
A full card number is the thing a fraudster needs. Once it enters a prompt, it can travel to the model, into the agent's working memory, into logs, into traces kept for debugging, and into any summary the agent writes. Each of those becomes a place card data lives.
Under PCI DSS v4.0, any system that stores, processes or transmits card data, or can affect its security, is in scope. An agent that sees full numbers brings its whole stack with it. The detailed requirements are in PCI DSS and AI agents that handle card data, and the specific trap of numbers sitting in text the agent produces is covered in PCI DSS and card data in AI agent prompts and logs.
What can the agent do without the full number?
Nearly everything. Card systems already work with references internally, and the agent should use the same ones.
| Task | What the agent uses | Depth | Stays with a person |
|---|---|---|---|
| Identify which card a customer means | Last four digits, card type, expiry month | 1 | Nothing |
| Explain a declined transaction | Token and authorisation record | 1 to 2 | Nothing routine |
| Freeze a card the customer reports lost | Card reference | 3 | Unfreezing after suspected fraud |
| Order a replacement card | Card reference, verified address | 3 | Address changed in the last few days |
| Change a spending limit | Card reference | 3 within bounds | Increases above the bank's limit |
| Raise a dispute | Token and transaction reference | 2 | Chargeback decision |
| Read the full number | Never | None | Never needed |
For the actions themselves, see whether an AI agent can freeze a customer's card and whether it can change a customer's card spending limits.
What about when a customer types the number into a chat?
Customers do this all the time, often when asked only for the last four digits. The agent should never be the first thing to see that text.
The right control is detection and masking before the message reaches the agent. A filter recognises card-number patterns, replaces them with a masked form, and records that it did so. The agent receives a message saying the customer shared card details and they were removed, and replies by asking only for what it needs. The original text is not stored anywhere the agent can reach.
This has to be enforced in the channel, not requested in the agent's instructions. An instruction to "ignore card numbers" still means the agent has read them.
Is there ever a case for the full number?
Some card operations do need the full number at some point: printing a card, sending it to a scheme, or a fraud analyst comparing with an external report. In each case a system or a person inside the card data environment does it, under the controls that environment already has. The agent can prepare the request, pass the token, and receive the result. It does not need to handle the number itself.
If a proposed agent design seems to require full numbers, that is a sign the boundary is in the wrong place. Move the step that needs the number into the existing card system and have the agent call it.
An illustrative example
Take a card issuer whose contact centre agent handles "I don't recognise this payment" messages. A customer writes in with their full card number and asks what a charge of 89 is.
The masking filter strips the number before the agent sees it. The agent reads the customer's authenticated session, finds the card by its reference, and pulls the transaction by token. It explains the merchant name as it appears on statements and offers to freeze the card. The customer agrees, and the agent freezes it at depth 3. It drafts a dispute for a person to review. At no point does a full number sit in the conversation, the logs or the dispute file.
What controls make it hold?
- Masking at the edge, before text reaches the agent, in every channel.
- Tokens only in the agent's tools; no tool returns a full number.
- Output scanning for card-number patterns in anything the agent writes or logs.
- Separate integration with the card management system through narrow, reference-based calls; see how to connect an AI agent to your card management system.
- A record of every masking event, so the bank can show the control works.
The wider limits on agents in banks are in AI agents in banking: what they may and may not do.
Questions people ask
Is the last four digits plus expiry safe for the agent to see?
Generally yes. Truncated numbers are designed to identify a card without exposing it. The bank should still confirm its own policy on which combinations are allowed together.
What about the security code on the back?
It should never reach the agent, and under card rules it must not be stored after authorisation. The same masking filter should catch it.
Can a model provider be in scope if card numbers reach it?
Yes. Any party whose systems process the number is drawn in, which is why the number should be stopped before it is sent.