· via dev.to (home feed)
Runaway accounting agent burned $50,000 in API spend with no attacker, Mandiant says
Mandiant documented an AI accounting agent that fired 15,000+ API calls and racked up about $50,000 in cloud spend in under an hour. A dev.to walkthrough shows the guardrails that stop it.

What happened
According to a dev.to article published in September 2026, Mandiant's AI Risk and Resilience report — drawing on data from Google's Threat Intelligence Group — describes an accounting agent that got stuck repeating itself and issued more than 15,000 API calls, accumulating roughly $50,000 in cloud charges in less than an hour. No attacker was involved, and every call was properly authenticated.
The gap the article identifies is narrow but consequential: a token handed to an AI agent establishes who issued it, but says nothing about which budget pays for the agent's actions or how much of that budget remains. Without a separate enforcement mechanism, a valid credential functions as a blank check.
Why signature checks don't help
The author unpacks the mechanics. A JSON Web Token is a signed set of claims, and a server can verify that signature without calling the identity provider back. But verification only answers two questions: did the provider issue this token, and has it expired. Whether the caller has already exhausted its budget is a separate question, and it needs its own server-side check layered on top of verification.
Rebuilding the failure in a demo
To make the failure concrete, the article builds a demo in which several agents call the same route on Convex, a backend platform, presenting access tokens issued by Kinde, an identity provider that can attach custom data to machine-to-machine tokens. Two claims matter: an owner and a spend limit.
The setup has rough edges worth knowing. Kinde's custom properties come in text or boolean form only — there is no numeric type — so the dollar limit travels as a string the server must parse. Properties also have to be scoped to applications, switched out of private mode, and enabled under token customization, and each value arrives wrapped in a nested field the server has to unwrap.
With each call priced at $2.50, the results split cleanly. The agent whose token carried no owner and no limit made eight calls; all succeeded, spending $20 with no ceiling in sight. The agent with a $10 limit in its token had its first four calls accepted — exactly $10 — after which the server rejected every further call with an HTTP 402.
When the server trusts the caller
The most instructive part of the demo reproduces the original failure on purpose. A second enforcement route performed the same budget math but read the running total from a request parameter supplied by the caller, rather than from a ledger the server maintained itself.
Twenty calls hit that route using the metered agent's own token, each claiming $0 already spent. All twenty returned 200. The claimed total never moved from $0.00, while real spend — tracked in the background by the same ledger the honest route uses — reached $50 against a $10 limit, with a valid signature on every request.
The author also flags a testing trap from their own work: an early version of the proof script ran against a leftover ledger balance, which made the agent look capped from its very first call. Resetting the ledger before each run exposed that false positive.
Concurrency and fairness
Firing twenty simultaneous calls at the properly enforced route, with the same $10 limit and $2.50 price, produced exactly four accepted calls. The arithmetic holds under concurrent load because Convex queues mutations and runs them one at a time. But the accepted calls were processed in an arbitrary order, not arrival order, so a correct total is no guarantee of first-come-first-served fairness.
The demo's stated limitations: it ran on a single Convex deployment, did not test enforcement spread across multiple deployments or regions, and assumes an operator sets the text-typed limit correctly rather than feeding the parser a malformed value.
Why it matters
The Mandiant case shows that agent-driven overspend needs no adversary — a loop plus a valid credential is enough. As organizations hand autonomous agents their own machine credentials, spend control has to move into the authorization layer: per-owner attribution, budget claims bound to identity, and enforcement against a server-side ledger rather than numbers the caller reports about itself. The demo's figures are small, but the failure mode scales directly to the $50,000 Mandiant observed, and the fix is a pattern any team can copy before their own agent discovers the same loophole.
- #ai-agents
- #cloud-costs
- #api-security
- #finops
- #identity