A traditional bug usually fails loudly. A runaway AI agent fails quietly, and it fails expensively. It keeps calling the model, every call succeeds, nothing crashes, and the bill grows until someone looks at it.
OWASP lists this as LLM10:2025 Unbounded Consumption. It names the financial version "Denial of Wallet": attackers, or simply bugs, trigger a high volume of operations and exploit the cost-per-use model of cloud AI services. You don't need an attacker for this. A loop in your own code is enough.
It isn't only loops: three incidents from 2026
All three were reported publicly. None was an agent loop. Each was a key with no ceiling of its own.
- About $600,000 of model credits in three weeks. METR, the AI evaluation lab, had an API key taken from an exposed cloud instance. It said it had no way to cap spending on that key at the time (METR, 31 Aug 2026; Infosecurity Magazine).
- $82,314 in about 48 hours. A three-developer company in Mexico had a Google API key compromised. Its normal bill was about $180 a month (The Register, 3 Mar 2026).
- $14,000 in one day. A three-person agency had static access keys extracted and used to run Claude on Amazon Bedrock. The same report notes that cloud billing lags about a day behind this kind of spend (InfoQ, 16 Jul 2026).
The controls below apply to both cases: the loop you wrote yourself, and the key somebody else is using.
This post walks through what a runaway looks like in numbers, five controls you can put in place, and what each one misses.
What a runaway costs
Take an agent that gets stuck. A tool call fails, the agent decides to retry with the full conversation, and it never gives up. Assume, for illustration only:
- 20 model calls per minute
- 8,000 input tokens and 1,000 output tokens per call
- a model priced at $3 per million input tokens and $15 per million output tokens (illustrative, not any provider's current price)
One call costs 8,000 × $3 / 1,000,000 + 1,000 × $15 / 1,000,000 = $0.024 + $0.015 = $0.039. At 20 calls a minute, that is $0.78 a minute. Over an 8-hour night (480 minutes), it comes to about $374.
Change the assumptions and the number changes, but the shape doesn't: small per-call cost, high repetition, nobody awake.
Control 1: Limit the loop in your own code
Cap the number of steps an agent can take per task, set a timeout on each run, and cap the output length (max_tokens). OWASP's mitigation list includes timeouts and throttling, and limiting queued and total actions.
Works well when: you own the agent code.
Where it breaks: it only protects code you remembered to limit. A new service, a script, a framework default, or a retry inside a library can run without any cap. And it limits steps, not money: ten expensive steps can cost more than a hundred cheap ones.
Control 2: Use your provider's spend limits
The big providers now offer spend limits, and you should turn them on.
- OpenAI: organization-level and project-level hard limits. When a hard limit is reached, requests fail with HTTP 429. OpenAI's docs also state that alerts only notify and "do not enforce a cap", and that "enforcement is not instantaneous, so recorded spend can slightly exceed the configured amount."
- Google Gemini API: a monthly spend cap per project in AI Studio. Google says spend caps have a delay of about ten minutes and that users are responsible for overages incurred in that period.
- Anthropic: the spend limit API for Console organizations sets
organizationandworkspacelimits, which are monthly. At the time of writing, setting them through the API is an early access preview.
Works well when: you want a last line of defense so that a worst case has a ceiling.
Where it breaks: the limits are coarse. They apply to an organization, project or workspace, not to one agent, one team or one customer. When the cap is reached, everything on that project stops, including the healthy traffic. And because enforcement lags, the real spend can overshoot the cap.
Control 3: One project or key per agent
Because the provider limits work at project or workspace level, a useful trick is to give each agent or service its own project and set a limit on each one. A runaway then hits its own ceiling and not the whole company's.
Works well when: you have a handful of agents and want a hard ceiling for each.
Where it breaks: the same problem as one key per customer. Creating, storing and rotating keys grows with every agent. It also doesn't answer which feature or which customer caused the cost.
Control 4: Alerts and anomaly detection
Alert when spend per hour jumps, when one key's usage doubles, or when requests per minute passes a threshold. OWASP recommends logging, monitoring and anomaly detection for exactly this reason.
Works well when: somebody is awake to act on the alert.
Where it breaks: an alert tells you a problem is happening. It does not stop it. The runaway in our example costs about $0.78 a minute while the alert sits in an inbox.
Control 5: Check the budget before the call
The fifth control puts a layer between your app and the provider. Before each call it checks whether a budget would be exceeded, and if so refuses the call before the provider charges anything. A kill switch works the same way, on demand.
This is the control that a provider dashboard can't give you, because it needs to know about your agents and teams, not just the provider's projects. Open-source gateways such as LiteLLM can do this, and we built TOLVYN to do it as a hosted service. In TOLVYN, a hard budget (on Starter and above) can apply to an organization, team, service, agent or individual API key, so a stolen key has a ceiling too. The check happens at the proxy using a conservative estimate of the call's cost, and a refused call returns HTTP 429. A kill switch stops a team, service or agent on demand, from the dashboard, the API or the CLI.
Trade-offs, honestly:
- It is one more service in the request path. Start with one non-critical service and measure the latency yourself. (In our own benchmark TOLVYN adds about 5 ms at p50 and about 9 ms at p95. Measure yours.)
- The check is based on an estimate, not the final bill, so it is conservative by design.
- Hard budgets today work per organization, team, service, agent or API key. They do not yet work per individual end customer or per agent run; both are being built.
- TOLVYN does not yet detect a loop automatically. It stops spend when a budget is hit, not when a pattern looks like a loop.
- If an SDK falls back to the provider directly while TOLVYN is unreachable, those calls aren't metered.
Which ones should you use?
You don't pick one. They cover different gaps:
- Limit the loop in your code, because it is the cheapest fix.
- Turn on provider spend limits as the final ceiling.
- Separate projects for your riskiest agents, if you have only a few.
- Alerts, so someone knows.
- A pre-call check or kill switch when you have many agents, teams or customers and need to stop one without stopping everything.
And whichever you choose, test it. Make a deliberately bad loop in a sandbox and see which control stops it, and how much it costs before it does. The point of the exercise is to learn the number before your first real incident.
If you want to see per-agent cost on your own calls, TOLVYN is free up to 10,000 requests a month, no card needed: tolvyn.io.
Sources: METR security update, 31 Aug 2026 · The Register, 3 Mar 2026 · InfoQ, 16 Jul 2026 · OWASP LLM10:2025 Unbounded Consumption · OpenAI: Spend limits · Google: More control over Gemini API costs (16 Mar 2026) · Anthropic: Set Spend Limit API reference