Mandates for agentic payments: turning intent into enforceable authority

Core model

A mandate is normalized authority, not a transcript

In agentic payments, natural-language intent is useful input but unsafe as the final authorization object. Phrases such as “book the best refundable flight” or “keep us stocked” leave material choices unresolved: seller, total cost, fee tolerance, timing, quantity, cancellation rules, and whether substitutes are allowed. A mandate converts the principal's goal into typed constraints that a policy engine and counterparty can evaluate without asking a model to decide what permission probably meant.

Google's Agent Payments Protocol distinguishes intent-oriented and transaction-oriented mandate evidence. That distinction is broadly useful even outside one protocol. An intent mandate records the principal's purpose and search boundaries before a specific order exists. A transaction mandate binds approval to the selected seller, items, price, currency, terms, and expiry. The first guides constrained planning; the second authorizes a concrete economic effect. Systems should preserve both when the transaction is selected through an adaptive process.

A mandate should make the permitted transaction computable. If enforcement still requires interpreting the user's prose, normalization is incomplete.

Represent constraints and binding fields explicitly

A production mandate needs a stable identifier, issuer, subject, authorized agent or agent class, scope, validity window, and revocation state. Economic constraints commonly include amount ceilings, currency or asset, merchant allowlists, category restrictions, item requirements, frequency, cumulative budget, geography, refundability, and conditions requiring step-up approval. The exact shape depends on the use case, but omitted fields should be deliberate rather than silently interpreted as unlimited.

The transaction binding should reference an immutable order snapshot or canonical hash. A checkout session URL alone is insufficient because the underlying cart may change. Include the merchant identity, destination, line items or resource, amount, fees, currency, relevant terms, and expiry that the principal saw. Canonicalization rules must be versioned so independent participants produce the same digest; otherwise a signature can be valid while the parties disagree about what was signed.

Treat issuance, delegation, and revocation as security events

Mandate issuance begins in an authenticated principal context. The service should display or otherwise communicate the normalized constraints, record the authentication method, and bind the approval to the mandate bytes or canonical representation. Signing belongs in an isolated service or trusted client boundary, not inside the model runtime. The agent may propose a mandate, but it should not control the identity proof, approval ceremony, signing key, or policy that decides whether the mandate is issuable.

Delegation should remain monotonic: a derived mandate can narrow an upstream mandate but cannot extend its amount, duration, merchants, purposes, or transferability. Every verifier needs the chain and a deterministic rule for combining constraints. Revocation is equally important. Systems must define whether revocation stops only new execution or also cancels pending orders, how status is distributed, what happens during verifier outages, and which evidence proves that a verifier checked the current state before accepting a payment.

• Authenticate the principal independently of agent-provided claims.
• Show material normalized constraints at approval time and store the exact approved representation.
• Use nonces, expiries, audience restrictions, and transaction binding to reduce replay and confusion.
• Permit sub-delegation only when every derived constraint is equal to or narrower than its parent.
• Fail closed when a required mandate, signature, version, or revocation check cannot be verified.

Keep the mandate understandable beyond one protocol

A mandate is most valuable when it survives system boundaries. Preserve the original artifact, canonical bytes or digest, signatures, issuer metadata, verification result, applicable policy version, and references to the resulting order and payment. Do not reduce the record to a boolean such as `authorized=true`; that erases the constraints and makes it impossible to determine whether a later refund, retry, or merchant change remained within the principal's authority.

Protocol interoperability does not require forcing every external schema into one universal object. Maintain a stable internal authority model, store external artifacts alongside it, and record the mapping version and any information that could not be represented. AP2 mandates, seller-scoped payment tokens, network credentials, and internal spend rules can participate in the same transaction while owning different responsibilities. The architecture should expose those boundaries instead of suggesting one signed object solves identity, commerce state, settlement, and recourse.

• Validate mandates against published schemas and pin the protocol version used for each decision.
• Store human-readable summaries for operations without treating summaries as the signed source of truth.
• Link superseded mandates rather than overwriting them, so the authority history remains inspectable.
• Test cross-system canonicalization with shared fixtures before accepting third-party signatures.
• Include mandate identifiers in receipts, reconciliation events, and support tooling without exposing sensitive contents publicly.