If I let an AI shopping agent buy something for me later using Google's Agent Payments Protocol (AP2), how do I limit what it can spend while I'm not there? What do open Payment and Checkout Mandates actually cap, and who enforces it?

What should I check, step by step?

1. Ask whether your agent and wallet support AP2 v0.2 open mandates at all. The spec is a 0.x draft. Google's FAQ says the core specification work continues in FIDO, and you can only use the constraints your credential provider verifies.

2. Put a per-payment ceiling on every open Payment Mandate with payment.amount_range (max, plus currency). A verifier must reject a payment in a different currency or outside the range.
3. For anything repeating, such as a monthly reorder, pair payment.agent_recurrence (frequency and max_occurrences, for example MONTHLY and 12) with payment.budget (max total). The spec defines the budget for use with recurrence, so don't count on it for a one-off purchase.
4. Name the payees. payment.allowed_payees and checkout.allowed_merchants stop the agent paying a merchant you didn't approve, even if a prompt injection steers it to one.
5. Pin the instrument with payment.allowed_payment_instruments, so the agent can't switch to a different card or account you hold with the same provider.
6. Give every open mandate a short life. The spec recommends setting exp to the smallest value that lets the agent finish the task, and payment.execution_date can add a not_before/not_after window. The v0.2 docs define no revoke step, so expiry is your off switch.
7. Use checkout.line_items when you know what you want (for example, one of two acceptable product IDs at quantity 1), so a merchant can't substitute a different item at the same price.
8. Keep the receipts. Verifiers must return a signed Mandate Receipt (success or error, with codes like invalid_mandate and unresolved_constraint). Those receipts, and the merchant's Checkout Receipt, are your record of what the agent bought under which mandate.
9. Keep a cap of your own outside the agent too, such as a card or wallet limit. AP2 bounds what verifiers accept, but double-spend protection still partly relies on the agent.

How do AP2 open and closed mandates let an agent pay without me?

AP2 separates two cases. With the human present, you see the final cart and approve it directly. With the human not present, you first approve open Checkout and Payment Mandates on a trusted surface. These are SD-JWT verifiable credentials holding constraints rather than a fixed cart, and they're bound to the shopping agent's public key through a cnf claim. Their types are mandate.checkout.open.1 and mandate.payment.open.1.

• When the agent later finds a checkout it thinks fits, it signs closed mandates (mandate.checkout.1 and mandate.payment.1) for that exact checkout and amount with its own key. It presents the open and closed mandates together. The open Payment Mandate includes a hash of the open Checkout Mandate, which links the two permanently, and the payment.reference constraint ties a payment to that checkout chain.
• Verifiers always receive closed mandates. They check the chain and that the closed mandate leaves the open mandate's claims unchanged, then evaluate every constraint. The spec says any unknown constraint MUST be treated as failing evaluation. Selective disclosure means the agent shows a verifier only the constraints relevant to that purchase.
• AP2 v0.1 (September 16, 2025) described an Intent Mandate for this case. In v0.2, open Checkout and Payment Mandates fill that role, so older tutorials may use names that no longer match the spec.

What do AP2 amount range, budget and recurrence constraints check?

payment.amount_range: the closed payment amount must be between min and max, and its currency must match the constraint's currency. payment.budget: the requested amount plus the total of previously closed Payment Mandates under the same open mandate must be at most max, and the spec says the amount MUST be added to the running total after approval. payment.agent_recurrence: each use must be far enough from the previous one to meet the frequency, and within max_occurrences.

• payment.allowed_payees, payment.allowed_payment_instruments and payment.allowed_pisps each require the closed mandate's value to appear in an allowed list. payment.execution_date requires the execution date to fall between not_before and not_after where those are set. On the checkout side, checkout.allowed_merchants and checkout.line_items limit where the agent can buy and which items, in which quantities.
• If a verifier can't evaluate a constraint, it returns unresolved_constraint, which the spec says may be used to fall back to a directly approved closed mandate or a non-agentic flow. In practice, that means asking you.

What can an AI agent still do within an AP2 open mandate?

Budgets and recurrence need state. The spec says evaluating them requires tracking previous presentations, so they're only as good as the verifier's record. The double-spend rule mostly sits with the shopping agent: it MUST NOT sign overlapping closed mandates for the same open mandate without first receiving receipts rejecting the earlier ones, and those receipts must be protected from its LLM. Credential providers, networks and processors MAY reject overlapping mandates or invalidate earlier payment tokens.

• AP2's security notes say constraint enforcement keeps the worst case "strictly bounded" when prompt injection makes an agent choose badly. Bounded isn't zero, though. An agent can still spend the whole range on a poor choice from an allowed merchant. So set the ranges to what you'd be comfortable losing, not just what the task might cost.
• There's no revoke step in the v0.2 docs, and agent-to-agent delegation of mandates is out of scope. Mastercard's Verifiable Intent, co-developed with Google and contributed to FIDO alongside AP2, covers how the user's authorization is recorded as evidence. FIDO's Payments Technical Working Group, chaired by members from Mastercard and Visa, is developing the specifications, so details may change.