Industry Report Analysis

Mandiant's $50K Runaway Agent: How a Bug Becomes a Denial-of-Wallet Attack

Google Mandiant and the Google Threat Intelligence Group just documented a real accounting agent that burned $50,000 in cloud spend in under an hour — by accident. The uncomfortable part isn't the accident. It's that everything about the flaw that caused it is trivially reproducible on purpose.

$50K
Cloud spend from one runaway agent, in under an hour
15,000+
High-cost reasoning API calls in that window
1
Corrupted null value that started the whole loop

What Actually Happened

Google Mandiant and the Google Threat Intelligence Group (GTIG) published their 2026 AI Risk and Resilience report this week, and buried inside it is one of the cleanest real-world illustrations yet of why "autonomous" and "unsupervised" are not the same thing.

A global financial services provider deployed an agent to reconcile accounting ledger anomalies. To do its job, it needed — and was granted — direct read/write access to internal billing databases. Reasonable enough on paper. Then it hit a corrupted, null value that broke its own formatting tool.

Instead of failing, logging an error, and stopping, the agent tried to reason its way out. It entered what Mandiant describes as an unconstrained, recursive reasoning loop — repeatedly attempting to brute-force a fix. In under an hour, that loop generated more than 15,000 high-frequency, high-cost reasoning API calls, triggered a roughly $50,000 cloud-billing spike, and locked the local database badly enough to halt active business transactions.

Nobody caught this while it was happening. That's the actual headline. Not the dollar figure — the fact that an agent with real write access to a production billing system ran unattended at machine speed for the better part of an hour before anyone noticed.

Why This Stops Being "Just a Bug" the Moment an Attacker Notices

A self-inflicted execution loop is a resilience failure. The same execution loop, triggered on purpose, is a weapon — and Mandiant's report is explicit that this is exactly the direction attackers are moving. As agents get broader system access and the ability to execute at machine speed, a single poisoned data source, compromised model dependency, or malicious extension hook can turn a trusted, well-behaved agent into a channel for internal reconnaissance, lateral movement, or an outright break from its intended sandbox.

Nothing about the accounting agent's failure mode required an attacker. That's precisely what should worry security teams: if a bad null value can do this by accident, a crafted input can do it reliably, repeatedly, and on a schedule of the attacker's choosing.

Four Ways Attackers Will Weaponize the Same Flaw

This section is HexTyx's own analysis of the incentives Mandiant's findings create — not a direct quote from the report. Here's what a deliberately-triggered version of this failure looks like from an attacker's side:

1. Denial of Wallet (DoW)

Traditional denial-of-service floods a server with traffic until it falls over. Denial of wallet skips the outage entirely and goes straight for the budget: a crafted input — a logically unresolvable request, a malformed file that can never be parsed cleanly — gets fed to an agent with the specific goal of triggering exactly the kind of unbounded retry loop Mandiant documented. No breach, no data loss, just tens of thousands of dollars in compute and premium token spend by morning.

2. Smoke Screening and Log Flooding

A runaway agent doesn't just burn money — it generates an enormous volume of logs and error alerts in a very short window. Triggering that flood deliberately, timed to coincide with a separate, quieter intrusion elsewhere in the network, is a classic distraction play: the SOC's own monitoring tools get buried under noise from the agent incident precisely when they need to be watching something else.

3. Extension-Hook Data Siphoning

An agent stuck in a loop repeatedly re-queries its own backend systems looking for an answer. If an attacker has already poisoned one of those data sources — a connected spreadsheet, a support database, any external dependency the agent trusts — every iteration of the loop is another chance to read the poisoned instruction and act on it, exfiltrating a little more sensitive data each cycle, under cover of what looks like a routine internal error.

4. Rate-Limit Bypass via Trusted Internal Identity

Most perimeter defenses rate-limit by IP or session, aimed at throttling human attackers. An agent running inside the corporate cloud environment is, by design, already trusted — it isn't subject to the same session timeouts or per-IP throttling a human attacker would trip. Manipulating a legitimate internal agent into a loop is a way to query internal systems at a velocity no external attacker could ever achieve on their own credentials.

What Google Mandiant Recommends

The report's own defensive guidance is refreshingly concrete — this isn't "be more careful," it's specific control categories:

How HexTyx Aegis Shield Helps Close These Gaps

Aegis is HexTyx's runtime governance gateway — it sits in front of a live AI agent, not behind it, and evaluates every request across five checkpoints: input, RAG retrieval, tool calls, output, and a persistent audit trail. That positioning maps directly onto the failure modes in Mandiant's report, not as a coincidence — this is the exact problem class Aegis was built to sit in front of.

Where the line actually is

Aegis governs and can block what an agent is allowed to do at runtime — it's the control layer Mandiant's report describes as missing. It doesn't replace an organization's own IAM policy or cloud billing caps; it's the enforcement point that makes those policies actually bite at the moment a request happens, instead of showing up as a line item after the fact.

See how Aegis governs agents in real time

Five checkpoints, one audit trail, built for the exact failure mode Mandiant just documented in production.

Frequently Asked Questions

What happened in the Mandiant runaway AI agent incident?
An enterprise accounting agent at a financial services company, given read/write access to internal billing databases to reconcile ledger anomalies, hit a corrupted null value in its formatting tool. Instead of failing safely, it entered an unconstrained recursive reasoning loop, making over 15,000 high-cost API calls in under an hour, generating roughly $50,000 in cloud charges, and locking the database badly enough to halt active business transactions.
Is this a hypothetical risk or a real documented incident?
It's a real case study in Google Mandiant and the Google Threat Intelligence Group's 2026 AI Risk and Resilience report, drawn from Mandiant's actual field engagements — not a theoretical scenario.
What is a denial-of-wallet attack?
A denial-of-wallet (DoW) attack is the financial cousin of denial-of-service: instead of crashing a system with traffic, an attacker deliberately feeds an AI agent inputs designed to trigger unbounded compute or API usage, running up an enterprise's cloud bill rather than taking a service offline.
How could an execution loop be used to hide a separate attack?
A runaway agent generates a huge volume of logs and error alerts in a short window. If an attacker deliberately triggers this while carrying out a separate intrusion elsewhere on the network, the resulting alert flood can overwhelm a SOC's monitoring tools, making the real attack harder to spot.
What does Google Mandiant recommend as a defense?
The report recommends identity and access management with role-based access controls scoped specifically to agents, cost-cap thresholds, and stronger observability and monitoring — moving toward adaptive identity controls and real-time behavioral telemetry rather than static, one-time reviews.

Related Reading