Blast-Radius Gates: Limiting What a Single Agent Action Can Do

Most guardrail conversations start with correctness: how do we stop the agent from doing the wrong thing? That's the right question to ask, and it's also the wrong place to put all your effort, because you will never fully answer it. Language models are probabilistic; agents built on them will occasionally make a call that, in hindsight, was clearly bad, and no amount of prompt engineering or policy tuning drives that probability to zero. The teams that get burned worst aren't the ones whose agents were wrong — every production agent is eventually wrong about something. They're the ones whose agent, when wrong, could do unlimited damage before anyone noticed.

That reframes the design question entirely. Instead of "how do we make the agent always right," the more tractable question is: how much damage can a single wrong action do, and can we cap that number regardless of how the agent got there? That's a blast-radius gate — a hard limit on the scope, rate, or reversibility of what one action, or one run, is permitted to do, independent of whether the reasoning behind it was sound.

Why correctness-only guardrails aren't enough

A content filter or a policy check evaluates whether a specific action is allowed in principle. What it typically doesn't evaluate is scale: is this the agent's first refund today or its fiftieth, is this action reversible if it turns out to be wrong, does this single call touch one customer record or ten thousand. A rule that says "refunds are allowed" says nothing about whether one agent should be able to issue a hundred of them in an hour without anyone looking.

This is the gap that turns a single bad judgment call into an incident instead of a footnote. An agent that makes one mistake and stops is a Tuesday. An agent that makes the same category of mistake fourteen times in eleven minutes because nothing capped its rate is the scenario examined in the five-step incident-response playbook — and the difference between those two outcomes wasn't better reasoning. It was a gate that either existed or didn't.

Three dimensions worth gating explicitly

Rate. How many of a given action type can this agent take per minute, hour, or session, regardless of whether each one individually looks fine? Rate limits are unglamorous and extremely effective, because most runaway-agent incidents are runaway precisely because nothing throttled the repetition. A single bad refund is a data point. Fifty in a row is a pattern that a rate gate turns back into a single data point by simply refusing the fifty-first until a human looks at the first.

Scope. How much can one action touch? A tool that updates "a customer record" should be scoped to update one customer record per invocation, not accept a batch parameter that lets a single call fan out across ten thousand rows because that was technically convenient to implement. Scope creep in tool design is one of the most common ways blast radius quietly grows — nobody decided to let the agent touch the whole table, it just wasn't prevented, and the agent used what was available to it.

Reversibility. Can this action be undone, and how expensively? A gate doesn't have to block every irreversible action outright, but it should treat the reversible/irreversible line as the primary axis for deciding what needs human approval versus what can proceed autonomously. Sending a draft for review is reversible. Sending an email to a customer is not. Writing to a staging table is reversible. Writing to a production ledger is not. The gate's job is to route actions differently based on which side of that line they fall on, not to trust the agent's own assessment of how risky its action is.

What a gate looks like in practice

Concretely, a blast-radius gate sits at the tool-execution layer, not in the prompt. That distinction matters: a prompt instruction telling the agent "don't process more than five refunds per hour" is a suggestion the model might not reliably follow under adversarial input or a sufficiently confusing edge case. A gate enforced in the code that actually executes the tool call is a hard limit the model cannot reason its way around, because it's not the model's decision to make — it's infrastructure sitting between the model's intent and the outside world.

A well-built gate for something like refund processing might look like: no single action processes more than one refund; no more than three refunds per account per rolling 24 hours without explicit human sign-off; any refund above a fixed dollar threshold requires approval regardless of how many have already happened; and the aggregate dollar amount processed by the agent in any hour is capped, with the cap itself requiring a manual reset once hit rather than silently resuming after a cooldown. None of this requires the agent to be smarter. It requires the infrastructure around the agent to not trust it past a certain point, which is a completely different and much more reliable kind of safety than hoping the model reasons correctly every time.

Gates and guardrails aren't the same tool

It's easy to conflate blast-radius gates with guardrails generally, but they're solving different problems and it's worth keeping them conceptually separate even when they're implemented in the same policy layer. A guardrail typically asks "is this specific action allowed" — a correctness question. A blast-radius gate asks "regardless of whether this action is allowed, how much of it are we willing to permit before requiring a human" — a scale question. You can have a guardrail that correctly permits every individual refund and still get burned by the absence of a gate on how many correctly-permitted refunds can stack up before someone looks.

Mature teams — particularly ones operating in regulated industries — build both layers deliberately rather than treating one as a substitute for the other. The guardrail is judgment about individual actions. The gate is arithmetic about aggregate exposure. Judgment can be wrong in ways nobody anticipated. Arithmetic, enforced in code that the model doesn't control, cannot.

Sizing the gate to the actual cost of being wrong

The hardest part of designing a blast-radius gate isn't the mechanism, it's the number. Set the rate limit too tight and you throttle a genuinely well-functioning agent into uselessness, generating support tickets of a different kind — "why is this taking so long" instead of "why did this go wrong." Set it too loose and the gate exists in name only, a limit so high it never actually engages before real damage accumulates.

The right anchor for that number isn't "what feels reasonable" — it's the actual cost of the worst plausible outcome if this specific gate weren't there. What does it cost, in dollars, reputation, or regulatory exposure, if this action type goes wrong ten times before anyone notices? A hundred times? That number, run backwards, tells you where the gate should sit. It's the same logic behind why to kill an agent run rather than let it keep going — the gate is the automated, pre-committed version of that same judgment call, made in advance so nobody has to make it correctly under pressure at 2am.

Blast radius won't stop an agent from being wrong. Nothing will, reliably, forever. What it does is convert an unbounded failure into a bounded one — turning "we don't know how bad this got" into "we know exactly how bad this could possibly have gotten, and we capped it before it got there." That's a lower bar than perfect judgment, and it's the one that's actually achievable.

Part of the "Running Agents in Production" series on aiskill.market.