AP2 Bounds One Grant. Who Bounds the Principal?

AP2 v0.2 authorizes an agent ahead of time, lets the agent sign concrete payments under that authorization, and caps cumulative spend across repeated uses of one reusable mandate. The same pattern holds across the agent payment stack. Every system bounds its own grant: one mandate, one token, one key, one permission. None of them bounds the principal across grants, agents, payment rails and organizations, and that is the job a portable mandate would have to do.

I use portable mandate here to mean a principal-level grant of authority that keeps an agent's budget, revocation and onward delegation consistent across independently issued grants, tools, payment rails and organizations. Neither the phrase nor the underlying mechanisms are new. UCAN, Biscuit and Macaroons already narrow authority on delegation. ERC-7715 and ERC-7710, both drafts, standardize wallet permission requests and delegated execution, while the MetaMask Delegation Framework and Coinbase Spend Permissions already enforce periodic limits with revocation visible outside the agent. Open Horizon Labs' Agent Mandate Layer, Tesseris and Alkimi already use the wording. What this article adds is narrower: a composition and enforcement model for the grants that already exist.

Compared against AP2 specification v0.2 (v0.2.0, released 28 April 2026) as of 3 October 2026. Normative statements cite ap2-protocol.org. Issues and pull requests are cited as open as of the same date.

What do AP2 Checkout and Payment Mandates authorize today?

They authorize a specific checkout and its payment, and in autonomous mode they authorize a bounded class of future checkouts and payments that the agent completes on its own signature.

The core specification defines two mandate types. A Checkout Mandate proves to the merchant that the shopping agent is authorized to buy the checkout it assembled. A Payment Mandate proves to the credential provider, the network and the merchant's payment processor that the agent is authorized to pay for that checkout. Each has two forms. The open one carries constraints, and the closed one carries the actual values for a given purchase.

In human-present mode the user approves the closed mandates directly. In human-not-present mode the user approves open mandates on a trusted surface. Those open mandates must include the agent's public key as a cnf claim, and the agent then signs the closed mandates itself. Verifiers always receive closed mandates. The merchant checks the checkout against the open constraints before completing it, and the credential provider checks the payment before returning a payment credential. That is authorization at execution time, and it also produces evidence for later disputes.

The constraint set on the Payment Mandate is richer than a single price cap. It covers amount ranges, allowed payees, allowed instruments, allowed payment initiation providers, execution windows, a recurrence rule (payment.agent_recurrence, from ON_DEMAND to ANNUALLY, with optional max_occurrences) and a cumulative spend envelope, payment.budget. The budget's evaluation rule is worth quoting exactly: "the requested amount plus the total sum of amounts from previously closed Payment Mandates MUST be less than or equal to max."

Delegation from user to agent is the point of the open/closed design. Delegation from one shopping agent to another is a different matter: the specification calls it conceptually possible and "outside the scope of the current specification."

The older vocabulary of Intent, Cart and Payment Mandates belongs to v0.1, published in September 2025. Analyses written against it describe a protocol that has since changed.

What do other agent payment systems already bound?

They bound their own grant and nothing else. The check happens at their own checkpoint, and revocation, where it exists, works inside their own system.

Sources: ACP payments reference, Stripe Shared Payment Tokens and revoke endpoint, MPP agent spend guide and Tempo sessions, Coinbase Spend Permissions, MetaMask Delegation Framework, x402 v2 specification, EIP-3009.

The third column is the one that matters. The boundary is always one grant, or one account inside one system. That is a sensible design for each system. The catch is on the principal's side: someone who has issued five grants across three systems ends up with five budgets and five revocation paths, and no total anywhere.

What do I mean by a portable mandate?

The grant defined at the top of this piece, sitting one level above everything in that table. One principal. One spend envelope that several grants draw down. A revocation that actually reaches every descendant, plus rules on who may delegate onward and how far.

The six fields from the original framing were principal, scope, spend envelope, expiry, revocation path and accountability. Most of the systems above carry some version of them already, so the fields were never the hard part. Enforcement across grants is. A field declared inside each grant gets checked by that grant's verifier and by nobody else. Once a field has to hold across grants, somebody has to count all of those grants in one place.

SEPA direct debit is the comparison people usually reach for, and for the shape it's fair: a standing authorization, with every collection under it still running under the scheme's rules. It breaks right where this article starts. A SEPA mandate lives inside one scheme and one participant network. Nobody expects it to carry a budget across rails.

AP2 bounds one grant. A portable mandate has to bound all of them.

Where does per-grant bounding break?

It breaks when the principal's real limit is spread across more than one grant, more than one verifier, or more than one point in time. Three failure patterns show the mechanism: sum-of-grants overspend, check-then-spend race and stale-grant acceptance.

Sum-of-grants overspend. A principal intends to spend €1,000 on a trip. They authorize a lodging agent for €700 and a transport agent for €700, each under its own open Payment Mandate with its own payment.budget. Both agents stay inside their caps, and €1,400 is authorized. Nothing in either grant is violated, because the €1,000 limit was never written down anywhere a machine could read it. The nearest public discussion covers the adjacent case of one budget checked by several merchants: AP2 issue #207, filed in v0.1 vocabulary, and PR #252, whose sample shows two merchants evaluating one budget independently and an agent spending $120 against a $100 cap. Both are open as of 3 October 2026. No public incident with losses has been reported for this scenario. It illustrates the mechanism.

Check-then-spend race. This is the classic time-of-check to time-of-use pattern, applied to a spend envelope. Picture two verifiers sharing one €1,000 allowance. They check the balance in the same instant, each sees the full €1,000, and each signs off on €600. Each check was correct when it ran. The nearest public work is AP2 issue #346 and PR #347, on replay of one accepted Payment Mandate and atomic consumption at a single verifier. The PR describes itself as a durable single-host result with no claim about distributed stores. Both are open as of 3 October 2026. No public incident with losses has been reported here either.

Stale-grant acceptance. A grant expires tomorrow. The principal withdraws authority today. A verifier that checks only the signature and exp accepts the next payment, because by every test it runs the grant is still valid. Revocation only works if it is checked at the last trusted point before the payment executes. Lifecycle and revocation questions are raised in AP2 issue #45 and issue #118, both written against v0.1 and both open since 2025. No public incident with losses was found here.

AP2 does address part of this ground. Its security considerations require the shopping agent to avoid signing overlapping closed mandates under one open mandate, and allow credential providers, networks and processors to reject overlapping mandates or invalidate previously issued tokens. That rule covers reuse of a single open mandate. The gap lies between different open mandates, different verifiers and different rails, which is where all three scenarios live.

The same goes for revocation. AP2's implementation considerations say the agent "SHOULD provide a mechanism to manage active Mandates," and the specification recommends setting exp on open mandates "to the smallest value that will allow the Shopping Agent to complete the assigned task." The Delegate SD-JWT draft underneath AP2 discusses credential revocation and the difficulty of distributing status for holder-issued delegations. What the AP2 core lacks is interoperable early revocation with status propagation. Stripe can revoke a token, Tempo can revoke a key, Coinbase and MetaMask can revoke on-chain. Each of those works inside its own system.

Revocation that stays inside one system is not revocation of the principal's authority.

Who keeps the count?

Whoever keeps the state that a signature cannot carry. A spend envelope is a number in a signed object. Enforcing it requires a running total, and a running total is state that someone has to keep, update and serialize.

AP2's reference evaluator makes this explicit. The budget check needs a MandateContext with the amount spent so far and the number of uses, and that context comes from outside the mandate. Leave it out and the check refuses to run. The prose of the spec agrees: evaluating the budget "requires tracking the total amount spent using this Payment Mandate." The mandate states the limit. The verifier's own records decide whether it holds.

AP2 states the budget. Something has to keep the count.

That works when one verifier sees every use. Give two verifiers different slices of the traffic and each ends up with its own count. Let two approvals land at once and you hit the other problem: reading a balance and writing the new one are separate steps.

A signed cap cannot serialize two concurrent approvals.

For that you need check-and-reserve as one atomic step, followed by commit or release.

x402 gets to the same place by leaving it out. Its v2 core separates payment requirements, signed payloads, verification and settlement, and lists client-side budget management as out of scope. That is a reasonable boundary for a payment protocol. It also means the budget lives somewhere the protocol does not specify, which is the gap I described from the stack side in the piece on machine-native money.

Put simply, the count has to live somewhere the agent can't route around, and it has to be consulted before any credential goes out or any payment executes. Once the agent finds one payment path that skips the shared count, the count is just a suggestion. Researchers have started to pin down how hard this gets. Fault-Tolerant Budget Conservation in Distributed Multi-Agent Delegation (Zhu and Wang, submitted 29 September 2026) shows that parent-child allocation limits and distributed escrow, on their own, do not prevent overspend when replies are lost, messages repeat or branches partition, and that refunding on timeout "merely delays discovery of the overspend." Their protocol holds the bound under stated assumptions: one declared enforcement boundary, complete mediation, and a gateway that checks a signed permit before first acceptance. Their own limits section makes this article's point: "Issuer-level escrow is required for an aggregate cap." The catch is who the issuer is. In today's stack the principal does not issue the grants; each system does, so issuer-level escrow has no single issuer to live in. Inside one mediated system, bounding delegated spend is now a formally specified design, not yet a deployed one. Across grants issued separately, or organizations that share no gateway, it remains open.

What would a portable mandate have to specify?

Principal and delegation rights, a budget domain, atomic enforcement, revocation, shared semantics and trust, and evidence kept apart from responsibility. Each is a decision with an owner.

Principal and delegation rights. Which legal or organizational principal stands behind the grant, which signing identity represents them, who may delegate onward, to what depth, and under what rule for narrowing scope at each hop.

Budget domain. Which grants draw on the same spend envelope. How currency and periods work. Plus the accounting nobody enjoys, meaning which of reservations, settled payments, fees, refunds and reversals eat capacity and which give it back.

Atomic enforcement. Who serializes concurrent use, how offline or delayed uses are bounded, and how retries and failures avoid double reservation.

Revocation. Who publishes status, how verifiers discover it, how fresh it must be, what happens to descendants, what a verifier does when status is unavailable, and the point after which a payment cannot be stopped. W3C Bitstring Status List is a usable building block for the publishing half. The freshness and failure questions still need answers of their own.

Shared semantics and trust. Common identifiers for actions and categories, negotiation of which constraints a verifier supports and which issuers it trusts, plus an explicit adapter for each rail, so that card, bank and chain are never assumed to mean the same thing by "limit."

Evidence, kept apart from responsibility. Signed references to the grant and the action, receipts and retention duties. A portable mandate can name an accountable party. Liability itself stays in contracts, scheme rules and law.

The series has used this split before, with the mandate as the object and governance as everything around it. The difference now is that you can actually name the enforcement points.

How would you know a portable mandate works?

By running the shared-quota test. Two independent agents, operated through two different payment integrations, share one parent allowance. The test passes when a concurrent attempt to exceed the allowance is rejected, a descendant grant is rejected after the parent is revoked within a declared time bound, and every accepted and rejected action returns evidence that attributes it to a grant and a principal.

Any architecture that calls itself a portable mandate should pass this. A six-field schema that fails it is a document format. I would rather see one working run of this test across two rails than another specification that lists the fields more elegantly.

When is AP2 enough on its own?

When there is one agent, one open Payment Mandate and one credential provider that sees every use. In that configuration payment.budget with payment.agent_recurrence is a real cumulative cap, the overlap rules cover reuse, and a short exp keeps the exposure window small. In practice, adding a portable mandate on top would be overhead.

The need appears when any of those counts goes above one: more than one grant, more than one agent, more than one rail, or more than one organization. That is the point at which an agent moves into the economic-actor class, and it usually gets there through operation, long after the design was signed off.

What does this not settle?

Liability, regulation and adoption all stay open.

Take liability first. Signatures and receipts will tell you who did what, but who ends up paying for an agent's overspend is settled by contracts, card and scheme rules, and the law. AP2 itself places dispute resolution, retention and retrieval outside its scope.

Regulation: AP2's human-not-present mode describes how the protocol operates, and carries no legal exemption from strong customer authentication. The recurring-transaction exemption in Article 14 of the EU SCA rules is conditional on the same amount and the same payee after the first authenticated payment. As for PSD3 and the PSR, the political deal came in November 2025 and the final compromise texts in April 2026, but neither applies yet.

Adoption is the murkiest of the three. AP2 launched with more than 60 organizations involved, and in April 2026 Google contributed it to the FIDO Alliance. Participation and deployment are different measures. No public AP2 transaction volumes are available, and the one public production implementation report (issue #345) is self-reported and explicitly partial. Two recent security analyses, one of AP2 v0.2 and one formal model of AP2, ACP, MPP and x402, show the protocols are under serious scrutiny. Both work from models and testbeds. Neither reports anything that happened in production.

FAQ

Does AP2 have a spending limit? AP2 v0.2 defines payment.budget, a cumulative cap used with payment.agent_recurrence on a reusable open Payment Mandate, alongside per-payment amount ranges. The cap is scoped to that one mandate, and a second mandate issued separately gets a separate cap.

Can an AP2 mandate be revoked before it expires? Only inside individual systems, where the underlying tokens, keys or credentials can be revoked by whoever issued them. The AP2 core has no interoperable early-revocation mechanism that gets status out to verifiers. It recommends short expiry and says agents should let users manage active mandates.

Can an AP2 agent delegate to another agent? The spec doesn't provide for it yet. AP2 v0.2 covers delegation from user to agent and puts agent-to-agent delegation outside the scope of the current specification. The reference SDK documents a multi-hop presentation pattern that currently fails past the first hop (issue #353, fix proposed in PR #363, both open as of 3 October 2026).

Is "portable mandate" a standard? No. The phrase turns up in a handful of projects, each meaning something slightly different. I use portable mandate here to mean a principal-level grant of authority that keeps an agent's budget, revocation and onward delegation consistent across independently issued grants, tools, payment rails and organizations.

How is this different from wallet spend permissions? Wallet spend permissions, such as Coinbase Spend Permissions or MetaMask caveats, enforce a limit and revocation for one permission or one delegation chain on one account. A portable mandate would have to hold one limit across several such permissions and across rails that are not wallets at all.

What is the shared-quota test? A pass/fail check for any architecture that claims to bound a principal across grants. Two independent agents on two payment integrations share one parent allowance. A concurrent over-budget attempt must be rejected, a descendant must be rejected within a declared time after the parent is revoked, and every decision must return evidence tied to a grant and a principal.

What will the first serious agent payment failure look like?

A set of valid grants, each inside its own limits, that together exceeded what the principal actually authorized. The prediction is testable. If a publicly documented agent payment loss above $1 million occurs by the end of 2027, its root cause will be an aggregate of individually valid grants that exceeded the principal's intended limit, with no forged signature, no compromised key and no single grant used beyond its own terms. A broken signature, a stolen key or one grant abused beyond its terms as the root cause would make me wrong. And if nobody documents a loss that size by then, the question stays open. In the failure it describes, every component will have worked as specified, and that is the part worth designing for now.

If you're new to the series, the earlier pieces are at /topics/agentic-systems. Most of them make one argument, which is that authority, more than model quality, decides whether an agent should get anywhere near money.