Blast Radius

Context

This is a tactical pattern that connects security to system design. When something goes wrong (a bug, an exploit, a misconfiguration, a bad deployment) the blast radius is how far the damage spreads. A system with a small blast radius contains failures. A system with a large blast radius lets one problem cascade into a catastrophe.

In agentic coding, blast radius thinking applies to both the software you build and the agent’s own access. An agent with broad permissions has a large blast radius. An agent confined to a sandbox with narrow scope has a small one.

Problem

Failures are inevitable. Bugs ship to production. Credentials leak. Deployments break things. Attackers find vulnerabilities. You can’t prevent every failure, but you can control how far each failure reaches. How do you design systems so that a single point of failure doesn’t bring down everything?

Forces

• Tightly coupled systems are simpler to build initially but create large blast radii.
• Isolation reduces blast radius but adds complexity and operational overhead.
• Shared resources (databases, credentials, networks) create hidden connections that expand the blast radius beyond what the architecture diagram suggests.
• The desire for consistency and simplicity often works against isolation.

Solution

Design systems so that failures are contained rather than propagated. Several strategies reinforce each other here:

Isolate components. Use separate services, separate databases, separate credential sets. When one service is compromised, the attacker shouldn’t automatically have access to the data or capabilities of other services.

Scope permissions narrowly. Apply least privilege so that a compromised component can only affect what it has permission to touch. An API key scoped to one service limits the blast radius if that key leaks.

Deploy incrementally. Roll out changes to a small percentage of users first. If the change introduces a bug, only a fraction of users are affected. This applies to code deployments, configuration changes, and database migrations.

Use feature flags. Gate new functionality behind flags that can be turned off instantly. A broken feature can be disabled without rolling back the entire deployment.

Segment networks and data. Don’t put everything on one flat network. Use network segmentation so that a compromise in one zone doesn’t grant access to others.

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, the attacker can read and modify data belonging to every service in the company. The blast radius is the entire organization’s data. If each service had its own database (or at least its own database user with access only to its own tables), the same exploit would have affected only one service’s data.

A developer grants an AI agent full access to their development environment: all repositories, all cloud credentials, all SSH keys. The agent processes a user-submitted file containing a prompt injection that tricks it into running git push --force origin main on a production repository. The blast radius is every repository the agent can access. Limiting the agent to a single repository with a scoped token would have confined the blast radius to just that one repository. Still bad, but survivable.

Consequences

Small blast radii make systems resilient. Failures become incidents rather than catastrophes. Recovery is faster because less is broken. Investigation is easier because the scope is bounded. Teams can deploy with more confidence because the worst case is contained.

The cost is structural complexity. Isolation requires more infrastructure, more credential management, more network configuration, and more careful architecture. It is genuinely harder to build a system of isolated components than a monolith with shared everything. But the alternative, a system where any single failure can cascade to total compromise, isn’t a system you want to operate at scale.

Related Patterns

• Depends on: Least Privilege. Narrow permissions are the primary mechanism for limiting blast radius.
• Depends on: Sandbox. Sandboxes enforce blast radius boundaries.
• Uses: Trust Boundary. Blast radius is bounded by trust boundaries.
• Enables: Authorization. Well-designed authorization limits what any one actor can affect.
• Contrasts with: Attack Surface. Attack surface is about where you can be reached; blast radius is about how far damage spreads once something goes wrong.
• Enables: Prompt Injection. The goal is to make successful injection survivable.
• Enables: Threat Model. Understanding blast radius helps prioritize threats.
• Related: Shadow Agent – an unknown agent has unbounded blast radius.