Card networks never had to ask what the cardholder meant — the card was present or it was not. An autonomous agent breaks that assumption: it transacts while the user sleeps, reasons over adversarial input, and can be talked into things. AP2's answer is the mandate — a signed, self-describing statement of what the user authorized, carried with the transaction and checkable by anyone downstream. Two of them, really: an intent mandate granting a bounded envelope, and a cart mandate spending one specific basket inside it. This piece takes the mandate apart as an artifact — what it must bind to be worth anything, who signs which part with which key, the checklist a verifier runs before treating it as authorization, what non-repudiation actually proves when a dispute lands, how a mandate ends, and the four ways the whole scheme fails.
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.
Non-repudiation — what a signature actually proves
Non-repudiation is the headline benefit and the most overclaimed one. Be precise about what a verified mandate establishes: that this key signed these exact bytes, that the bytes are unchanged, and that the executed cart fell inside a scope that key authorized. That is a genuine advance over disputes adjudicated on whether a card was present and whether the pattern looked odd.
What it does not establish: that a human was present, that the human understood the scope, that the device holding the key was uncompromised, or that any scheme will treat the proof as a liability shift. Liability allocation comes from scheme rules and law; a signature is evidence entering that process, not a verdict.
The honest framing is that mandates change the argument. The dispute stops being 'did you authorize this?' — largely unanswerable — and becomes 'was your key compromised?' That is narrower, more tractable, and backed by a real evidentiary trail, but it is still an argument, and the chargeback process still adjudicates it.
Revocation and expiry — ending a mandate
Two mechanisms end a mandate's authority, and they trade against each other. Expiry is intrinsic: the not-after is signed into the artifact, every verifier enforces it offline, and nothing needs to be reachable for it to work. Revocation is extrinsic: the user changes their mind or a key is compromised, and every verifier must now learn something the artifact does not say.
That asymmetry drives the design. Short windows make revocation less load-bearing — a mandate expiring in an hour barely needs a kill switch — but force re-signing, which for a delegated agent means waking a user who is not there. Long windows enable real autonomy and make the revocation path safety-critical: a status check at authorization, with defined behavior when it is unreachable.
Revocation should also be honest about its reach. It stops future authorizations. It does not claw back a capture that already settled, and it does not invalidate the signed record of what was authorized beforehand — nor should it.
Four failure modes — replay, scope creep, stale mandate, ambiguous cart
Replay. A mandate captured in transit and presented again. The defence is a per-mandate nonce plus verifier-side memory of what it has accepted, scoped to the validity window so that memory stays bounded. A mandate with no nonce is a reusable coupon.
Scope creep. Not forgery — the mandate verifies perfectly and the constraints are simply too loose: a category broad enough to include anything, a window measured in months, a ceiling set at the account balance. This one fails silently, because nothing in verification objects.
Stale mandate. Signed against conditions that no longer hold — the price at signing, the merchant's standing at signing, a funding instrument since cancelled. Verification confirms the signature, not that the world still matches it.
Ambiguous cart. The hardest. The user signs a basket; between authorization and capture an item is substituted, shipping is added, or the total drifts. The signature now covers a cart nobody is charging. Any delta that changes what the user agreed to needs a fresh cart mandate — not a tolerance band quietly widened until the mismatch stops failing.