Agent blast radius

Agent blast radius is the full set of consequences an autonomous agent could cause if its model, tools, permissions, or context went wrong on a given run, the damage envelope that every containment control is sized against rather than the likelihood that anything goes wrong at all.

How it works

Blast radius is measured by reach, not by probability: what the agent can read, write, spend, trigger, and send, and how reversible each of those is, define the worst outcome a wrong action, or a permitted chain of them, could produce. It is set by the union of the agent's granted tools, its credential access, its network egress, and the consequence of each action it can take, so a read-only agent and one that can merge to production and move money sit at opposite ends of the same axis. The envelope is independent of the agent's judgment on any given run, which is the point: it holds whether the wrong action came from a reasoning error, a hallucination, or an instruction injected through content the agent merely read. Containment controls operate on this envelope from different angles: a sandbox shrinks what an action can reach, least privilege removes tools from the set, and an autonomy gate holds the high-consequence actions for a human, while threat modeling maps the envelope before any of them are placed. Reversibility is the second axis alongside reach, because an action that can be undone has a smaller effective radius than one that cannot, even when both touch the same system. Sizing the radius is what turns an open-ended safety worry into a bounded engineering decision: not whether this can be trusted, but what is the worst this can do, and whether that is acceptable.

Why it matters

It is easy to stall on the wrong question, whether the model can be trusted to behave, which no team can answer with confidence for a probabilistic system operating with autonomy. Blast radius replaces it with one the system's structure can answer, how much harm a failure can cause, and that reframing is what makes autonomy survivable: you stop trying to guarantee the agent never errs and start bounding what an error reaches. It also gives the reach-reducing controls a common axis, since a sandbox, a permission scope, and a gate can each be judged by how much of the envelope they remove, even though detection and review controls act on a different axis, shortening how long a failure runs rather than what it can reach. Two agents behind the same sandbox can still carry very different blast radii, one bounded to reversible local files and the other able to move money or leak regulated data, which is the distinction the dimension exists to surface. The honest limit is that blast radius bounds consequence, not correctness: an agent kept inside a small radius can still do the wrong permitted thing, so a tight radius raises the floor on harm while verification raises the ceiling on quality. The quiet failure is a radius that looks bounded but is not, an over-broad tool grant or an open egress path that widens the envelope while the configuration still reads safe, which is why the radius is something to probe by what the agent cannot do rather than trust by what the settings say.

In practice

A team about to give a coding agent a tool that can open pull requests asks what its blast radius becomes: the agent can now create branches, trigger continuous-integration runs, and surface code to reviewers, but it cannot merge, deploy, or reach production data, and the continuous integration it triggers runs without production secrets or a deploy path. That envelope is acceptable for unattended runs, so the tool is granted with merge and deploy left outside the set and a human gate kept on the merge. When the agent later proposes a change that should not ship, the worst case is a rejected pull request rather than a production incident, because the consequence was bounded before the first run rather than after the first mistake.

Practical considerations

The radius is worth enumerating per agent as a concrete list, the tools it holds, the data and credentials it can reach, the destinations it can send to, and the reversibility of each action, rather than reasoning about it in the abstract. Treat every new tool, connector, or permission as a radius change and re-evaluate, because the envelope the last review approved is stale the moment reach is added. The four reach dimensions widen independently, so a filesystem boundary means little if network egress is open, and a tight tool list means little if the credentials in scope unlock everything downstream. Reversibility is worth engineering in, since an action behind an undo, a draft, or a staged change has a smaller effective radius than the same action applied directly, though once data has left the boundary, rollback shrinks recovery cost more than reach. Verify the radius by attempting what should be impossible, not by reading the configuration, because the dangerous gaps are the ones that look closed. Where the radius cannot be made acceptable for autonomous operation, that is the signal to keep a human gate on the actions that carry it rather than to widen the lane.

Defined by Ready Solutions AI