Agent payments.
Handing an agent your card number works on the first try, and that is exactly the problem: a card number is a bearer credential, so the limit, the merchant and the reason all live in a prompt the agent is free to reinterpret. What the 2026 protocols added is not a faster rail — money already moved fine. It is a mandate: a signed, bounded record of what one named human authorised, which travels with the payment and can be checked by a party that does not trust your agent at all.
A card number is the wrong shape for a delegate.
Payment credentials were designed around possession. Whoever holds the number can spend, at any merchant, for any amount, any number of times, until it is cancelled. That was tolerable when possession implied a person, and it stops being tolerable the moment the holder is a process that can be talked into things.
- It carries no ceiling. Your $200 budget is a sentence in the system prompt, which means it has a failure rate rather than a return value — the same argument the instruction hierarchy makes about every other rule you tried to write there.
- It carries no purpose. Nothing in the transaction says what the human wanted. A refund clerk, a fraud model and an auditor all have to infer it afterwards from the merchant name.
- It carries no principal. The network sees a cardholder. It does not see that a program acted, on whose instruction, or under what constraint — which is a problem for the network before it is a problem for you.
This is ambient authority with a price attached. An agent running in a browser profile with a saved card did not receive a payment tool; it received your ability to buy things, and no one enumerated that set.
The mandate is the actual invention.
Every serious agent-commerce design converges on the same object under different names: a small, signed, verifiable statement of delegated authority that sits beside the payment instrument rather than inside the prompt. Google's Agent Payments Protocol (AP2), published in September 2025 with more than sixty launch partners and built on W3C Verifiable Credentials, calls them mandates and makes the useful distinction explicit.
- An intent mandate is issued when the human is not present: buy this class of thing, under this ceiling, before this date. The agent may act later, alone, within the envelope.
- A cart mandate is issued when the human approved this exact basket at this exact price. It is narrow, single-use, and worth almost nothing to an attacker.
That pair is the entire human-in-the-loop question rewritten as data. "Did a person approve this?" stops being a claim your logs make after the fact and becomes a signature someone else can verify. Whatever a mandate is called in the protocol you adopt, it has to carry five things: who authorised it, which agent may use it, what it is for, the bounds it dies outside of (amount, merchant or category, expiry, single-use or not), and a signature that survives leaving your infrastructure.
The rails did not change. They grew a field that says "an agent did this".
The card networks arrived at the same conclusion from the opposite direction, and their reason is worth understanding because it is not politeness. A network has to be able to tell an agent transaction apart — to score it for fraud, to price it, and above all to route a dispute. An unlabelled agent purchase looks exactly like card-not-present fraud, so the first symptom of getting this wrong is not a breach. It is a decline rate.
- Mastercard Agent Pay, announced in April 2025, issues Agentic Tokens through the existing tokenisation service so a verified agent transacts on a consumer's behalf with a credential that is not the card.
- Visa's Trusted Agent Protocol, announced in September 2025, pairs a Verified Agent ID with a consent record signed on the issuer's side — agent identity and human authorisation kept as two separate artefacts, which is the right split.
- Convergence is now the trend, not fragmentation. Visa's Intelligent Commerce Connect (announced April 2026) is a single on-ramp across several of these schemes, and in May 2026 AP2 and Mastercard's Verifiable Intent were contributed to the FIDO Alliance. You are choosing an envelope, increasingly not a rail.
A second, quieter family exists for machine-to-machine spend — paying per API request, per unit of compute, per document — where there is no cart, no consumer and no chargeback. Those protocols optimise for settlement cost rather than consent, and the two families solve genuinely different problems; the protocol comparison lays out where each one keeps the spending limit.
What this means for something you are building.
An agent that can spend is an agent whose worst outcome is denominated in money, which makes it the clearest case in the whole field for putting the control outside the model.
- Move the cap out of the prompt and into the credential. A virtual card, a scoped token or a mandate with a hard ceiling is enforced by a party that cannot be persuaded. This is the payments-shaped version of scoped permissions.
- Scope per task, not per session. One mandate per intent, expiring on completion, keeps a persuaded agent holding nothing worth asking for.
- Keep the authorisation record as your audit artefact. The mandate is already a signed statement of who approved what — it is the cheapest good evidence you will ever get, and it is what a dispute, an observability trace and a regulator all want.
- Build the reversal before the purchase. A payment is the canonical irreversible side effect. If your agent can buy, something has to be able to refund, cancel and reconcile — and duplicate charges from retried tool calls are a real failure mode, not a hypothetical one.
If you do exactly one thing, do this: delete the sentence "do not spend more than $200" from your system prompt and replace it with a payment credential that cannot spend more than $200. Everything else on this page is elaboration on that swap — a rule the model follows becomes a bound the model cannot reach.
Related: AP2 & agent commerce for the protocol in depth, shopping & checkout agents for the build, and denial of wallet for the version of this risk where nobody is buying anything.