Every AI agent incident has two phases. The first is whatever the agent did: deleted the wrong records, ran the wrong migration, sent the wrong emails. The second is figuring out how far it spread.
The second phase — the blast radius — is almost entirely determined by decisions you made before the agent was deployed. Who it ran as. What it had access to. Whether it operated on live data or a staging copy. Whether its outputs were validated before they propagated downstream.
This is the uncomfortable truth about AI agent risk management: by the time an agent starts executing unexpected commands, it's too late to contain the damage through configuration. The architecture either contained it or it didn't.
What Determines Blast Radius
Four factors determine how far an agent incident can spread:
1. The scope of the agent's credentials
An agent running as a service account with read-only access to one database can exfiltrate data from that database. An agent running with full AWS credentials and org-level IAM permissions can spin up resources, access all S3 buckets, enumerate secrets, and potentially affect every system in the account. The difference in blast radius between those two scenarios is measured in orders of magnitude — in blast radius, recovery time, and regulatory exposure.
Most agents run with broader credentials than they need, because scoping credentials correctly requires upfront work, and it's faster to grant the "admin" role than to figure out the precise permissions required for each task.
2. Whether the agent operates on mutable state
An agent that reads a production database and writes summaries to a report file has a bounded blast radius. An agent that reads production, computes transformations, and writes results back into production can corrupt state. An agent that reads production, calls downstream APIs, triggers billing events, and updates customer records can affect hundreds of systems simultaneously.
Blast radius scales with how many mutable systems the agent touches. Every read-write integration is a potential damage vector. Every external API call is an action that may not be reversible.
3. The reversibility of the agent's actions
Some actions are reversible: a database write can be rolled back if you have point-in-time recovery. Some are partially reversible: a file deletion can be recovered from backup if you noticed quickly. Some are irreversible: a sent email, a triggered webhook, a deleted S3 object with versioning disabled.
Irreversible actions at scale are particularly dangerous because they require compensating actions — sending correction emails, contacting affected customers, manually recreating data — rather than simple rollback.
4. How quickly the incident is detected
An agent executing a bad command that's detected immediately has a smaller blast radius than the same agent executing the same command that's not detected for six hours. Detection speed determines how many subsequent actions the agent takes before it's stopped, and how far downstream effects have propagated.
This is why command authorization matters not just as a pre-execution gate, but as a real-time visibility mechanism. Every command that passes through a human review layer is a detection opportunity — even for commands that are approved, unexpected patterns surface in the review queue.
The Architecture Review You're Not Doing
Most teams deploying AI agents review the agent's prompt design, test its behavior against sample inputs, and monitor its outputs. Very few teams ask the question: "If this agent malfunctions in the worst way we can imagine, what does the damage look like?"
That's the blast radius question. And it requires thinking through scenarios that feel unlikely:
- What if the agent receives a malicious prompt that redirects its behavior?
- What if the model produces an unexpectedly destructive command sequence?
- What if a dependency the agent calls returns bad data that causes cascading errors?
- What if the agent enters a loop and executes the same action thousands of times?
- What if someone gains access to the agent's API keys?
For each scenario, you should be able to answer: what systems are affected? How quickly would we know? What's the recovery path?
If the answers are "everything," "eventually," and "unclear," that's the architecture problem.
Architectural Controls That Actually Reduce Blast Radius
Isolation boundaries
Agents should operate within explicit isolation boundaries: a dedicated service account, a dedicated network segment, a dedicated database user with scoped permissions. Isolation doesn't prevent misfires — it ensures they don't propagate beyond a defined perimeter.
The implementation cost is real. Scoping permissions correctly, setting up dedicated accounts, and enforcing network boundaries takes time. The justification is that this cost is paid once, while the alternative — dealing with a production incident with a broad blast radius — has a variable and potentially very high cost.
Staged propagation
Where possible, agent outputs should propagate in stages, not all at once. Instead of an agent that writes directly to production and triggers downstream processes simultaneously, design flows where the agent writes to a staging area, a human (or automated check) validates the output, and propagation happens only after validation.
This is especially important for bulk operations. An agent that processes and updates 10,000 customer records should not update all 10,000 in a single transaction without a validation step. Staged propagation with checkpoints limits how many records can be affected before a problem is caught.
Write rate limits
Legitimate agent tasks have predictable throughput. An agent that normally processes 50 orders per hour shouldn't be able to trigger 50,000 actions in a loop. Write rate limits — at the application layer or at the infrastructure layer — cap the blast radius of runaway execution.
Rate limits are also a detection mechanism. Hitting a rate limit surfaces unexpected behavior that might otherwise go unnoticed until the damage is done.
Command authorization
For agents that execute shell commands or infrastructure operations, requiring human authorization before execution is the most direct blast-radius control available. Commands can't cause damage they haven't been allowed to execute.
This isn't practical for every command in every context — agents that need to run hundreds of read-only queries per minute can't pause for human review on each one. But for consequential operations — writes, deletes, network changes, external API calls — the authorization gate is the architectural equivalent of a circuit breaker.
Audit-first design
Every action the agent takes should be logged with enough detail to reconstruct exactly what happened and in what order. This doesn't reduce blast radius in the moment, but it dramatically reduces recovery time and post-incident analysis time — which in practice limits the total impact.
An agent that produces a clean audit trail allows you to reconstruct the incident, identify the exact set of affected records, and execute targeted remediation. An agent with no audit trail requires you to guess at impact scope, which usually results in conservative and expensive remediation.
The Trade-off That's Not Actually a Trade-off
Teams often frame blast-radius controls as trading off against agent speed or capability. "If we require human approval for destructive commands, the agent can't operate autonomously." This framing is wrong.
Blast-radius controls don't reduce capability — they scope where capability is applied. An agent that can do anything to any system isn't more capable than one with explicit boundaries; it's just more dangerous. The agent that requires human authorization on destructive commands and runs autonomously within its approved scope is faster overall, because it doesn't cause incidents that require multi-day recovery.
The teams that have learned this lesson, usually after an incident, uniformly report that the post-incident controls they implemented (scoped credentials, authorization gates, rate limits) didn't meaningfully reduce productivity. They just made the blast radius of future incidents smaller.
Designing for Failure
The mental model shift required here is treating agent failures as certain rather than possible. Every agent will eventually do something unexpected — because models are probabilistic, because inputs are unpredictable, because adversarial prompts exist, because dependencies fail in unexpected ways.
Designing for failure means asking, before deployment: when this agent does something unexpected (not if), how bad does it get? And then making architectural choices that bound the answer.
Blast-radius thinking isn't pessimistic — it's the same engineering mindset that produces distributed systems that tolerate node failures, databases with point-in-time recovery, and networks with circuit breakers. The infrastructure engineering community learned these lessons through painful incidents. AI agent engineering is going through the same learning curve, just faster.
Expacti provides command authorization for AI agents — a runtime approval gate that intercepts consequential commands before they execute. It's one of the blast-radius controls described in this post, and it works with your existing agents without architecture changes. Try the interactive demo or join the beta waitlist.