AI agents and payment data: who is really asking?

Card networks and payment providers have begun publishing frameworks for payments initiated by AI agents: software that searches, compares and checks out on a customer's behalf. It is early, but the direction is clear. More requests for sensitive data will come from software acting for a person, rather than from the person directly.

Two different questions

The first question is authorisation: should this agent be allowed to make this request, for this customer, right now? That is a business decision. It depends on the customer's consent, limits, context and your own rules.

The second question is protection: when the request is allowed, how many systems get to see the data along the way? That is an architecture decision, and it is easy to overlook.

New places for data to leak

• Agent prompts and context windows that contain customer details.
• Conversation logs and traces kept for debugging or model improvement.
• Third-party tools and plug-ins the agent calls along the way.

Each of these is a new copy of sensitive data, in a system that was not designed to hold it.

Keep the two jobs separate

It is tempting to expect one product to decide whether an agent is trustworthy and also protect the data. Keeping those jobs separate makes both stronger: your application decides what is allowed, and the architecture makes sure that only the systems that need the data can ever read it.