AP2 Mandate Explained
The protocol defines how a mandate travels. It does not define how narrowly yours is drawn, and that is the part a dispute turns on.
What a mandate is
In the Agent Payments Protocol a mandate is the object that carries authorisation from the person to the transaction. It is not a permission flag and it is not a session. It is a signed statement, made before the purchase, describing what an agent may do, and it travels with the payment so that whoever has to decide can read it.
That is a genuine advance on what came before, which was an API key and a hope. It also relocates the whole problem. If the mandate is what authorises, then how the mandate was drawn is the only thing that matters, and drawing it is not a protocol question.
Intent and cart
AP2 separates two moments that most implementations collapse. There is what the user asked for, expressed before anything was found, and there is what the agent proposes to buy, expressed once it has. The first is broad and the second is specific, and the gap between them is where an agent exercises judgement.
Keeping them apart matters because they answer different questions after the fact. The first says what the person wanted. The second says what the software decided. A dispute is almost always about the distance between the two, and a system that recorded only one of them cannot show that distance at all.
What a signature proves, and what it does not
A cryptographic signature proves that a mandate was issued by a particular key at a particular time and has not been altered since. That is a real and useful guarantee, and it is narrower than it looks.
It does not prove the person understood what they authorised. It does not prove the scope was appropriate to the purchase. It does not prove the agent stayed inside it, only that a checker could tell. And it does not prove that anyone was accountable for the configuration that produced it. Those are governance properties and no protocol supplies them.
Scope drift and the standing mandate
The failure that will produce the first serious disputes is not fraud and it is not a broken signature. It is a mandate that was drawn for one purpose, reused for another because reissuing it was friction, and quietly widened until it authorised more than anyone intended.
Nothing in a protocol prevents that. A widened mandate is still valid, still signed and still checkable. It is the agentic equivalent of a shared administrator password, and it will be discovered the same way, which is during an incident rather than during a review.
The countermeasure is unglamorous. Mandates get an expiry, scopes get reviewed on a schedule with a named owner, and any widening is a decision somebody makes rather than a default somebody inherits.
What this means for a merchant and for a bank
The two ends of the transaction care about different halves of AP2. A merchant needs to know that a request carries a valid mandate and that accepting it does not leave the sale disputable. A bank or issuer needs to know what the mandate actually authorised, because that is the document a chargeback will be argued against.
Neither of them can answer their question from the protocol alone. The merchant needs a policy for what to do when a mandate is absent or expired. The issuer needs the mandate to have been drawn narrowly enough that it distinguishes an authorised purchase from an unauthorised one, and a mandate naming a category and a ceiling frequently does not.
That asymmetry is worth naming early in any implementation, because the two sides usually discover it at the same moment and from opposite directions. The delegation chain sets out how far apart they can end up.
Where AP2 stops
AP2 defines the shape of a mandate and how it travels. It does not decide how narrow yours are, what happens to a transaction that arrives outside one, how long a standing mandate should live, or who inside your organisation signs the scope off.
Those four are the whole of the commercial exposure and they are yours in every version of every protocol. An organisation that adopts AP2 and answers none of them has bought interoperability and no governance, which is a reasonable trade only if it knows that is the trade. How the three protocols differ is set out in the protocol comparison.
What to decide before adopting it
Three things, and none of them is technical. Which transaction classes may proceed on a standing mandate and which require a fresh one. What the ceiling and the expiry are for each class, expressed as numbers a system can enforce rather than as a policy anyone can interpret. And who is named as accountable for the scope, the monitoring and the release.
Decide those and the protocol choice becomes an implementation detail. Skip them and the protocol choice will not save you, because the protocol was never the part that was in question. The wider framing is in agentic commerce governance.
Start the conversation
We advise companies on agentic commerce, from first assessment through to a defensible implementation decision.
Contact contraco