How it works
Blast radius is an estimate you compute per action, not a vibe. For a given tool call, you ask what the worst plausible outcome touches:
- Reach: which systems, records, or users a single action can modify.
- Reversibility: whether the effect can be undone, and how fast.
- Amplification: whether one call fans out — a broadcast, a batch write, a deploy.
- Blindness: how long the damage runs before anyone or anything notices.
You combine those into a rough cost of being wrong. A read against a scratch database has a near-zero radius. A DELETE with no WHERE clause against production, or an email to a live customer list, has a large one. The number does not need to be precise; it needs to rank actions so you can spend guards where they pay off.
The output is a policy decision. High-radius actions earn expensive controls — an approval gate, a dry-run, a human diff review, a staged rollout. Low-radius actions run free, because a guard there only buys latency and operator fatigue. The point is to match the cost of the guard to the cost of the mistake, not to guard everything equally.
Why it matters in an agent harness
An agent is a stochastic process wired to real tools. It will eventually emit a wrong action — a hallucinated argument, a misread instruction, a prompt-injection payload it obeyed. Blast radius is how you decide that this is survivable. You are not trying to make the model perfect; you are trying to bound what its worst call can do.
This reframes control from "is the agent smart enough?" to "what does one bad action reach?" That question is answerable at design time, and it drives the whole harness:
- Permissions: scope tokens so a confused or compromised agent can only touch a small radius.
- Reversibility: prefer actions you can roll back; a reversible mistake has a smaller effective radius than an irreversible one of the same reach.
- Containment: sandbox side effects so a bad write lands somewhere recoverable.
- Observability: shrink the blind window so damage is caught while it is still small.
Blast radius also tells you where autonomy is cheap. An agent editing a branch in a throwaway worktree can run wide open. The same agent holding production credentials needs a gate on every mutating call. Same model, different radius, different harness.
Blast radius vs least privilege
The two get conflated. Least privilege is a mechanism; blast radius is the measurement that tells you how much of it you need.
| Blast radius | Least privilege | |
|---|---|---|
| What it is | A measure of potential harm | A control that limits granted access |
| Question it answers | How bad if this goes wrong? | What is the minimum access to do the job? |
| When you use it | Deciding where to spend guards | Implementing the guard |
| Direction | Diagnostic — sizes the risk | Prescriptive — reduces the risk |
Least privilege is one of the strongest ways to shrink a radius, but it is not the only one. Reversibility, sandboxing, and rate limits all reduce blast radius without changing who can call what. Sizing the radius first stops you from over-restricting a harmless tool or under-guarding a dangerous one.
The Rifty take
We size the harness to the blast radius, not to the model's confidence. A capable model on a small radius earns more autonomy than a cautious model on a large one, because the harness — not the model's self-belief — is what holds when the output is wrong. We accept the latency of a hard gate on irreversible, wide-reach actions, and refuse to pay it anywhere else: a guard on a harmless call is just friction that trains operators to click through the one that mattered.
Common failure modes
- Uniform guarding: an approval prompt on every action. Operators habituate and rubber-stamp the one that counted.
- Ignoring amplification: treating a single "send" as low-radius when it fans out to thousands.
- Counting reach, forgetting reversibility: a wide but instantly reversible action can be safer than a narrow permanent one.
- Stale radius: a tool graded low-risk in staging keeps that grade after it is pointed at production.
- Blind windows: no detection between a bad action and its consequence, so a small mistake compounds before anyone sees it.
- Shared credentials: one over-scoped token silently widens the radius of every agent that holds it.
Frequently asked questions
How do I actually measure blast radius?
Estimate, don't calculate. For each action, score its reach (systems and records touched), reversibility, amplification, and how long harm runs unseen, then combine them into a rough rank rather than a precise number. The goal is to order actions so guards land on the dangerous ones.
Does a smaller blast radius mean I can give an agent more autonomy?
Yes. Autonomy should track radius, not model quality. When one bad action can only touch a recoverable, narrow scope — a scratch branch, a sandboxed write — you can let the agent run without gates. Widen the radius to production and irreversible effects, and you need approval on every mutation.
Isn't least privilege enough on its own?
No. Least privilege shrinks reach, but blast radius also depends on reversibility, amplification, and detection speed. An action can be minimally scoped and still catastrophic if it is irreversible and fans out. Size the radius first, then apply least privilege, sandboxing, and rollback as the tools that reduce it.
Where should I spend an expensive guard like human review?
On high-radius actions: irreversible, wide-reach, or amplifying calls such as production deletes, deploys, payments, or messages to real users. Keep low-radius actions — reads, sandboxed writes, throwaway branches — gate-free. Uniform guarding trains operators to click through, which defeats the guard exactly where it counts.