AI Agent Spending Limits: What x402, AP2, ACP and MCP Define, and Where Limits Fail

This table records what each published specification says. It does not describe any particular deployment, which may add controls on top.

These cases come from the Agent Payment Risk Index^[12]. Only the first involves an AI agent, and it ran in a sandbox. We include the others because they show how a limit fails, not because they are agent incidents.

1. No limit configured.Zscaler ThreatLabz described web pages that hide instructions telling a browsing agent to buy a fake $3.00 developer license, with page code that sends about 0.0012 ETH. In its sandbox test the agent "was configured with no spending limits to measure the maximum potential exploitation surface". Across 26 models, 4 "failed to take appropriate actions"^[9]. A cap would have bounded the amount. It would not have stopped the payment, because the payee and the intent were wrong, not the size.

2. Limits checked per item, not in aggregate.On 1 August 2012, Knight Capital's automated router sent more than 4 million orders in 45 minutes while trying to fill 212 customer orders, and the firm lost more than $460 million. The SEC found that Knight "relied on financial risk controls that were not capable of preventing the entry of orders that exceeded pre-set capital thresholds for the firm in the aggregate" ^[10]. This was not an AI agent. It shows the same gap in automated spending: each order looked acceptable, and nothing enforced the total.

3. Limit checked against stale state.Ling et al. describe an "allowance overdraft" on x402's upto scheme. Verification is a snapshot check that the payer has authorized enough. The check is non-binding and locks no funds, so many concurrent requests can pass against the same remaining allowance. Settlement later reverts the excess, but the service has already been delivered^[11]. In this case the loss falls on the seller. The lesson is the same either way: a limit read from a snapshot is not a limit under concurrency.

The x402 papers do not report a production-loss dollar total. Our x402 security risks summary covers them in more detail.

1. Set a per-payment cap and a cumulative cap per period for each agent. Enforce both outside the agent's own runtime, so a manipulated agent cannot raise them.
2. Make the cumulative check atomic. Reserve the amount when the payment is authorized and release it if settlement fails, so concurrent requests cannot all pass against the same balance.
3. Scope every limit by payee. Hold the first payment to a payee that isn't on the allowlist, and any change to a payee's details.
4. Scope limits by asset and network as well as amount. Know which assets your client library caps by default and which it leaves uncapped.
5. Give every authorization an expiry and a revocation path. Prefer short windows for autonomous flows.
6. Fail closed. An unknown constraint, a check that errors, or a missing limit should deny the payment, as AP2 requires for unknown constraints.
7. Check the payment against the principal's instruction, not against text the agent retrieved while working.
8. Require human approval above a threshold and for counterparty changes, rather than on every payment, so reviewers aren't flooded.
9. Record the limit that applied, the remaining balance, and the rule that fired before settlement, so every decision can be reconstructed later.
10. Review client-library defaults on every upgrade. A default cap is only a control if you know it is on.