AI Agent Payment Mandates: How AP2 Limits Spending

An AI agent payment mandate is verifiable authorization for an agent to pay on someone’s behalf under defined terms. In AP2, a checkout mandate covers the purchase, while a payment mandate covers payment for that checkout. The systems accepting them must verify the authority and its limits.

Giving an agent access to a company card leaves an obvious question: what is it allowed to buy?

Looking for the payload fields and checkout binding? Use the AP2 payment mandate field reference. This guide focuses on spending limits and how accepting systems enforce them. The Agent Identity Learning Center connects both guides to the wider commerce reading path.

“Keep it reasonable” is a conversation. A mandate gives participating systems something more precise to check: the approved transaction or the boundaries within which the agent may choose one.

Checkout mandate and payment mandate: two different approvals

The AP2 checkout mandate authorizes completion of a checkout. For a closed mandate, the merchant-signed checkout object and its hash connect approval to particular purchase details. The merchant verifies the mandate.

The payment mandate authorizes payment for the associated checkout. Its content includes the payee, payment amount, and payment instrument, with a transaction reference linking it to that checkout. Verification involves the credential provider, network, and merchant payment processor.

Approval to buy one item should not become a reusable excuse to pay for an unrelated cart.

A mandate carries authority. The payment integration still has to execute the transaction. Our x402, AP2, and MPP comparison explains how authorization and payment mechanisms fit together.

Open mandates allow a choice. Closed mandates identify the transaction.

AP2’s Agent Authorization Framework distinguishes two states. An open mandate delegates constrained authority to an agent whose key it identifies. A closed mandate is bound to the particular transaction presented for authorization.

In a human-present flow, the user can approve the completed purchase details. In an autonomous flow, the user approves constraints first, and the agent later binds the permitted transaction to that authority. The AP2 flow documentation describes these paths.

Open does not mean unlimited. It means some choices remain to be made within the approved boundaries.

Turn a shopping request into explicit limits

Imagine an office manager asks an agent to buy one replacement monitor. The following is an illustrative approval brief, not an AP2 payload:

• Buy one monitor from the approved product list.
• Use one of the approved merchants.
• Keep the final charge, including applicable tax and shipping, at or below $300.
• Use the designated company payment instrument.
• Complete one purchase before the approval expires.
• Ask again if no eligible offer meets those terms.

A $280 monitor with $35 in additional charges does not meet that brief. Neither does a second monitor, even if each costs less than $300.

The application must translate the brief into supported checkout constraints, payment constraints, and any additional enforced policy. Do not paste these sentences into a field and assume every verifier understands them.

AP2 documents allowed merchants and line items for open checkout mandates. Its payment constraints include allowed payees, payment instruments, amount ranges, budgets, recurrence, and execution dates. A per-purchase ceiling and an aggregate budget solve different problems; recurring use needs accounting for earlier uses.

What the verifier must establish

A valid-looking JSON object is not sufficient. The verifier must establish that the authorization came through a trusted approval path and applies to the action being requested.

Under AP2’s framework, verification includes the cryptographic mandate chain, unchanged claims inherited from the open mandate, and evaluation of every constraint. Unknown constraints fail evaluation. An unresolved_constraint result may lead to direct approval or another supported flow; it does not permit silently dropping the condition.

AP2 uses SD-JWT-based credentials for its described mandate format. Selective disclosure allows relevant information to be presented without exposing every approved alternative. Key binding connects autonomous use to the endorsed agent key.

For implementation, use the current AP2 specification and the exact schemas supported by your integration. A blog example cannot substitute for signature verification, trust configuration, or a compatible implementation.

Enforce the boundary outside the agent’s reasoning

The agent may choose an offer, but the components that release credentials and accept the purchase need to enforce the approved terms.

AP2’s security considerations include manipulated checkouts, stolen credentials, and agents attempting transactions outside the user’s approval. They require checks connecting payment authority to the relevant checkout and its constraints.

A product page saying “the buyer has approved an upgrade” cannot amend the user’s mandate. If the requested transaction no longer fits, obtain new authority through the trusted approval path.

Protect the delegated signing key as well. A limit in the prompt is a weak substitute for a payment component that refuses an out-of-bounds transaction.

Reuse requires more than an unexpired signature

Before reusing authority, the implementation needs to account for its permitted frequency, remaining budget, prior uses, and any applicable expiry or lifecycle controls. Two workers must not each assume they can spend the same remaining allowance.

The AP2 implementation guidance is the place to check operational requirements alongside the specification. Define how your own integration stops future use and handles in-flight transactions. Do not promise that changing a public profile revokes payment authority already issued elsewhere.

Keep authorization results attached to the relevant mandate. Payment confirmation and delivery are separate outcomes, covered in our guide to payment receipts and purchase evidence.

Where a Headless Domains name helps

A mandate identifies authority through its verified credentials and keys. A persistent public name can help people and compatible agents recognize the actor across services and find the information its operator maintains.

For example, a procurement agent may appear in a directory, use a company-controlled runtime, and interact with several merchants. A Headless Domains identity can connect its public profile to operator information, service endpoints, and machine-readable manifests.

The manifest reference describes those public records. Your integration still needs a verified mapping between the public identity and the credential or key used in the transaction.

AP2 does not require a Headless Domains name. Registering one does not create a mandate, establish a merchant’s trust relationship, or grant access to a payment instrument. The name helps identify the actor; the accepting systems decide whether its presented authority is valid.

Keep mandates and buyer information in access-controlled systems. Publish only the service information appropriate for public discovery. The Agent Identity Stack explains the broader separation between public identity, authentication, and authorization.

Start with a purchase the agent must refuse

In your integration’s sandbox, take an approved purchase and change one condition: exceed the total, select a different payee, present an unsupported constraint, or attempt another purchase after the allowance is used.

Check that the responsible verifier rejects it or requests the required new approval. The agent explaining why it should stop is not the same as the payment system stopping it.

Once those boundaries work, give the agent a public identity that stays recognizable as its tools change. Send it to the Headless Domains skill file and ask it to explain registration requirements before taking action.