Blast Radius

The blast radius of a failure is the set of things that go bad when one thing goes bad; the word gives a team a way to talk about the scope of damage separately from the likelihood of damage.

What It Is

The blast radius of a particular failure is the set of resources, users, services, or data that are affected when that failure occurs. A bug in one service that corrupts only that service’s own data has a small blast radius. The same bug, when the service writes to a shared database that ten other services read from, has a much larger one. The word names a measurement — how far did it spread? — that’s distinct from the question of what caused it and from the question of how often it happens.

The measurement is always relative to a specific failure. A given system has many blast radii, not one: the blast radius of a leaked credential is different from the blast radius of a misconfigured deployment, which is different from the blast radius of a successful prompt injection against an agent. A useful security conversation enumerates the radii separately and asks, for each, whether the radius is acceptable given the failure’s plausibility.

It helps to keep two close-but-distinct ideas separate. Attack surface is about where you can be hit: the entry points an attacker can reach. Blast radius is about how far the damage spreads once a hit lands. Defenders shrink the attack surface to keep attackers out and shrink the blast radius to limit what attackers get once they’re in. The two answer different questions and call for different defenses, and a team that conflates them tends to over-invest in one and under-invest in the other.

A few neighboring terms travel with this one. Cell, in cloud-engineering vocabulary, names a unit of isolation chosen so that a failure inside the cell can’t escape it. Bulkhead, in Michael Nygard’s Release It! sense, names the partition between cells. Containment names the practice of keeping a failure inside its cell once it starts. Blast radius is the property that those constructs aim to bound.

Why It Matters

Without the word, security and reliability arguments collapse into a single dimension: “how likely is this to fail?” That’s the wrong question on its own, because it treats a 1% risk of a contained failure as equivalent to a 1% risk of a total-compromise failure. With the word, the conversation has two axes, and a team can make the trade-off explicitly: we accept this 1% risk because the radius is small; we refuse that 0.1% risk because the radius is the whole company.

The vocabulary also bounds the design conversation. When someone proposes “give the deployment script root on the cluster,” there’s a precise objection: that’s a small change in convenience and a large change in blast radius for any compromise of the script. When someone proposes “let the agent use a single scoped token instead of the developer’s full credentials,” the trade-off is the same shape, in reverse: a small loss in convenience for a large reduction in blast radius if the agent is tricked. These trade-offs exist whether or not the team has the word; with the word, they get argued explicitly rather than absorbed silently.

Under agentic coding, the discipline matters more, not less. An AI agent operating in a developer’s environment isn’t a single point of failure with a known radius; it’s a chain of decisions and tool invocations, each of which has its own radius, and the chain’s total radius can be much larger than any individual step. A delegation chain that hands a small permission from agent to subagent to tool can amplify it: each hop preserves the permission, and a single bad input at the top can drive ten consequential actions at the bottom. Teams that name the radius can decide which hops to gate, which to log, and which to refuse outright; teams that don’t tend to discover the chain after it has acted.

The discipline of naming radius also calibrates approval gates. The right approval threshold tracks how much damage an action can do, not how common the action is. A team that approves every database write because writes are common, and approves every shell command because commands are common, will eventually approve a destructive one out of habit. A team that gates by radius — this action could affect production data, escalate — preserves attention for the actions where it matters and avoids the approval-fatigue drift that makes the gate ineffective.

How to Recognize It

The radius of a particular failure is bounded by what the failure can reach. Several things shape it:

• Shared resources expand it. When N services share a database, a credential, a network, or a deployment pipeline, the radius of any single compromise grows to include all N. A shared production database with one connection string used by every service in the company has a radius the size of the company.
• Permissions cap it. Least privilege is the primary mechanism for bounding radius: a compromised component can affect only what its credentials allow. An API key scoped to one service caps the radius at that service; a developer’s full credentials cap it at the developer’s full access; a workload identity with no permissions caps it at nothing.
• Coupling propagates it. Tight coupling lets a failure in one component cascade into others that depend on it. A service that returns wrong data infects every service that reads it; a deployment script that breaks in one stage halts the whole pipeline. Loose coupling shrinks radius by ensuring each consumer can degrade independently.
• Trust boundaries wall it off. A trust boundary is the line where one component stops believing what another tells it. Boundaries that validate, authorize, and rate-limit before letting requests cross are the structural mechanism that prevents a small radius from becoming a large one.
• Sandboxes enforce it. A sandbox restricts what the code inside it can read, write, call, or reach. The radius of a compromise inside the sandbox is, by construction, the sandbox itself plus whatever the sandbox is configured to let out.

A team that takes radius seriously can usually answer these questions for the system they operate:

• What is the worst single thing a compromise here could do? Not “what would happen if every defense failed simultaneously,” which is unbounded — but “if this specific component were taken over right now, what’s reachable from it?” The answer is the radius of that compromise.
• Which actions in this system have the largest radius? Production database writes, deployment pipeline executions, credential mints, IAM policy edits, anything that crosses a region or an account boundary. These deserve heavier gating than radius-zero actions like reading a metric.
• Where does the radius widen unexpectedly? A read endpoint that touches a cache that’s also read by the billing system; a logging pipeline that ships logs to a service shared with other tenants; an agent’s web-fetch tool that loads pages containing prompt-injection payloads. Unexpected widening is the usual cause of incidents that surprise the team.

Signs the radius has gotten away from a team:

• A single credential, key, or role grants access to everything.
• An incident in one service takes down services that “weren’t supposed to be related.”
• An agent operating on one task is found to have touched files, repositories, or services entirely outside the task.
• The team can’t sketch the radius of a hypothetical compromise without going to look it up.

How It Plays Out

A company runs all its microservices against a single shared database using the same credentials. When one service is exploited through a SQL-injection bug, the attacker can read and modify data belonging to every service in the company. The radius of that one failure is the entire organization’s data. The team’s post-incident review notes that nothing about the architecture forced the shared credentials; each service could have run with its own database user with access only to its own tables. Adopting per-service users shrinks the radius for the next equivalent failure from “the whole company” to “one service’s data.”

A developer hands an AI agent full access to a personal development environment: every repository, every cloud credential, every SSH key. The agent processes a user-submitted file containing a prompt-injection payload that tricks it into running git push --force origin main on a production repository. The radius is every repository the agent could reach. The same incident, with the agent confined to a single repository through a scoped token, would have damaged one repository instead of the developer’s entire portfolio. Still bad, but survivable.

A platform team is asked to characterize blast radius for every action an in-house deployment agent can take. They list the actions, sketch the radius for each, and discover that “redeploy a service in staging” has the same effective radius as “redeploy a service in production” because both pipelines use the same upstream container registry credential. Splitting the credentials — staging gets a registry-read token, production gets one that requires multi-party approval — shrinks the radius of a staging compromise from “could push poisoned images into production” to “could break staging until rebuilt.” The fix takes an afternoon; the radius change is permanent.

Consequences

Naming radius separately from likelihood changes how a team designs and approves. The conversation becomes two-dimensional, and the trade-offs that used to be implicit become explicit. The cost is paid in structure: shrinking radius requires more isolation, more credentials to manage, more boundaries to maintain, and more deliberate architecture than the alternative.

Benefits. Failures stay incidents instead of becoming catastrophes. Recovery is faster because less is broken, and the broken parts are easier to find because the scope was bounded by construction. Deployments are less stressful because the worst case is a small radius, not a large one. Security-review conversations become specific: the radius of this change is this, and we can argue about whether that’s acceptable. Under agentic coding, the same discipline lets a team grant agents real capability without granting them unbounded reach: the agent’s permissions, sandbox, and gating each cap a piece of the radius, and the team can reason about the total.

Liabilities. Isolation has real costs. More credentials means more credential management. More boundaries means more cross-boundary calls, more latency budget spent on validation, and more configuration to keep consistent. A team that pushes radius reduction past the point where it pays for itself ends up with a system that’s hard to operate, where every cross-boundary call is a maintenance burden and engineers spend more time threading credentials than building features. The discipline is to shrink the radii that matter — the ones whose current size makes a plausible failure unacceptable — and to leave the rest at the convenient default. A radius that’s small in theory and ignored in practice is no smaller than a radius that’s large in theory and named honestly.

The other failure mode is treating radius as a static property. It isn’t: every new dependency, every new shared credential, every new agent tool can widen the radius of an existing failure mode without anyone noticing. The discipline is to revisit the radii on a regular cadence and after every architecturally significant change, and to treat a widening radius the same way a team treats a widening attack surface: as something to push back on or to budget for, not as background noise.

Related Patterns

Sources

• The “blast radius” metaphor migrated into computer security from military and weapons-effects vocabulary, where it describes the physical area damaged by an explosion. As networks grew more complex through the early 2000s and perimeter-defense thinking gave way to assume-breach and lateral-movement scenarios, practitioners borrowed the term to describe the post-failure scope of a compromise.
• Jerome Saltzer and Michael Schroeder articulated the underlying design principle in “The Protection of Information in Computer Systems” (Proceedings of the IEEE, vol. 63, no. 9, 1975). Their principle of least privilege (“every program and every user of the system should operate using the least set of privileges necessary to complete the job”) is the primary mechanism through which systems bound the radius of any single failure, and remains the canonical reference five decades later.
• Michael Nygard’s Release It! Design and Deploy Production-Ready Software (Pragmatic Bookshelf, 2007; 2nd ed. 2018) popularized the bulkhead pattern in software, named for the watertight compartments that keep a damaged ship from sinking. The book frames partitioning, redundancy, and resource isolation explicitly as ways to contain the radius of a failure to one part of the system.
• Amazon Web Services adopted “blast radius” as standard vocabulary for its availability-zone, region, and cell-based architectures, treating the term as a first-class design metric for cloud services. The Well-Architected Framework reliability pillar and re:Invent talks on cell-based architecture pushed the term into mainstream cloud-engineering usage in the 2010s.
• Charity Majors’ “I test in prod” (Increment, 2018) framed limited-blast-radius deployment as a deliberate practice rather than a fallback: “it’s better to practice risky things often and in small chunks, with a limited blast radius, than to avoid risky things altogether.” This reframing connected the term to feature flags, progressive rollouts, and canary deployments as everyday discipline.