Agent Blast Radius: Two and a Half Years of Customer Data, Destroyed by a Single Approved Tool Call

The incident is the cleanest reference we have In late February 2026, the maintainer of a well-known data community published a post-mortem describing how an AI coding agent destroyed two and a half years of student submissions, homework, projects, and leaderboard data, together with the automated backup snapshots, in the course of a routine cloud migration. The maintainer is a professional engineer who understood every tool involved. The agent had even warned him, before starting, that the migration plan was structurally risky and recommended keeping the two cloud setups separate. He overrode the recommendation for cost savings. The mechanism was a stale infrastructure-as-code state file. The agent worked from an incomplete picture, created duplicate resources, and when the engineer subsequently uploaded the state file, the agent treated it as the source of truth and ran a to align the live infrastructure with the description. The state file described both projects' infrastructure. The destroy operation wiped a database that held two and a half years of irrecoverable user data, plus the automated backup snapshots. A day on the phone with the cloud provider's emergency support eventually surfaced a single surviving snapshot. The maintainer's own diagnosis was direct: he had over-relied on the agent to run the infrastructure command without reviewing the plan at the moment it mattered. The framing matters for any regulated mid-market buyer reading this. A professional engineer with full mental model of every tool involved hit this wall. The buyers we work with, operations teams, clinical informatics teams, billing teams adopting AI tools without the engineering depth to read the agent's output line by line, are in a structurally more exposed position. Treating this as a one-engineer cautionary tale is the wrong read. It is the cleanest reference we have for what blast radius means in an agent deployment, and the pattern that produced the loss is the pattern most regulated AI deployments do not yet have a control for. Blast radius, as a regulated buyer should think about it Blast radius is the question we run first on every Adopt-AI-Safely engagement that involves agents with tool access: how much of the production environment can a single change potentially affect? In a regulated environment the variants of the question are concrete. How many records can the agent read in one tool call? How many records can it modify in one tool call? Which side-effecting tools are reachable from the agent's tool surface, and how does it acquire approval to call them? What is the blast radius of the credential the agent holds? The agents we audit cluster into three blast-radius classes: Read-only agents. Tool surface limited to retrieval, summarization, transformation, drafting. Failure mode is a bad answer; the production environment is unaffected. Most documentation-summarization, ambient-scribe, and clinical-research-summary agents fall here. Mutating agents. Tool surface includes write operations against bounded record sets, a clinical-decision-support agent that updates a single patient's record, a billing agent that posts a single charge, a scheduling agent that creates a single appointment. Failure mode is a bad write. Recovery is bounded by the size of the change. Destructive agents. Tool surface includes operations whose blast radius is measured in records the agent did not name explicitly, bulk operations, schema changes, infrastructure operations, batch deletes. Failure mode is the destruction of state the agent did not retrieve to its own context before acting. The Terraform incident is the cleanest example, and the pattern transfers directly to any agent with database administrative privileges, EHR bulk-operation access, or messaging-platform broadcast capability. The class is the question. A read-only agent does not need an approval gate on every call. A destructive agent must not be able to call the destructive tool without one, and the gate cannot be a system-prompt instruction that the agent will respect on its own. What HIPAA already says about this The HIPAA control that maps directly is §164.308(a)(8), the evaluation requirement, often paired in audit playbooks with the change-management discipline implicit in the Security Management Process under §164.308(a)(1). The principle is that changes to systems that store, process, or transmit ePHI go through a documented change-control process. The auditor expects to see a change record, an approval, an executor, and a verification. The discipline exists precisely because experienced engineers running un-approved changes have produced data-loss events for as long as the rule has been on the books. An AI agent acting as the executor of a change is a new class of executor, but the rule does not change. The change record still has to exist. The approval still has to exist. The verification still has to exist. The structural failure in the Terraform incident, and in every agent-blast-radius failure we have audited, is that the change record was the agent's transcript, the approval was the agent's "I am about to run this," and the verification was an experienced engineer who, in the moment, did not stop to read the plan. For a regulated buyer the structural answer has three components, all of which sit at the orchestration layer rather than in the system prompt. One: classify the tool surface. Every tool the agent can call is classified at registration as read-only, mutating, or destructive. The classification is a property of the tool, not a behavior of the agent. The orchestration layer enforces the class. Two: gate destructive tools with mandatory approval. A destructive tool call cannot proceed without an explicit, structured approval step that names the change, the records affected (where bounded), the verifier, and the timestamp. The approval surface is a human-in-the-loop interface for low-frequency operations or a coordinator-agent pattern for high-frequency operations, but it is never the model's own decision. Three: produce the change record. Every approved destructive tool call writes a structured change record to the audit log: the change description, the approver, the executor (the agent identity, not the human user), the verification result, the rollback path. This is the artifact the audit asks for. The five-minute rule and what it actually generalizes to The post-mortem coined a useful operational rule: if the agent has been working for more than five minutes without showing what it's done, stop and check. For a hobby project or a small team, that rule is enough. For a regulated mid-market environment, the rule generalizes to the change-control discipline above. The agent that has been working for more than five minutes on a destructive workflow without an approval gate is an agent operating outside the change-control surface the auditor expects. The trust-architecture frame from the Trust Architecture for Regulated AI Field Guide gives the structural shape. Level two, scoped permissions and tool surface, is where blast-radius classification lives. Level four, the stop-and-ask escalation policy, is where the destructive-tool approval gate lives. The 12-piece Agent Infrastructure Field Guide names the specific primitives, the tool registry with a field, the permission system with trust tiers, the workflow state with idempotency keys, the verification harness, that turn the principle into enforced architecture. What we recommend A mid-market healthcare or financial-services buyer evaluating an AI agent with any tool surface beyond retrieval should run the blast-radius audit before the agent moves into production. First: classify every tool in the agent's surface as read-only, mutating, or destructive. The classification is the buyer's call, not the vendor's. A tool that the vendor labels "low risk" but that calls a bulk-operation API is a destructive tool. Second: require a written approval gate for every destructive tool call. The approval surface lives at the orchestration layer; it is not a system-prompt instruction. Third: produce the change record. Every destructive tool call writes a structured entry to the change-control log with a reproducible link back to the agent identity, the human user who initiated the workflow, and the verification outcome. Fourth: build the rollback. A destructive tool call without a documented rollback path is a tool call without a recovery posture. The Terraform incident's recovery happened because the cloud provider had an undocumented residual snapshot. That is not a recovery posture. It is luck. The pattern is simple, the discipline is familiar, and the audit linkage is direct. The buyers who internalize this before the next major agent deployment do not become the next published post-mortem. They become the case study a future auditor cites approvingly.