A Valid Mandate Is Not Current Execution Eligibility
Google's Agent Payments Protocol, now at v0.2 and handed to the FIDO Alliance, gives agentic commerce cryptographically signed mandates with transaction binding, optional expiration, and constraint checking — a genuinely strong answer to whether an agent's purchase stays inside what a person delegated. The protocol's own error codes, warnings, and scope statements show where that answer stops: a mandate can prove an execution is covered by delegated authority without proving that everything required to execute still holds now.
What happens
Google announced the Agent Payments Protocol in September 2025 with more than sixty partners across card networks, processors, and fintechs. In April 2026 it released v0.2 and donated the protocol to the FIDO Alliance, alongside Verifiable Intent, a companion standard co-developed with Mastercard. The v0.2 headline was autonomous, “human not present” payments: an agent securing limited-run tickets the moment they go on sale, on pre-authorized instructions.
The mechanism is worth stating precisely, because the precision is the point. AP2 v0.2 defines two signed proofs bound to the same purchase: a Checkout Mandate, proving to the merchant that the agent is authorized to buy the assembled checkout, and a Payment Mandate, proving to payment actors that the agent is authorized to pay for it. Each can be open — carrying constraints a person approved in advance — or closed — bound to one specific transaction. When the person is present, they approve the closed mandates directly. When they are not, they approve open mandates up front, and the agent assembles and signs closed mandates within those constraints.
The bindings are cryptographic: the closed Checkout Mandate is tied to the merchant’s signed checkout by hash, the Payment Mandate is tied to that same hash, and the merchant payment processor verifies that the payment credential is scoped to that checkout — including the mandate binding used to establish that scope — with signed checkout and payment receipts returned to the relevant participants. Mandates can carry an expiration. If a closed mandate does not resolve against the open one’s constraints, the merchant or credential provider can return an unresolved_constraint error and bring the person back into the loop. This is not a passive record. It is an authorization mechanism with checks at the point of action.
The usual reading
One reading says the trust problem of agentic commerce is being solved in-protocol: signature, binding, expiry, constraints, and a human fallback. The skeptical reading says no protocol can make autonomous spending safe.
Both readings share an assumption — that “authorized” is one question with one answer. AP2 is strong precisely because it answers one version of that question very well. The version it answers should be named exactly.
What the verifier checks, and what it checks against
At the moment of execution, an AP2 verifier establishes that the mandate’s signature chain is intact, that the closed mandate is bound to this checkout and no other, that the mandate has not expired where an expiry is present, and that the proposed transaction satisfies the constraints the person encoded. Many of those checks are evaluated against the mandate chain and its encoded constraints — the authorization object, as written at signing time. Others already reach into transaction state: the merchant, for example, verifies the closed Checkout Mandate against the current cart. AP2 therefore already demonstrates the principle this essay is about — execution-time authorization sometimes requires information that is not contained in the authorization artifact itself.
That is a lot, and it closes gaps that earlier agent-payment schemes left wide open. The question is not whether runtime state enters the decision — it already does — but which runtime state does. A constraint like “up to five hundred dollars, these categories, this month” is a description of permitted actions. It is not a description of the world at the moment an action is attempted. Expiration, where present, is not revocation. Constraint satisfaction is not current-state authorization. A mandate can be cryptographically valid, unexpired, fully satisfied by a transaction, and consistent with the current cart — and the world can still have changed in ways the mandate has no field for.
The seams the specification names
The most useful evidence here comes from AP2 itself, not from its critics.
The specification warns that an agent must not present further open mandates without a rejection receipt, to prevent multiple checkouts against the same open mandate, and its implementation guidance describes agent key binding and receipt management as the defense. The protocol therefore needs execution history — prior presentation, rejection, receipt, and in-flight state — in addition to the mandate’s signed content. Authorization object plus execution history: AP2’s own design says the object alone is not enough.
The unresolved_constraint path is a second seam, drawn honestly. It is a defined error for the case where a verifier cannot establish that an agent-assembled closed mandate is covered by the constraints the person approved, and the specified response is not to force the action through but to fall back — to direct approval, returning the decision to a human. In FO’s terms, the protocol already recognizes one class of case in which autonomous execution must stop because the verifier cannot establish that the proposed action is covered by the delegated authority.
The third seam is a scope statement. AP2’s implementation guidance says long-lived mandates should be manageable — a shopping agent should provide a mechanism for it — while the management of delegated mandates through external trusted surfaces remains outside the specification’s scope. That distinction matters. The protocol can verify the mandate presented for an action. The state that determines whether a previously delegated mandate should still remain usable may live somewhere else. None of this is a flaw to score against AP2. It is where the protocol has said, in its own vocabulary, that its object ends and current state begins.
Two different objects
Mandate validity. A property of the authorization object and its immediate transaction context. It is settled by signature, binding, constraint resolution, expiry where present, and consistency with the checkout being paid for — checks that can be performed deterministically by the parties AP2 defines. Its strength is that nearly all of it can be settled from the mandate chain and the transaction in front of the verifier.
Execution eligibility. A property of the present moment. It may depend on state that changed after the object was issued: the person withdrew the delegation; the account was suspended or frozen; the rights attached to the payment instrument changed; the relationship between person and agent ended; the risk posture shifted; an operational policy now forbids this action. None of these are fields in a mandate, because a mandate is a record of what was delegated, not a sensor of what is true.
Collapsing the two means treating a valid mandate as sufficient for execution — letting the presence of a checkable object answer a question the object was never asked. The stronger the object becomes, the easier the collapse: v0.2 checks more than v0.1 did, and every check it absorbs makes the remaining gap look smaller than it is.
Where this is heading
The trajectory is instructive. AP2 has been pulling parts of the authorization problem inside the protocol — expiration where present, constraint resolution, the cart-state check, receipt management, the human fallback — and it will likely absorb more. That is the right direction, and it does not close the boundary; it clarifies it. The chain now reads: signature → transaction binding → constraint resolution → mandate validity → transaction-state verification — and then one more arrow, to current execution eligibility, that no property of the mandate chain or the checkout in front of the verifier can supply on its own: the account, the credential, the delegation itself, the risk posture, the policy. Every improvement to the object sharpens the edge of what the object is not.
This is the same shape this series found at payment batches and vendor-risk desks: the artifact produced upstream keeps getting better, and the question of what may happen now keeps concentrating into the one step the artifact cannot reach.
The proposition
An agent arriving with a valid mandate may carry proof that the person delegated this class of action, that the mandate has not expired where an expiry was set, that the proposed transaction satisfies its encoded constraints, and that it matches the checkout being paid for. That still does not establish that the execution is eligible now. Mandate validity is evaluated against the authorization object and the transaction in front of the verifier; execution eligibility may also depend on state that changed after that object was issued — the account, the credential, the person-agent relationship, the risk conditions, or an external policy capable of stopping the action.
The mandate answers whether this execution is covered by delegated authority. The execution boundary answers whether that covered action may proceed now.