Blast Radius Thinking: A Framework for AI Risk

There’s a mental model I’ve used in incident response for decades. It’s not mine — it comes from network security, originally from how we think about firewall design and blast containment. But I’ve been applying it to AI agent architecture lately, and it’s become the clearest framework I have for answering a question I get constantly: how much access should this agent have?

The model is called blast radius thinking. And if you work in security, you already use it without calling it that.

What Blast Radius Means in Incident Response

In traditional security architecture, blast radius refers to the maximum potential damage if a given component is fully compromised. A privileged service account with access to every system in the environment has a massive blast radius. A read-only service account scoped to a single S3 bucket has a tiny one.

The principle drives least-privilege design. You don’t give a service account domain admin because it only needs to read from a database. You scope it tightly because the blast radius of a compromised credential is proportional to what that credential can reach.

This is foundational. It’s baked into NIST, into CIS controls, into every IAM framework I’ve worked with. It’s also exactly the framework most teams throw out the window when they start wiring up AI agents.

The Blast Radius of an AI Agent Is Different — and Bigger

When you give an agent access to a tool, you’re not just granting it the permissions in that tool’s API. You’re granting it the ability to act at machine speed, with autonomous decision-making, across whatever context it has access to.

That’s a force multiplier on blast radius.

Here’s what I mean. A human analyst with write access to your ticketing system, your GitHub repo, and your Slack workspace could cause significant damage if they went rogue — but they’d be slow about it. They’d have to think, click, type, navigate. You’d have time to notice.

An agent with those same permissions can act in milliseconds. It can create 200 tickets, push commits to 40 repos, and send 500 Slack messages before a human has loaded a dashboard. The blast radius isn’t just about what it can reach. It’s about how fast it can move through what it can reach.

I ran into this directly when I was scoping the first iteration of the ABT content agent. I’d given it access to GitHub (reasonable), the blog repo (necessary), and a Telegram integration (useful for status updates). What I hadn’t thought through was that those three tools, combined, let it publish content, push code, and notify users — all in one autonomous chain. No checkpoint. No human in the loop between “draft” and “live.”

That’s a non-trivial blast radius for a content tool.

Applying the Framework: Three Questions Before You Wire Any Agent

Blast radius thinking gives you a structured way to evaluate agent access before you grant it. I now run through three questions every time I’m scoping a new agent or extending an existing one.

1. What’s the worst-case outcome if this agent acts on bad input?

Not “what do I expect it to do” — what’s the ceiling on damage if it receives a malicious prompt, misinterprets a task, or hits a bug? An agent that only reads data has a much lower ceiling than one that can write, delete, or notify external systems.

2. Is the blast radius bounded by the tool’s scope or by the agent’s context?

This is the one teams miss most often. You can scope a tool tightly, but if the agent has broad context — access to customer data, internal docs, previous conversation history — a prompt injection or context manipulation can redirect its behavior even within a “scoped” tool. The blast radius includes what the agent knows, not just what it can do.

3. Where is the human checkpoint, and is it before or after the action?

Read operations: post-hoc review is usually fine. Write operations: you want a human in the loop before commit. Irreversible operations (delete, publish, send): require explicit human confirmation, full stop. If the answer to this question is “there isn’t a checkpoint,” that’s your answer — go add one before you move on.

Where I Applied This in Practice

After the content agent scoping incident, I restructured the pipeline around blast radius principles.

The agent lost its direct publish access. It now writes to a draft state only, flagged published: false. A separate /publish command — triggered by me manually — is the only path to live. That’s a human checkpoint before an irreversible action.

I also audited what context the agent had access to at inference time. It didn’t need access to the full repo history to write a blog post. It needed the CLAUDE.md guidelines and the recent post index. Tightening context scope reduced the surface area for prompt-based manipulation, even though the tool permissions hadn’t changed.

Blast radius dropped significantly — not by reducing capability, but by thinking clearly about what “compromised” actually meant in this context.

The Mental Model Applied to Enterprise AI Rollouts

If you’re managing AI adoption at an organizational level, blast radius thinking gives you a risk prioritization framework that maps cleanly to existing security vocabulary.

Start by categorizing every agent or AI integration by its action type:

Action Type	Example	Blast Radius Category
Read-only	RAG over internal docs	Low
Write to bounded scope	Create draft tickets	Medium
Write to production systems	Push to main branch	High
Irreversible external action	Send email, publish content	Critical
Multi-system chain	Read data → write ticket → notify Slack	Depends on chain

The last row is where most enterprise AI implementations land. And it’s where blast radius compounds. A chain of individually “medium” actions can produce a “critical” blast radius when they’re wired together autonomously without checkpoints.

Decompose the chain. Audit each link. Insert human gates before the irreversible steps.

Why Security Teams Underestimate This

Most security reviews of AI tools focus on data privacy (what does it access?) and compliance (does it log what it does?). Both are valid. Neither captures blast radius fully.

Blast radius is about the velocity and scope of autonomous action, not just access. A read-only agent can still have significant blast radius if it’s reading your customer database and feeding results into another agent that writes to an external API. The chain is the risk unit, not the individual tool.

Twenty-five years of IAM work taught me that access control reviews focus on credentials and permissions. AI introduces a new dimension: the agent’s reasoning process itself is part of the control plane. If the reasoning can be manipulated — through prompt injection, bad input, or context poisoning — the blast radius of that manipulation is whatever the agent is authorized to do.

That’s a different threat model than we’ve had before. Blast radius thinking doesn’t solve it completely. But it gives you a starting point that maps to how security teams already think.

Key Takeaways

• Blast radius thinking — borrowed from incident response — is the clearest framework I’ve found for scoping AI agent access.
• The blast radius of an AI agent includes both what it can do (tool permissions) and what it knows (context access). Both dimensions matter.
• Speed amplifies blast radius. An agent can cause damage faster than human review cycles. Design checkpoints around that reality.
• Ask three questions before granting any agent access: worst-case outcome, whether scope is tool-bounded or context-bounded, and where the human checkpoint sits.
• For enterprise AI rollouts, categorize agents by action type, then audit the full chain — not just individual tool permissions.
• Insert human gates before irreversible actions. That’s not a UX constraint. It’s blast radius containment.

The framework doesn’t require new tooling. It requires applying a familiar security mental model to an unfamiliar threat surface. That’s usually where I find the most leverage.