Your Agent Spent the Money. Can You Prove You Authorised It?

Google’s Agent Payments Protocol builds a cryptographic record of what an AI agent was permitted to do. That is genuinely useful engineering. It is also not the same thing as proving you wanted the outcome.

A year ago this was a seminar question. It is now an operational one. Agents are booking, buying and renewing on behalf of users, and the infrastructure to make that accountable is being assembled while it is already in use.

The most serious attempt at that infrastructure is Google’s Agent Payments Protocol, AP2 — a vendor-neutral open standard launched with more than sixty partners including Mastercard, PayPal, American Express, Coinbase and Salesforce. It is worth understanding properly, because it is likely to shape how this problem gets solved, and because its limitations are as instructive as its design.

What does AP2 actually do?

AP2 breaks a transaction into three signed artefacts, carried as W3C Verifiable Credentials. An Intent Mandate captures what the user asked for, with constraints attached — a price ceiling, a category, a deadline. A Cart Mandate captures the specific basket the agent assembled. A Payment Mandate captures what the merchant and payment network accepted.

Separating those three creates something that did not previously exist: a verifiable chain showing what an agent was authorised to do, what it actually did, and what the other side agreed to. The protocol also treats stablecoin rails as first-class alongside cards and bank transfers, which tells you something about where Google expects this to go.

As engineering, this is sound. Signed, scoped, revocable delegation is the right primitive. Anyone building agentic systems should be borrowing the shape of it whether or not they adopt the protocol.

What’s the gap between authorisation and intent?

Here is the difficulty, and it is the one Fortune put its finger on in late August: AP2 can tell you exactly how your agent spent your money. It is considerably less help when the agent buys something you never wanted.

A mandate proves a chain of signatures. It does not prove the purchase reflected the user’s actual intention. If an agent misreads “find me something around £200 for my sister’s birthday” and produces a signed, valid, in-budget Cart Mandate for the wrong thing entirely, every cryptographic check passes. The record is impeccable. The outcome is wrong.

Provable authorisation and correct interpretation are different problems. AP2 solves the first one well, and does not claim to solve the second — but the two are easy to conflate in a procurement conversation.

This matters most precisely where the commercial value is. Early AP2 implementations keep a human in the loop: the agent assembles the cart, the user confirms. Google has signalled support for human-not-present flows, where cart mandates are pre-authorised for future events — an upcoming ticket release being the canonical example. That is the use case everyone actually wants. It is also the one where the human judgement thins out to nothing at the moment of purchase.

What new attack surface does this create?

Several categories of risk here have no real precedent in card payments.

Merchant steering. Adversarial fine-tuning can bias an agent’s product selection toward particular merchants. The user sees a plausible recommendation; the mandate validates; nobody can easily tell it was manipulated.

Replay and context-binding failures. Academic work on AP2 specifically has flagged the need for zero-trust runtime verification, because a signed mandate detached from its original context is a reusable object.

Unintended principals. Without strong controls, a child talking to a household chatbot can generate an intent that looks, cryptographically, exactly like an adult’s.

Feedback contamination. Intent mandates flowing back into retraining can entrench systematic misreadings of what users mean.

None of these are reasons to avoid agentic payments. They are reasons to treat the protocol as one layer of a system rather than as the answer.

Where is regulation heading on this?

Two developments point the same way. NIST is working through comments on its draft concept paper on agent identity and permission, which asks how an agent proves its authority, ties that authority to a person, and produces verifiable records. Its initial scope is deliberately narrow — agents operating inside organisations, where visibility and control are achievable.

Alongside it, Senator Warner’s AI AGENT Act would define a “custodial user agent” as one acting for a user in a transparent, documented, limited and revocable manner, require real-time records of actions taken, and direct NIST to develop standards for verifying delegated authority.

Whatever happens to that particular bill, the requirement it describes — auditable delegation, retained and inspectable — is being arrived at from several directions simultaneously. That is usually a reliable signal.

What should you actually do about this now?

Log intent separately from execution. Most systems record what happened. Far fewer record what the user asked for, in the user’s own terms, alongside the constraints applied. When something goes wrong, the second record is the one that matters.

Make constraints hard, not advisory. A price ceiling enforced in the prompt is not a control. Enforce limits outside the model, where they cannot be reasoned around.

Decide your position on human-not-present before a client asks. There is a defensible answer, but it involves narrower scopes, shorter validity windows and per-category caps — not simply removing the confirmation step.

Assume you will need to reconstruct a transaction. Not for compliance today, but for the dispute you will eventually have to explain to a customer, an insurer, or a regulator.

What’s the honest summary?

AP2 is a good piece of work addressing a real gap, and the fact that payment networks are engaging seriously with it is more encouraging than most agentic AI announcements this year.

But it answers the question “was this authorised?” rather than “was this what the person meant?” For the moment, the second question still lands on whoever deployed the agent. Building as though that will remain true is the cautious assumption, and probably the correct one.

Key takeaways

• AP2 proves what an agent was authorised to do and what it actually did, through three signed artefacts (Intent, Cart, and Payment Mandates). It does not prove the purchase matched what the user actually meant.
• The commercial value is highest in “human-not-present” flows, which is exactly where human judgement disappears from the moment of purchase.
• New risks here have no real precedent in card payments: merchant steering via adversarial fine-tuning, replay/context-binding failures, unintended principals (like a child’s request passing as an adult’s), and feedback contamination in retraining.
• NIST’s draft concept paper and Senator Warner’s AI AGENT Act are both converging on the same requirement from different directions: auditable, revocable, inspectable delegation.
• Practical steps now: log intent separately from execution, enforce constraints outside the model rather than in the prompt, decide your human-not-present policy before a client forces the question, and assume you’ll need to reconstruct any given transaction for a future dispute.

FAQs

What is Google’s Agent Payments Protocol (AP2)?
AP2 is a vendor-neutral open standard, launched with over sixty partners including Mastercard, PayPal, American Express, Coinbase and Salesforce, that creates a cryptographic record of what an AI agent was authorised to do, what it did, and what the merchant accepted.

Does AP2 prove a purchase matched what the user actually wanted?
No. AP2 proves a valid chain of signed authorisation, not correct interpretation of intent. An agent can produce a fully valid, in-budget mandate for something the user never actually wanted, and every cryptographic check will still pass.

What are the three mandates in AP2?
An Intent Mandate (what the user asked for, with constraints like price ceiling or deadline), a Cart Mandate (the specific basket the agent assembled), and a Payment Mandate (what the merchant and payment network accepted).

What is a “human-not-present” flow in agentic payments?
It’s a transaction flow where a cart mandate is pre-authorised for a future event, such as an upcoming ticket release, so the agent can complete the purchase without a human confirming at the moment of purchase. It’s the most commercially valuable use case and the one with the least human oversight at the critical moment.

What new security risks does agentic payment infrastructure introduce?
Four with no real precedent in card payments: merchant steering through adversarial fine-tuning, replay and context-binding failures on reused mandates, unintended principals (like a child generating a request that looks cryptographically like an adult’s), and feedback contamination from intent mandates flowing back into retraining.

Is agent payment regulation coming?
Signs point that way. NIST is developing standards for agent identity and permission, and Senator Warner’s AI AGENT Act would legally define a “custodial user agent” and require real-time, auditable records of actions taken on a user’s behalf.