A Runaway Agent Burned 50,000 Dollars in an Hour, and Nobody Attacked It

Mandiant published the AI Risk and Resilience report on 16 September 2026, drawing on its own incident response work and on observations from the Google Threat Intelligence Group. Most of the coverage has led with the threat actor material, which is understandable, because named adversaries make better headlines than operational hygiene. The finding that deserves your attention is quieter and considerably more likely to happen to you. An accounting agent entered a runaway execution loop and made more than 15,000 high cost API calls in less than an hour, running up roughly 50,000 dollars in charges and disrupting business transactions while it did so. There was no attacker. The agent held valid credentials, was doing the task it had been given, and failed in a way that no prompt injection defence would have caught.

It is worth being precise about what kind of event that is, because the classification determines who ever hears about it. This is an availability incident. A process with legitimate authorisation consumed a shared resource without limit until the services around it degraded, and the business impact was not the invoice but the disrupted transactions. In the language every security team already uses, that is a denial of service with an internal origin. Almost all of the agent security conversation for the past two years has been about confidentiality, because prompt injection and data exfiltration are the interesting failure modes to write about. Availability is where agents fail without any help from anyone, and it is the leg of the triad that AI programmes have scoped out of their control set almost universally.

The reason this class of failure stays invisible is that no existing control owns it. Rate limits are a platform engineering concern and are usually set to protect the provider rather than the customer. Budget alerts belong to finance and arrive against a monthly cycle. The security operations team is watching for indicators of compromise and an agent calling an API it is authorised to call generates none. So the detection path for an event that completed in under sixty minutes runs through a billing statement that may not be read for thirty days. Put any other process on your network beside it. If a service account made 15,000 outbound calls in an hour, that would page someone within minutes. The only difference here is that the process was an AI agent, and AI agents were onboarded into production without ever being handed to the teams that run capacity and monitoring.

The supply chain material in the same report reinforces a thread we have followed all month. In February, VirusTotal identified malicious OpenClaw skills carrying backdoors, droppers and infostealers, which is the registry level version of the declaration and behaviour gap we wrote about yesterday. In March, Mandiant responded to incidents attributed to UNC6780, also tracked as TeamPCP, involving stolen AI credentials and proprietary data. In May came the first publicly confirmed case of cybercriminals using an AI developed zero day exploit for mass exploitation. Set against that timeline, the red team findings are almost deflating in their ordinariness: prompt injection remains a primary attack vector in enterprise AI deployments, and it sits alongside improper file permissions and inadequate access controls. Two of those three findings are not AI problems at all. They are 2005 problems that arrived in a new deployment shape and went unreviewed because the thing being deployed was called an agent.

Among the recommendations, one sentence carries most of the operational weight: collect telemetry on agent token use, cross application API calls and network egress. That is a complete definition of the observable surface, and it is the part teams can act on this week without waiting for a framework or a vendor. Token use tells you when an agent is looping. Cross application API calls tell you what it is reaching and how often. Network egress tells you whether data is leaving, which is the control that actually constrains an exfiltration path regardless of what any instruction file claims. The report pairs that with maintaining inventories of models, applications and services, using automated software bills of materials to track components through to production, extending secure development practice into AI engineering, matching model capability to the task so routine work does not run on the most expensive model available, and building clearly identified adaptive identity controls. It also notes that open weight models create additional responsibilities because of limited visibility into what went into them, which is the same conclusion we reached when we argued that self hosting a frontier model makes you the provider.

The framework mapping is more interesting than usual because the obvious home is one most AI programmes deliberately left out of scope. SOC 2 has an availability criterion covering capacity planning and the monitoring of system components, and a runaway agent that disrupts business transactions is squarely inside it. The great majority of AI governance work over the past eighteen months has been scoped to the security criterion alone, which means the control that this incident calls for is one many organisations have chosen not to be assessed against. ISO 27001 carries it in two places that are already in nearly every statement of applicability: capacity management, and the logging and monitoring family that exists precisely to detect anomalous resource consumption. The gap is not that the control is missing from the standard. It is that nobody extended it to cover a non human identity that can invoke a paid API in a loop. ISO 42001 is the right home for the operating limit itself, because a management system for AI is supposed to define the boundaries a system runs inside and to review them when behaviour changes. PCI DSS enters the moment an agent with this failure mode sits anywhere near cardholder data, since an uncontrolled process making thousands of calls is a scoping conversation on its own. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof will all store the policy and collect evidence against it, and none of them reads your model provider token meters, so this is a control you build rather than one you buy.

The build is small and mostly consists of applying old practice to a new kind of process. Give every agent its own identity, because a meter that cannot attribute spend to a single agent cannot detect one agent misbehaving. Set a hard ceiling on calls and spend per agent identity, enforced at the credential or the gateway rather than stated in a prompt, since a limit an agent can read is a limit an agent can talk its way past. Alert on rate of change rather than on an absolute monthly total, because the incident that matters completes in under an hour and a threshold set against a monthly budget will never fire in time. Build a kill switch with a named owner and rehearse it, on the understanding that an untested kill switch is a diagram. And add runaway execution to your incident classification scheme with a severity attached, so that when it happens the event has somewhere to go other than a finance query six weeks later. None of this requires new technology. It requires deciding that an agent is a production workload.

The uncomfortable implication of the report is that the maturity gap is not about sophistication. An organisation that could detect this incident is one that treats agents like every other thing it runs: inventoried, given an identity, metered, bounded, monitored and owned. An organisation that cannot detect it has usually not made a single bad decision, it has simply never made a decision at all, because agents entered through product teams and enthusiasm rather than through a change process. Start by asking which agents are running in your environment right now, who owns each one, and what the maximum amount of money any of them could spend between two coffee breaks. If that last question has no answer, you have found the work. The ISO 27001 and ISO 42001 guides on this site cover the capacity, monitoring and lifecycle control families this belongs in, the compliance readiness assessment will show you which of them you can currently evidence, and the policy templates library has the acceptable use, change management and incident response clauses to hang it on.