Enforcing agent spending limits across x402, AP2 and delegated checkout

Goal

Status as of 25 October 2026. Make each payment attributable to a bounded user authorization, including unattended purchases and retries. Re-check x402's scope, AP2 constraint schemas and the chosen ACP snapshot before implementing this proposed procedure. Protocol fields support controls; an independent enforcement component must actually apply them.

Prerequisites

Use a payment gateway or signer that enforces policy outside the model, a durable authorization ledger, authenticated approval interfaces and access to payment-status records. Define ownership for unresolved transactions. Record the protocol revision, currency or asset, amount representation, permitted destinations and expiration for each authorization before allowing spending.

Steps

1. Set a per-transaction cap. AP2's Payment Mandate defines payment.amount_range. ACP's delegated allowance provides max_amount, currency and expiry. For x402, compare the advertised payment requirements with local policy before signing. Apply the cap to the final authorized amount, including charges included in the checkout total.

2. Account for cumulative spending. AP2's payment.budget, used with payment.agent_recurrence, requires the requested amount plus amounts from previous closed mandates to remain within the maximum; approval adds the amount to the accumulated total. Implement the check and reservation atomically in shared storage. As a proposed accounting rule, hold unresolved attempts against available budget until their outcome is reconciled. x402's core specification excludes client-side budget management.

3. Restrict destinations and instruments. AP2 provides checkout.allowed_merchants, plus payment payee and instrument constraints. ACP binds its allowance to a merchant and checkout session. For x402, maintain an external allowlist covering resource origin, payment recipient, asset and network. Do not treat descriptive merchant text as a verified identity.

4. Bind human approval to concrete terms. Show the buyer the destination, items, full amount, payment instrument and expiry. For prior delegation, show the permitted bounds instead. AP2's authorization framework requires constraint evaluation and treats unknown constraints as failures. Its unresolved_constraint response can trigger direct approval. As local policy, require renewed approval for changes outside the approved scope, even if a payment credential remains technically usable.

5. Link evidence without leaking credentials. Record approval and mandate references, the policy decision, reserved amount, checkout or resource identifier, payment identifier and final outcome. AP2 Payment Receipts link to the closed mandate and carry payment status. Keep sensitive signed credentials in a restricted evidence store; routine audit logs should contain references rather than reusable payment material. Reconcile payment and delivery separately.

6. Exercise refusal paths before launch. In a non-production environment, try an expired approval, disallowed merchant, changed currency, amount above the cap, overlapping purchases and an interrupted response. Verify that rejected attempts create no new authorization and unresolved attempts do not silently restore spending capacity. These are proposed acceptance checks, not claimed test results.

Expected result

Every allowed attempt has a traceable approval, a budget reservation and an eventual reconciled outcome. Rejected requests remain explainable without granting the model authority to override the decision. A reviewer can distinguish requested, authorized and completed spending.

Limits and test basis

This procedure has not been exercised against payment providers. Cross-provider budgets need shared accounting beyond individual protocol objects. AP2's amount-range table specifies integer minor units while one example uses decimals; resolve that inconsistency with the implementation contract before accepting amounts. No conversion is inferred here. Signed receipts document protocol outcomes; they do not prove physical delivery.