Why architecture matters here

The architecture matters because agent payments concentrate a specific, severe risk: autonomous action with financial consequence and an untrusted actor in the middle. The agent reasoning over the purchase is a persuadable component handling adversarial input (a malicious product page, an injected instruction); if authorization is 'the agent decided to pay', then prompt injection is theft. Mandates make the agent's discretion bounded and provable: the agent can only present authorizations the user actually signed, scoped to amounts, merchants, and timeframes the user set — so a compromised agent's blast radius is the scope of its mandate, not the user's whole account. The cryptographic scoping is the blast-radius control, the same principle as least-privilege tokens, applied to money.

Non-repudiation is the second load-bearing property, and it reshapes liability. Today's card disputes are adjudicated on weak evidence (was the card present? does the pattern look fraudulent?); an agent transaction backed by a signed cart mandate bound to a signed intent produces cryptographic proof of what the user authorized and what the agent executed — the merchant can prove authorization, the user can prove the scope they set, and a transaction outside the mandate is provably unauthorized. This is why the audit chain isn't logging hygiene but the core value: it moves agent-payment disputes from 'he-said-she-said' to signature verification, which is the only foundation on which merchants will accept agent transactions at all.

The human-present versus delegated distinction is the third architectural axis, and it governs where trust is anchored. In human-present flows, the user approves the specific cart in real time (signing the cart mandate at purchase) — maximum control, minimum autonomy. In delegated flows, the user pre-authorizes via an intent mandate and the agent acts later without them (signing carts within the pre-approved scope) — real autonomy, requiring the scope, limits, and revocation to be tight because the human isn't there to catch a mistake. Most real systems offer both and route by risk: small, in-scope purchases delegated; large or unusual ones escalated to human-present. Designing that routing — and the limits that make delegation safe — is the practical heart of an AP2 deployment.

Advertisement

The architecture: every piece explained

Top row: the authorization objects. User intent is the human decision — captured in whatever UX the wallet/agent provides — about what spending is permitted. The intent mandate encodes it as a signed, scoped credential: constraints on amount (per-transaction and aggregate), eligible merchants or categories, validity window, and the delegated agent's identity — signed by the user (their wallet key), establishing the envelope. The cart mandate is the transaction-specific authorization: the concrete items, merchant, and total, bound by reference to the intent mandate that permits it and signed (by the user in human-present flows, by the agent under delegated authority in delegated flows). Signatures chain the trust: user signatures establish authorization, agent signatures establish who acted, and verifiable credentials (the emerging standard for portable, cryptographically-verifiable claims) let merchants and payment providers verify all of it without a shared account relationship.

Middle row: presentation and execution. The agent presents the mandate chain to the merchant at purchase — the cart mandate, its parent intent mandate, and the signatures. Verification is the merchant's (or payment processor's) check: signatures valid, the cart within the intent's scope (amount ≤ limit, merchant eligible, within the time window), the intent not revoked, freshness (not replayed) — authorization established by cryptography, not by trusting the agent's assertion. Payment execution then runs on whatever rail the transaction uses — card networks, bank transfer, stablecoin — with the mandate as the authorization layer above the rail (AP2 is rail-agnostic; the mandate proves authorization regardless of how money moves). The audit trail is the signed chain itself, retained: user intent → cart → execution, each cryptographically linked, producing non-repudiable evidence for any later dispute.

Bottom rows: control and safety. Human-present vs delegated determines who signs the cart and thus how much autonomy the agent has; risk-based routing escalates high-value or anomalous transactions from delegated to human-present. Revocation and limits are the safety envelope for delegation: intent mandates can be revoked (a kill switch invalidating future use), velocity caps limit spend rate, and aggregate limits bound total exposure — so a delegated agent operating while the user sleeps has hard ceilings. The ops strip carries the real-world weight: key management (the user's signing keys and the agent's — their security is the system's security), dispute evidence (retaining and presenting the mandate chain), and fraud monitoring (patterns across mandates, anomaly detection even within valid scope — because a valid mandate abused is still fraud).

AP2 mandates — cryptographic authorization for agent paymentsthe user's intent, signed and scopedUser intentwhat's authorizedIntent mandatescope: amount, merchant, timeCart mandatespecific transactionSignaturesuser + agent + verifiable credsAgent presentsmandate to merchantVerificationsignature + scope + freshnessPayment executionrails: card, bank, stablecoinAudit trailnon-repudiable chainHuman-present vs delegatedreal-time vs pre-authorizedRevocation + limitskill switch, velocity capsOps — key management + dispute evidence + fraud monitoringcarryverifyexecuterecordscopelimitproveoperateoperate
AP2 mandates: signed intent and cart mandates carry scoped, verifiable authorization from user through agent to merchant, with a non-repudiable audit chain.
Advertisement

End-to-end flow

Walk two flows. Delegated purchase: a user tells their shopping agent 'keep me stocked on coffee, up to $40 a month, from my usual roaster'. The wallet captures this as an intent mandate — amount cap $40/month aggregate, merchant = the roaster's verified identity, 30-day window, agent identity bound — signed by the user's key and stored. Two weeks later the agent notices supply running low, builds a cart (2 bags, $22, the roaster), and — under the delegated authority of the intent — signs a cart mandate referencing it. It presents both mandates to the merchant; the merchant verifies: user signature on intent valid, agent signature on cart valid, $22 ≤ $40 remaining this month, merchant matches, window open, not revoked. Payment executes on the card rail; the signed chain is retained. The user wakes to coffee ordered, and — critically — the merchant holds cryptographic proof the purchase was authorized within a scope the user set.

Human-present, risk-escalated: the same agent finds a great deal on an espresso machine, $280 — far outside the coffee-supply intent. The system's risk routing refuses to treat this as delegated; instead the agent surfaces the cart to the user, who reviews the specific items and merchant and signs the cart mandate themselves in real time. The autonomy dial turned all the way to human control for the high-value, out-of-pattern purchase — the same protocol, different trust anchor, chosen by risk.

The adversarial and dispute vignettes prove the design. A compromised agent (prompt-injected by a malicious product page) tries to buy a $2,000 gift card from an unknown merchant: it has no mandate covering that amount or merchant, cannot forge the user's signature, and the merchant's verification rejects an out-of-scope cart — the attack's blast radius is exactly the mandate's scope, which covers coffee, not gift cards. Weeks later, a genuine dispute: the user claims they never authorized a $40 charge. The resolution is cryptographic — the retained mandate chain shows the signed intent (their key, that scope) and the cart the agent executed within it; either the signature is theirs (authorized, dispute denied) or it isn't (unauthorized, and provably so). No guessing, no pattern-matching — the audit chain adjudicates. The operational reality underneath: the user's signing key lives in their wallet's secure element, the agent's key in a managed KMS, revocation is a real-time check the merchant honors, and fraud monitoring watches for valid-but-anomalous patterns (a sudden burst of in-scope purchases) that scope alone wouldn't catch — because in payments, even authorized can be fraud.