What is Blast Radius?
Also called impact radius.
Blast radius is the scope of harm a failure, defect, or malicious action can reach before something stops it. It is described in terms of who and what is affected: how many users or tenants, which data, which downstream systems, and whether the effects can be reversed. Reducing it is a design goal independent of reducing failure likelihood.
Radius is bounded by structural choices rather than by care. Per-tenant isolation stops a bad write from crossing customer boundaries. Narrow credentials stop a compromised component from reaching systems it never needed. Staged rollouts stop a defective release from reaching everyone at once. Spending caps stop a runaway loop from consuming an entire budget. Each control converts a potentially unbounded failure into a bounded one.
AI agents expand the default radius because they act through tools rather than returning text. An agent holding broad write access to a customer record system, an email account, and a payment API can, in a single flawed run, produce effects across all three. Scoping each tool to the minimum permission it needs, and requiring approval for irreversible categories, is the primary containment mechanism.
Reversibility deserves separate consideration from reach. A failure that touches many records but is fully undoable is often less serious than one touching a few records irreversibly. Sending an external message, deleting data without a recoverable copy, and moving money are the classic irreversible categories, and they justify controls disproportionate to their frequency.
The concept is also used prospectively during change review. Asking what the worst plausible outcome of a change would be, and what would stop it, tends to surface missing limits more reliably than asking whether the change is correct. Answers phrased as structural bounds, such as a rate limit or a tenant scope, are stronger than answers that rely on the code behaving as intended.
Key points
- Describes how far harm can spread before something stops it
- Bounded by isolation, narrow credentials, staged rollout, and caps
- Agents widen the default radius because they act through tools
- Irreversible effects warrant controls beyond their frequency
- Useful as a prospective question during change review
In practice
An agent that reconciles invoices is given a database role that can read every table but write only to a staging table drained by a reviewed job. When a prompt change causes it to misclassify 900 invoices, the damage stops at the staging table. Correcting it means truncating staged rows and rerunning, with no customer-visible effect, because production records were never in reach.