When a software system fails, the blast radius is the set of things that can go wrong as a result. A well-designed system limits this: a payment service that fails takes down payment processing, not user authentication or data analytics. Blast radius is a property you design for — or you get surprised by later.
AI agents have unusually large blast radii by default. Understanding why, and how to shrink it, is one of the most important engineering decisions you'll make before shipping agents to production.
Traditional software has deterministic failure modes. When a microservice crashes, it stops doing things. It doesn't start doing new, unexpected things. The failure envelope is: "the service stops working."
AI agents fail differently. When an agent misbehaves, it often continues executing — just in ways you didn't intend. A hallucinated tool call, a misinterpreted objective, a successful prompt injection — these don't crash the agent, they redirect it. And a redirected agent with broad permissions and no kill-switch can cause significant damage before anyone notices.
The key factors that expand blast radius:
The right question to ask before shipping an agent is: If this agent behaves in the worst possible way for the longest possible time, what is the maximum damage?
Work through each tool the agent has access to:
For most teams doing this exercise for the first time, the answer is "no, that's not acceptable" — but they hadn't quantified it before.
The blast radius of an agent that can read one database table is much smaller than one that can read the whole database. Map each tool call to the minimum necessary access. The extra five minutes it takes to scope this properly is worth it.
This also applies to external APIs. If your agent calls Stripe to create charges, give it a key scoped to the specific endpoint it needs — not full API access.
An agent in a runaway loop will make thousands of calls. Rate limits at the execution environment level — not just at the API — cap the maximum action velocity. An agent limited to 10 email sends per hour cannot send 4,000 emails in 90 seconds, regardless of what it decides to do.
Set these limits conservatively. What's the maximum legitimate action count for a well-behaved execution of this agent? Set the limit at 3x that. Anything above 3x is almost certainly a problem.
Real blast radius includes API costs, compute costs, and external service costs. An agent that burns $5,000 in API calls before you notice has caused real damage even if no data was lost. Set a cost budget per execution and terminate when it's exceeded.
Similarly, set a wall clock limit. If this task should take 2 minutes, an agent running for 20 minutes is almost certainly stuck in a loop or misbehaving. Terminate and alert.
Some actions have irreversible consequences with large impact: deleting a record, sending a message to all customers, processing a refund. For these, break the autonomous loop and require explicit confirmation before execution.
This is a real usability trade-off. You chose to deploy an agent because you wanted automation. But "mostly automatic with a human checkpoint for the truly dangerous stuff" is a much better operating posture than "fully automatic and hoping for the best."
Deploy agents in read-only mode first. Validate that the agent's reasoning and tool selection are appropriate for the task before granting write access. Add write permissions incrementally, one tool at a time, with logging and monitoring at each step.
This is the equivalent of "staging before production" for agent permissions. Most teams skip it because they're excited to ship. Don't.
Software incidents exist on a severity spectrum, and most of them are recoverable. Servers restart, caches clear, queues drain. The recovery path for "agent did something bad for 90 seconds with broad permissions" is often much harder — because the agent actually did things in the real world.
The asymmetry means that the cost of designing for small blast radius is paid once (at deployment time), while the cost of not designing for it can be paid repeatedly and unpredictably in production.
Pre-flight checklist: Before deploying any agent to production, document your answers to: (1) Maximum permissions needed, (2) Maximum action rate, (3) Maximum runtime, (4) Most dangerous single action, (5) Recovery path if all three go wrong simultaneously. If you can't answer these, you're not ready to ship.
Agent Enclosure enforces the boundaries you define — permission manifests, rate limits, cost budgets, time limits — at the execution environment level, so the answers to your pre-flight checklist are actually enforced, not just hoped for.
Permission manifests, rate limits, and automatic kill-switches — enforced at the infrastructure layer.
Request early access