A mandate is a signed claim, not a permission bit
Most delegation systems hand the delegate a bearer credential — an API key, an OAuth token, a card on file. Possession is authority: whoever holds it can spend, and the only record of what the user meant is a scope string in a database the user cannot inspect. That model breaks the moment the delegate is a model reading untrusted input. A prompt-injected agent holding a stored card is indistinguishable from a legitimate one, because the credential says nothing about the purchase.
A mandate inverts this. It is a signed, self-describing statement of what the user authorized — a verifiable-credential-style object rather than a lookup key. The agent does not hold spending power; it holds a document proving the user granted specific, bounded power, and the document commits to its own limits. Authorization becomes a claim you check rather than a secret you hold, and a compromised agent's blast radius shrinks to the scope its mandates actually cover.
Intent mandate and cart mandate — envelope and instance
AP2 splits authorization into two objects because the user and the transaction happen at different moments. The intent mandate is the envelope: signed by the user, it says this agent may transact on my behalf within these bounds — a ceiling, a merchant or category scope, a validity window, a named agent. It authorizes a space of possible purchases, not a purchase.
The cart mandate is the instance: one concrete basket, one merchant, one total, one currency, referencing the intent that permits it. In a human-present flow the user signs the cart themselves at purchase time and the envelope may collapse to nothing. In a delegated flow the user is absent, the agent signs the cart under the authority the intent grants, and the reference between the two objects is the only thing making that agent signature mean anything.
An intent mandate can be one-off (buy this when it drops below a price) or standing (an envelope drawn against repeatedly until it expires). Both are bounded envelopes; fixed-schedule billing is a separate lifecycle.
What a mandate must bind to mean anything
A signature only protects what it covers, so the bindings are the design. An amount ceiling with its currency — a limit without a currency is not a limit. A merchant scope, as a verified merchant identity or category, so an out-of-scope seller cannot use the mandate. A validity window with a not-before and a not-after, so authority decays on its own. A nonce, so a captured mandate cannot be replayed. The agent's identity, so a leaked mandate is useless to a second agent. The intended audience, so a mandate shown to one verifier is not accepted by another. For a cart mandate, a reference to its parent intent and a hash of the canonical cart.
Anything outside the signed payload is negotiable. If shipping, currency, or merchant identity sits alongside the signature rather than under it, an attacker or a careless integration can change it while verification still passes — the classic error of signing a summary instead of the object.
The signing chain — whose key, over which bytes
Three questions decide whether a mandate is worth verifying: whose key signed, over what bytes, and how the verifier resolves that key to a party it trusts. The third is really identity verification and deserves its own treatment; the first two are the mandate's own problem.
The user's key belongs where their other high-value secrets live — a hardware-backed store in the wallet or device — so signing requires a real user gesture rather than a server-side call. The agent's key lives in a managed KMS under the operator's control. Treat those as different trust levels: a user signature grants authority, an agent signature only attributes an action.
Over what bytes matters just as much. Signatures must cover a canonical serialization — a deterministic encoding where key order, number formatting, and whitespace cannot vary — otherwise two encodings of the same object hash differently and signer and verifier are not discussing the same thing.
Verification at authorization time — the checklist
A verifier — merchant, payment provider, or issuer — runs a fixed sequence before treating a mandate as authorization, and the ordering is deliberate: cheap, local, deterministic checks first, network-dependent ones last.
Parse and check the algorithm, rejecting anything you did not intend to accept. Verify the cart signature, then the parent intent's. Check reference integrity: the cart names this intent, the intent names this agent, the audience is you. Check scope containment: cart total ≤ ceiling, same currency, merchant inside scope. Check temporal validity against both windows with an explicit clock-skew allowance. Check freshness: this nonce has not been seen. Check status: the intent has not been revoked. Finally recompute the canonical cart hash from what is actually being charged and compare.
Every step fails closed. A verifier that cannot reach the revocation service and approves anyway has downgraded a cryptographic control to a hint — a policy decision worth making explicitly rather than by timeout.
Who holds the running total
That checklist hides a real architectural split. Per-transaction ceilings are stateless: a merchant can decide whether a $22 cart fits under a $40 cap from the artifact alone, remembering nothing. Cumulative ceilings are not. 'No more than $200 across this window' cannot be evaluated from the mandate, because the mandate does not know what has already been spent against it.
Somebody must hold that counter, and it cannot be the merchant — a merchant sees only its own sales, so an agent spreading spend across five sellers clears every local check independently. The counter belongs to a party that observes every draw: the wallet or the issuing side that authorized the envelope. In practice the aggregate cap is enforced there at authorization, alongside rate-based velocity controls, while the merchant enforces the per-transaction and scope constraints it can check locally. Getting this split wrong is the most common way a mandate that looks tightly bounded turns out not to be.