# The Blast Radius Problem: How to Contain an AI Agent When It Goes Wrong
Here is an uncomfortable assumption worth making out loud: every AI agent you deploy will eventually do the wrong thing. Not because the model is bad, but because models are probabilistic and the world is messy. The mature question is not "how do we stop the agent from ever failing?" It is "when it fails, how much can it break?" That radius of potential damage has a name borrowed from systems engineering, the blast radius, and it is the single most useful lens for deploying governed AI agents in an enterprise.
The short answer: an AI agent's blast radius is the total damage one run can cause before something stops it. You shrink it with three platform controls: least-privilege execution to narrow what the agent can reach, policy-as-code to cap what each action can do, and sandboxed operators to isolate where it runs. An enterprise AI operating system enforces all three by default and logs every decision, so containment is provable rather than assumed.
Most teams discover their blast radius the hard way. An agent given a broad API token to "help with billing" issues 4,000 refunds in nine minutes. A workflow with write access to a shared drive renames every file because one instruction was ambiguous. The agent did exactly what it was permitted to do. The failure was not the model's reasoning. It was the size of the area the model was allowed to touch.
What does "blast radius" mean for AI agents?
Blast radius is the set of things a single execution can affect before anything or anyone stops it. It is a function of three variables. First, scope of access: how many systems, records and actions the agent can reach. Second, magnitude per action: whether one step moves a row or wires a payment. Third, time-to-detection: how long a runaway sequence runs before a human or a rule intervenes.
The reason this matters for an enterprise AI operating system, rather than for a single chatbot, is that agents compose. One agent calls a connector, which triggers an operator, which hands off to another skill. Permissions and side effects accumulate across the chain. If you only reason about the first step, you have measured a fraction of the real radius. Containment has to be designed at the platform layer, not bolted onto each individual agent.
Three controls that shrink the radius
Reducing blast radius is mostly the discipline of saying no by default. Three controls do most of the work.
Least-privilege execution narrows scope of access. Every skill runs with the minimum permissions its task requires, scoped to the specific records and operations involved, not the broad token that "covers everything just in case". A refund skill can read an order and issue one refund up to a defined amount; it cannot enumerate the customer table.
Policy-as-code narrows magnitude. Limits like "refunds over $500 require approval" or "no more than 50 records modified per run" are written as rules, versioned alongside the skill, and enforced at execution time rather than living in a runbook nobody reads. With policy-as-code, the boundary is a tested artefact, not a hope. Crossing it is a defined event with a defined response, usually a human-in-the-loop pause.
Sandboxed operators narrow the area itself. When an agent has to act on a system without a clean API, such as driving an application or manipulating files, it runs inside an isolated operator with a constrained view of the environment. A mistake stays inside the sandbox instead of spreading to everything the host machine can reach.
Containment is only credible if it is auditable
A boundary you cannot prove was enforced is not a control; it is a claim. This is where blast radius connects to auditable AI automation. Each step an agent takes should emit a structured record: what it tried to do, which policy evaluated the attempt, whether the action was allowed, blocked or escalated, and what changed as a result. When a run does hit a limit, the evidence shows the boundary holding: the attempted action, the rule that caught it, and the approval that did or did not follow.
That record is what turns "we think it is contained" into "here is the run where the agent requested a bulk delete, the policy blocked it, and a human declined". Durable execution reinforces this: because state is persisted, a workflow that pauses for approval or survives a restart resumes exactly where it stopped, and the audit trail stays continuous across the interruption rather than fragmenting into untraceable retries.
A practical takeaway
Before you deploy any agent, write down its blast radius in one sentence: the worst thing this can do in a single run, given its current permissions, is ___. If you cannot finish the sentence, the agent has too much access to deploy safely. If the answer frightens you, you have found your first policy to write. Run the exercise for the whole chain, not just the entry point, because the radius lives in the composition.
Designing for failure is not pessimism. It is the only way to grant AI agents enough autonomy to be useful while keeping the cost of any single mistake bounded.
Frequently asked questions
What is the blast radius of an AI agent?
How do you limit an AI agent's blast radius?
Why design AI agents for failure?
Take the next step
You do not control whether an agent fails. You control how much it can break. Agento bounds the blast radius by construction.