A scoped, short-lived credential (Module 3) proves an agent is allowed to call a tool. It says nothing about whether the user actually agreed to the specific transaction the agent is about to push. A token that can spend $5,000 will happily spend it on the wrong cart, at the wrong merchant, after the agent misread a page. The gap is between "this agent is authenticated" and "this user approved this purchase." Mandates close that gap by binding a specific spend to a specific human decision with a signature you can verify later.
This module maps that idea to a concrete standard: the Agent Payments Protocol, AP2, published by Google on September 16, 2025, with more than 60 payments and technology partners including Mastercard, PayPal, American Express, Adyen, Coinbase, and Worldpay. AP2 is an open protocol that extends the Agent2Agent (A2A) protocol and the Model Context Protocol (MCP), so it sits next to the tooling layer rather than replacing it.
What a mandate actually is
A mandate is a cryptographically signed digital contract that records what a user authorized. In AP2 these are W3C Verifiable Credentials, signed JSON objects, so any change to the content breaks the signature and the credential reads as invalid.
The signature is the load-bearing part. A normal API call asserts "trust me, the user wanted this." A mandate carries proof the user wanted this, captured at the moment of the decision, on a key the user controls (in practice a hardware-backed key on their device). That property is non-repudiation: after the fact, no one can credibly deny the instruction was given, because the evidence is the signature itself.
Treat a mandate as the permission slip and the audit record at once. It answers three questions AP2 names directly: authorization (did the user grant this specific purchase), authenticity (does the agent's request reflect the user's true intent), and accountability (who is answerable if the transaction is wrong).
The three-mandate chain
AP2 does not use one blob. It chains three mandates, each scoped to a different actor and a different moment.
Intent Mandate
The Intent Mandate captures scope and constraints when the human is not present at transaction time. It is the user pre-authorizing a bounded action: "buy a pair of white running shoes, size 10, under $150, deliver to my saved address." The user signs it in their AP2-compatible client. The agent cannot exceed that scope without going back for a new signature.
This is the mandate that matters most for autonomous, human-not-present (HNP) flows, because it is the only place the user's real boundaries are recorded. Get the constraints wrong here and the agent has a signed license to overspend within whatever you forgot to bound.
Cart Mandate
The Cart Mandate is the human-present case. The merchant generates it from the user's request, and the user signs the exact cart: specific items, specific total. AP2 frames this as "what you see is what you pay for." Because the price and line items are inside the signed object, an agent or a compromised intermediary cannot swap the cart after approval without invalidating the signature.
Payment Mandate
The Payment Mandate is a minimal credential derived from the cart or intent, appended to the authorization and shared with the issuer and payment network. Its job is narrow: signal that an agent was involved and whether the flow was human-present or human-not-present, so the network can risk-score with that context, without changing existing authorization rails. It is deliberately thin so sensitive detail stays with the parties that need it.
Together the three form a non-repudiable trail from intent, to cart, to payment.
A worked example
A user tells their shopping agent: "Buy this jacket when it drops under $120, charge my default card, ship to home."
- The client builds an Intent Mandate: item reference, price ceiling $120, payment method handle, ship-to address, and an expiry. The user signs it. The agent now holds a bounded, signed authorization, not a blank check.
- Three days later the price hits $118. The agent assembles a cart with the merchant. The merchant returns a Cart Mandate for $118 plus $7 shipping. Because this is HNP, the system checks the cart against the signed Intent Mandate: total $125 exceeds the $120 ceiling. The constraint fails.
- Nothing settles. The agent either re-prompts the user for a new signature covering $125, or holds. No silent overspend, because the ceiling lived inside a signed object the agent could not edit.
Now flip one detail: the user was present and approved a $118 cart directly. The user signs the Cart Mandate in-session, a Payment Mandate is derived and sent to the network flagged human-present, and settlement proceeds on the normal rails. The difference between the two paths is recorded in cryptography, not in a log line an attacker could forge.
Where mandates fit, and where they don't
Mandates are an authorization and evidence layer, not a runtime guard. They constrain what the user agreed to; they do not stop a misbehaving tool from doing something dumb inside that scope. The gateway and least-agency controls (Module 6) and human-in-the-loop checkpoints (Module 7) handle execution-time enforcement. The tamper-evident audit work (Module 8) leans directly on the non-repudiation property a signed mandate gives you.
Two failure modes to watch when you implement. First, a sloppy Intent Mandate is the new over-scoped token: every constraint you omit (no expiry, no merchant restriction, a loose price ceiling) is a constraint the agent is free to ignore. Second, signature verification has to actually happen at the enforcement point, against the user's key, before settlement. A mandate no one checks is just JSON.
Takeaway
A session token proves identity; a signed mandate proves consent to a specific spend, and proves it in a form you can verify after the fact. AP2's contribution is to standardize that consent as a chain of verifiable credentials, scoped per actor and per moment, so the "did the user authorize this" question has a cryptographic answer instead of a log entry. Build the Intent Mandate constraints as carefully as you would build a least-privilege IAM policy, and verify every signature at the point money moves.