AI agent spending goes wrong in four minutes, not four weeks

The thing nobody tells you about runaway AI agent spending is how short it is. There is no gradual drift, no month of creeping costs somebody eventually queries. There is a Tuesday night, four minutes, and a bill. This is a minute-by-minute anatomy of how that happens (a composite of the failure pattern we see most often), the four places it could have been stopped, and why only the last one works when nobody is awake.

22:41, a webhook is dropped

A research agent buys market data over x402. About £0.004 a call, roughly 600 calls a day, £2.40 or so. It has run for eleven weeks without incident. Its ai agent spending is about as boring as a budget line gets.

At 22:41 the provider has a brief blip. One settlement confirmation never arrives.

Nothing has gone wrong yet, exactly. A packet was lost. This happens constantly and is almost always harmless.

22:41:03, the agent does not know it paid

The agent's logic is reasonable, and it is the logic almost everyone writes: if the payment did not confirm, the payment did not happen. Retry.

It retries. The retry succeeds and the money moves, but that confirmation is queued behind the same congestion.

So it retries again.

This is the whole mechanism. No attacker, no injection, no compromised key. An agent that cannot see its own settlements, doing exactly what it was built to do, correctly.

22:41:12, the loop closes

By the twelfth second there have been eleven attempts. Each one settles. None confirms in time.

Here is the property that makes this expensive: the loop is self-reinforcing. Every retry adds load, load adds latency, latency delays confirmations, delayed confirmations trigger retries.

The agent is now paying about three times a second.

22:45, four minutes in

720 payments. £2.88.

Still nothing anyone would notice. This is the part worth dwelling on, because it is where intuition fails. Four minutes of a runaway costs less than a coffee. The instinct is that there is plenty of time.

02:00, three hours later

At three payments a second, uninterrupted, that is roughly 32,000 payments an hour.

£128 an hour. £384 by 02:00.

Somewhere around here the provider's rate limiting kicks in, which slows the loop without stopping it, because a rate-limited request that fails is a request the agent retries.

07:30, someone opens a laptop

£1,100. Roughly 458 days of normal spending, in nine hours, from an agent whose job is buying £0.004 API calls.

The reconstruction takes most of the morning, and the finding is deflating: no fraud, no bug in the payment code, no misconfiguration. A dropped webhook and a retry policy that any reasonable engineer would have written.

Four places ai agent spending could have stopped

Table: four natural interventions in a runaway. Three of them help; one of them works at 02:00 with nobody watching.

Retry-loop detection is the earliest and the most precise. Three identical merchant-and-amount repeats inside five minutes is an unambiguous signature. Spend7 weights it up to 30 points out of 100, heavier than a first-seen merchant, because a loop is nearly always a defect rather than a judgement call.

But 30 points alone does not reach the deny threshold of 80. Combined with a velocity burst it lands in flag territory. Which brings us to the trap.

A flag is not a stop unless your code makes it one. If the client logs the flag and settles anyway, you have produced a beautifully detailed record of a loss you watched happen.

Alerting would have fired at 22:41 and been read at 07:30. That is not a control. It is a notification about something that already finished.

The rolling spend cap is the only one that works while everyone sleeps. It needs no detection, no cleverness, and no one awake. Just a number, set in advance, held where the agent cannot reach it.

"Every runaway we have looked at was stoppable by a cap somebody had considered setting and had not got round to. Not by better detection. The cap is boring, it takes four minutes, and it is the entire difference between a bad night and a bad quarter."

the Spend7 engineering team

What the cap would have done

Suppose that agent had a rolling daily cap of £25 (ten times its expected spend, deliberately generous, set in the "this will never bind" spirit).

The loop starts at 22:41. It burns through £25 in about twelve minutes. Every payment after that is denied.

Total exposure: £25 instead of £1,100.

The loop keeps running, because the cap does not fix the agent. It just stops the agent's confusion from being expensive, which is the entire job of a limit on ai agent spending. In the morning, someone reads a log full of denials, finds the dropped webhook, and fixes the retry policy (the same fix, arrived at through a £25 lesson).

Note what did not have to be true. Nobody had to predict a webhook failure. Nobody had to be awake. Nobody had to tune anything. A number set once, months earlier, in four minutes.

Common pitfalls when capping ai agent spending

Setting the cap tight. The temptation is a precise cap matching expected spend. Then it binds on a legitimate busy day, someone raises it in a hurry, and eventually someone disables it. A generous cap that survives beats a precise cap that gets switched off.

Treating a flag as advisory. Covered above and it is the most common way a working detector produces no benefit at all.

Counting denials against the cap. A denied payment moved no money. Count denials and the loop's own refusals consume the allowance, blocking the legitimate payment behind it.

Per-payment limits only. Every payment in this story was £0.004. No per-payment ceiling would ever have fired. Rolling windows are what see the aggregate.

Assuming idempotency solves it. It helps enormously and it is not sufficient. Idempotency at the provider stops double-charging for the same key; a client generating a fresh key per attempt is not repeating a payment as far as anyone downstream can tell.

What to set this week

Four minutes of work, in this order:

1. Give each agent a distinct identifier.
2. Set a rolling daily cap at ten times expected spend.
3. Set a per-payment ceiling that would catch a decimals error.
4. Make sure a deny actually prevents settlement in your code; test it with a £1 cap and a £5 payment.

Step four is the one that gets skipped and the one that decides whether any of the rest matters.

How to set x402 spend limits has the request shape, spend limits for AI agents covers scopes and windows, and autonomous agent payment monitoring covers what to watch once the cap is in. If you want the wider threat picture, OWASP's GenAI Security Project is the reference, though as this story shows, the expensive failure usually is not an attack at all.