Blast Radius, Explained From Zero

Imagine two very different fires. One starts in a wastebasket and is out before anyone else in the building even smells smoke. The other starts in the same spot but, because every door between every room was left wide open, ends up taking the whole building. The fire itself was the same size. What differed was everything that was reachable from where it started. Security people borrowed a word for exactly that idea from an entirely different field, explosives, and it has become one of the most useful, and most misunderstood, terms in the whole subject: blast radius. This article builds the idea up from nothing, then spends real time on two places where it behaves very differently than most people expect: AI agents, and quantum computing.

1 · The everyday word behind the term

Set computers aside completely for a moment. A blast radius, in its original, literal sense, is simply the distance outward from an explosion within which damage actually happens. A small firework has a blast radius of a few feet. A large explosive has a blast radius that can cover city blocks. Nothing about the word is complicated: it is just a measurement of “how far the damage reaches,” drawn as a circle around the point where something went wrong.

Two explosions can release very different amounts of energy and therefore have very different blast radii, but the word itself never changes meaning. It always means the same thing: the region, measured outward from the center, where whatever went wrong actually did damage. Everything inside that circle was affected. Everything outside it was not.

2 · Translating “blast radius” into computer systems

Computer security borrows this word directly, and keeps its meaning almost unchanged. In this field, a blast radius is everything that could plausibly be affected if one particular thing — a password, a laptop, a piece of software, a single AI agent — turns out to be compromised. “Compromised” simply means someone who should not have control of it now does, or it started behaving in an unintended way.

Unlike a physical explosion, a computer’s blast radius is not measured in feet. It is measured along three separate reach paths, and something usually only has a large blast radius because more than one of these paths is wide open at once.

• Identity reach. Every other system that trusts the same login, the same credential, or the same account is inside the radius, because whoever now controls that login can simply act as it everywhere it is trusted.
• Network reach. Every other computer or service that the compromised thing can actually send traffic to is inside the radius, because an attacker sitting on a compromised machine can use it as a stepping stone to reach anything it can already talk to.
• Data reach, via lineage. Every report, table, or downstream system built — directly or through several indirect steps — from data that thing touched is inside the radius. An indirect connection still counts: if system A feeds system B, and B later feeds system C, then A has still shaped what ends up in C, even though no direct link runs between A and C, the same way a rumor still traces back to the first person who told it even after passing through several other people.

3 · A worked example: one shared password, traced outward

Picture an ordinary engineer who, for convenience, reuses the exact same password across their email, a cloud administration console, and a file server, and whose cloud account also happens to have standing access to a backup host. One phishing email later, an attacker has that password. Nothing else about the company changed, yet the blast radius of that single event now includes every one of those systems, plus anything built from data those systems hold, plus anything reachable over the network from the backup host. The password was one small thing. The radius was not small at all.

This is precisely why security guidance treats password reuse, standing administrative access, and unnecessary network reachability as separate risks worth fixing independently — each one is a lever that, on its own, can make an otherwise ordinary compromise reach much further than it needed to.

4 · Why an AI agent can have a far larger blast radius than a person

A careless human employee still has a fundamentally human-sized blast radius: one person, generally doing one task at a time, at human speed, usually noticed reasonably quickly if their behavior changes. An AI agent — software that can decide, on its own, which tools to call and which actions to take in order to complete a task — does not have to work that way at all, and that difference is exactly why agent security deserves its own careful look.

Four specific, well-documented design mistakes are responsible for most of the difference, and each one has already been given a proper name elsewhere in this guide’s anti-patterns catalogue, because each one independently widens an agent’s blast radius:

• Wildcard tool exposure. Handing an agent access to every available tool “just in case,” instead of only the small set a given task actually needs. This is the software equivalent of giving someone a master key to every door in the building because unlocking one specific room seemed inconvenient to arrange.
• The standing credential. Issuing an agent one long-lived credential that never expires, instead of a fresh, narrow, short-lived one per task. A standing credential is a key that still works long after the job it was cut for is finished.
• The shared identity runtime. Running many unrelated agents, or many unrelated tasks, under one shared identity so that no audit log can tell them apart. If every worker in a building shares one keycard, a security camera cannot say which one of them walked through a given door.
• Implicit agent-to-agent trust. Wiring one agent to automatically believe and act on whatever another agent tells it, with no independent verification. A rumor that a second agent repeats unquestioningly to a third spreads exactly like the unverified rumor chain from the lineage article, except now it can trigger real actions instead of just being retold.

None of these four mistakes is exotic or rare. Each is a completely ordinary shortcut, taken to make an agent easier to build quickly. The problem is what they do in combination: an agent carrying a standing credential with wildcard tool access, sharing its identity with several other agents, and automatically trusting messages from yet more agents, can end up with a blast radius that spans the whole company — triggered by nothing more dramatic than one bad prompt, one poisoned document, or one compromised upstream service.

5 · A named incident, told in miniature

Here is a short, realistic scenario that ties the four mistakes together. A support-automation agent is given wildcard access to “all internal tools” during a rushed rollout, carries one standing credential that was never rotated, and shares that same identity with two other automation agents built later by a different team. One day, a crafted support ticket contains hidden instructions aimed at the agent rather than at a human reader. Because the agent implicitly trusts content it processes as if it were a direct instruction, it follows them: it uses its wildcard access to export data from a system that has nothing to do with support tickets at all, using a credential that was never meant to still be active, under an identity that two other unrelated agents were also using that same day.

Every part of the resulting mess traces back to a decision made weeks earlier, not to anything unusually clever the attacker did. That is the pattern worth remembering: an AI agent’s blast radius is set by its permissions and its trust wiring long before any incident occurs, exactly the same way the earlier password example showed for a human account — just with far higher stakes, because agents move faster and touch more systems than a person ever could in the same amount of time.

6 · How quantum computing quietly expands blast radius across time

Every example so far has had a blast radius that spreads outward through space — across systems, accounts, and tools. Quantum computing introduces something stranger: a blast radius that spreads outward through time.

Here is the mechanism, known as harvest-now-decrypt-later. Most of today’s encryption, the process that scrambles data so it is unreadable without the right key, relies on math problems that ordinary computers cannot solve in a practical amount of time. A sufficiently capable quantum computer — a fundamentally different kind of computer that works with the strange rules of quantum physics instead of ordinary on/off switches — is expected to eventually solve some of those exact math problems quickly. An attacker does not need to wait for that computer to exist before acting: they can copy and quietly store encrypted traffic today, entirely unreadable right now, and simply wait for a capable quantum computer to arrive later.

The moment that happens, every year of previously harvested, stored traffic that used the now-broken method becomes readable all at once. The blast radius did not grow slowly, one system at a time, the way it does in the earlier examples. It stayed completely invisible for years and then, in a single moment, expanded to cover everything that was ever encrypted the old way and copied by an attacker along the way.

This is exactly why the guide’s post-quantum readiness field guide treats certain categories of data — anything with value that lasts for years, health records, trade secrets, long-lived credentials, government or defense communications — as needing protection today, well before a capable quantum computer exists, rather than waiting until it does. By the time the threat is obvious, the blast radius has already been decided, exactly the same lesson as the shared-password example earlier, just measured in years instead of systems.

7 · Shrinking blast radius on purpose

Every example in this article has one thing in common: the radius was never inevitable. It was the direct, foreseeable result of specific design choices, which means it can be reduced by specific, deliberate counter-choices.

• Least privilege. Grant only the access a task genuinely needs, nothing “just in case.” This is the direct opposite of wildcard tool exposure.
• Short-lived, scoped credentials. Issue access that expires with the task instead of a standing credential that outlives its purpose.
• Segmentation, sometimes called cell-based architecture. Split systems into separate walled-off sections, so that a compromise in one section cannot automatically spread into the next — the digital equivalent of fire doors between rooms.
• Zero trust. Verify every request on its own merits, every time, instead of assuming anything is safe just because it came from inside the network or from another trusted-looking agent.
• Crypto-agility. Keep encryption methods swappable, so that when one is eventually broken, it can be replaced quickly across the whole company instead of leaving years of already-collected traffic permanently exposed.

8 · A simple test you can run this week

9 · Treating blast-radius reduction as a design principle

A blast-radius gap discovered during a review can be logged as a finding, something serious enough to be tracked and fixed on a schedule, or as a backlog item, an idea worth doing someday with no real pressure behind it. Backlog items about “maybe narrowing that agent’s permissions eventually” have a well-known habit of waiting forever, right up until the day they turn a routine bad prompt into a company-wide incident.

Treating blast radius as something to be designed down on purpose, at build time, rather than discovered by accident during an incident, is the difference between a security program that reacts and one that actually shrinks its own exposure over time.

10 · Glossary — every short-form term, spelled out

Blast radius

Everything that could plausibly be affected if one particular thing is compromised, borrowed from how far damage reaches outward from an explosion.

Compromised

Someone who should not have control of something now does, or it started behaving in an unintended way.

Identity reach

Every system that trusts the same login or credential as the thing that was compromised.

Network reach

Every system that the compromised thing can actually send traffic to.

Data reach (lineage)

Every report or downstream system built, directly or indirectly, from data the compromised thing touched.

AI agent

Software that can decide, on its own, which tools to call and which actions to take in order to complete a task, without a person approving each individual step.

Wildcard tool exposure

Granting an agent access to every available tool instead of only the ones a given task needs.

Standing credential

A long-lived credential that keeps working long after the task it was issued for is finished, instead of a short-lived one scoped to a single task.

Shared identity runtime

Many unrelated agents or tasks running under one shared identity, so audit logs cannot tell them apart.

Implicit agent-to-agent trust

One agent automatically believing and acting on whatever another agent tells it, with no independent verification.

Harvest-now-decrypt-later

An attack pattern where encrypted traffic is copied and stored today, unreadable at the time, then read all at once once a capable quantum computer can break the encryption method used.

Quantum computer

A fundamentally different kind of computer that works with the rules of quantum physics rather than ordinary on/off switches, expected to eventually solve certain math problems that today's encryption relies on being impractical to solve.

Least privilege

Granting only the access a task genuinely needs, nothing extra "just in case."

Segmentation (cell-based architecture)

Splitting systems into separate walled-off sections so a compromise in one cannot automatically spread into the next.

Zero trust

Verifying every request on its own merits every time, instead of assuming safety just because a request came from inside the network or from a trusted-looking source.

Crypto-agility

Keeping encryption methods swappable, so a broken one can be replaced quickly instead of leaving past records permanently exposed.

Finding versus backlog item

A finding is a problem serious enough that it must be tracked and fixed on a schedule. A backlog item is just an idea that can wait, and often does, forever.