How do you measure blast radius in practice?

Per action, not per agent, on two axes recorded separately. For each action the agent can take, write down whether it can be undone, by what mechanism, and how long that takes; then write down the maximum number of subjects one call can affect, taken from what the interface allows rather than from what you have seen. An agent's own radius is the worst of its actions, because the worst one is what happens on the bad day.

Is a wide blast radius always a problem?

No, and treating it as one is how a useful agent gets throttled into uselessness. A wide radius with a tested rollback and an enforced cap is an ordinary design. A narrow radius on an irreversible action, with nothing that stops a run, is the thing worth attention, and it looks harmless on any dashboard sorted by size.

Does a human approval step fix a wide blast radius?

It bounds it only for the actions the approval actually covers, and the list of covered actions is usually assembled from what sounded significant rather than from what cannot be undone. That ordering is the recurring defect: approval ends up on the alarming actions and off the quiet ones, and the quiet ones are where an agent spends its time.

What is blast radius for an AI agent?

Blast radius is the size of what happens when an AI agent takes an action it should not have taken. It has two parts that are usually confused: how much the action touches, measured in records, messages or money, and whether the action can be undone, measured against how long it takes to notice. The second matters more than the first. A narrow action nobody can reverse outranks a wide one you can put back in an afternoon.

Reversibility decides, not size

The instinct is to sort agent actions by how much they touch, because that is the number you can put on a slide. It produces the wrong ordering. Updating four thousand records you can restore from a snapshot is an afternoon. Sending one email to one customer is permanent, and no amount of narrowness changes that.

So the first question about any action is not how many, it is whether there is a mechanism that puts it back, and the honest answers are narrower than people expect. A true undo restores the prior state. A compensating action creates a second effect that offsets the first, which is a different thing: a refund is not an unbilling, and the customer saw both.

The second question is who owns the mechanism. Inside your own systems a rollback is something you can decide to do. Outside them it is a request to somebody else, which is why an agent that acts on the outside world has a smaller set of truly reversible actions than its owner usually believes.

An undo that misses its window is not an undo

Reversibility has a clock on it. If an action can be undone in five minutes and nobody looks at the queue until the next morning, it is not reversible in any sense that helps. What matters is the sum of how long it takes to notice and how long the undo takes, measured against the window in which undoing still changes the outcome.

The window is set by what happens downstream, not by the system that took the action. A record you can restore in seconds is not recoverable once a report has been sent from it, because the decision the report informed has already been made. A message you can delete from an inbox was read.

This is why an honest classification has a third category. Reversible, compensable, and irreversible are not a spectrum of how hard the undo is. They are three different answers to what you are able to offer the person on the other end.

A typical count is not a bound

The most common measurement error is recording what an action usually touches. A ticket-triage agent normally updates one ticket, so the radius gets written down as one. Then a query returns everything and the same code path updates nine thousand.

A bound is a limit something enforces, not a number somebody observed. Until a cap exists in code between the agent and the effect, the honest entry for blast radius is however much the underlying interface will accept in one call, which is usually a much larger number than anyone has written down.

Caps are also the cheapest control on this whole subject to add. They need no model, no approval workflow and no incident process. They convert the most ordinary agent failure there is, the loop, from an incident into a log line.

Common questions

How do you measure blast radius in practice?: Per action, not per agent, on two axes recorded separately. For each action the agent can take, write down whether it can be undone, by what mechanism, and how long that takes; then write down the maximum number of subjects one call can affect, taken from what the interface allows rather than from what you have seen. An agent's own radius is the worst of its actions, because the worst one is what happens on the bad day.
Is a wide blast radius always a problem?: No, and treating it as one is how a useful agent gets throttled into uselessness. A wide radius with a tested rollback and an enforced cap is an ordinary design. A narrow radius on an irreversible action, with nothing that stops a run, is the thing worth attention, and it looks harmless on any dashboard sorted by size.
Does a human approval step fix a wide blast radius?: It bounds it only for the actions the approval actually covers, and the list of covered actions is usually assembled from what sounded significant rather than from what cannot be undone. That ordering is the recurring defect: approval ends up on the alarming actions and off the quiet ones, and the quiet ones are where an agent spends its time.

Find out where you stand

The assessment on this site asks up to 24 questions about what your agent can reach and what happens when it is wrong, and returns a score, a verdict and, where a control is short, the one thing to fix first. It takes about ten minutes, and questions your agent has no surface for are dropped rather than scored against you.

It is a self-assessment of design, permissions and recovery, not a penetration test, not an audit of a running system, and not a certification.

Run the assessment