An AI agent can pass every safety evaluation you throw at it and still wire money to the wrong account, delete a production table, or email a settlement offer to ten thousand customers. Not because the model is misaligned. Because the model was never the thing that mattered. The thing that mattered was the action — and almost nobody is measuring that.
Most teams deploying agentic AI assess it the way they assess a chatbot: how good are the answers, does it refuse the obviously bad prompts, how did it score on the eval suite. Those are questions about the model's behavior. They tell you nothing about the consequence of the agent picking up a tool and doing something in a real system. A model's answer is reversible — you can ignore it. A model's action may not be. That asymmetry is where enterprise AI risk actually lives, and it is invisible to the entire model-evaluation stack.
This article introduces a framework for making that risk visible before you deploy: the Blast Radius of an agent action, a way to size it, and a nine-question test you can run on any agent this week. It is not a product tour. It is a lens you can use regardless of what you build with.
You cannot govern what you have not sized. Model evaluations measure how an agent behaves. Blast radius measures what happens when it acts. The gap between those two is where the incidents come from.
Why the model is not the risk
The AI safety industry has built an impressive apparatus around the model: red-teaming, jailbreak testing, alignment evaluations, guardrail classifiers, and — increasingly — using one language model to grade another. All of it operates on the same surface: the tokens the model produces. And all of it shares the same blind spot. It stops at the output.
An agent does not stop at the output. An agent reads the output, selects a tool, and takes an action against the outside world — a database, a payments API, a customer inbox, a cloud console. The moment the token stream turns into a tool call, you have left the domain that evaluations cover and entered the domain of consequences. A refusal classifier that is 99% effective at blocking harmful text tells you nothing about whether the 1% that slips through can move a million dollars.
There is a classic name for the failure that results: the confused deputy. The agent legitimately holds authority — it is allowed to call the payments API, allowed to query the database, allowed to send mail. An attacker who cannot get that authority directly instead tricks the deputy into exercising it on their behalf, usually by planting instructions in content the agent will read: a retrieved document, a tool response, a web page, a support ticket. The model behaves exactly as designed. The action is catastrophic anyway. Security researcher Simon Willison has described the enabling conditions as a "lethal trifecta": access to private data, exposure to untrusted content, and a way to exfiltrate or act. When all three meet in one agent, prompt-level defenses are not enough.
This is not a fringe concern that better models will fix. It has a name in the field's canonical risk taxonomy. OWASP's Top 10 for LLM Applications lists Excessive Agency as a distinct risk category — the danger that arises when an LLM-based system is granted more functionality, permissions, or autonomy than the situation warrants. Excessive agency is not a model quality problem. It is a blast radius problem. And you cannot evaluate your way out of it, because the size of the blast radius is a property of the action, not the model.
The Blast Radius framework
Blast radius is the potential consequence of a single action, sized on two independent axes. Neither has anything to do with how well the model writes.
Reversibility asks: if this action fires and it is wrong, can the effect be undone — and by whom, in what time, at what cost? A read-only query is trivially reversible; there is nothing to undo. Updating a record is reversible with effort if you kept the prior value. A wire transfer that clears, a public post that is screenshotted, a deletion with no backup — these are practically irreversible. Reversibility is not binary; it is a clock and a cost.
Reach asks: how far does one action extend? How many records, customers, dollars, systems, or people can a single invocation touch? Drafting one internal note has reach of one. Updating one customer's address has narrow reach. Repricing a product line, messaging an entire list, or changing an access-control policy has reach measured in thousands or in blast-doors that stay open.
Plot every action an agent can take on those two axes and it falls into one of four zones. The zone, not the model's eval score, determines how much governance the action needs.
| Zone | Reversibility × Reach | Example agent actions | Required disposition |
|---|---|---|---|
| 1 · Contained | Reversible · narrow reach | Read-only queries, internal draft generation, summarizing a document the user already has | Auto-allow, log for audit |
| 2 · Recoverable | Reversible · broad reach, or irreversible · narrow reach | Update a single record, create an internal ticket, post to a private staging channel | Allow with evidence; keep the pre-action value |
| 3 · Consequential | Irreversible · moderate reach, or reversible · external reach | Send an outbound customer email, write to an external system of record, issue a refund below a threshold | Pre-execution gate bound to the specific action + signed evidence |
| 4 · Critical | Irreversible · external or broad reach | Move funds, execute a trade, delete production data, change access controls, publish public content, mass-message a list | Deny by default; require explicit authorization bound to the exact action, fail closed |
The framework's uncomfortable implication is that most agents in production today have never been mapped this way. Teams know what the agent is supposed to do. Very few have enumerated what it can do — the full set of tools, APIs, and side effects reachable from a single confused-deputy step — and sized each one. That un-enumerated set is the real attack surface.
A Zone 4 action does not become safe because the model that triggers it scored well on an eval. It becomes safe when it cannot execute without an authorization bound to that exact action — this recipient, this amount, this record — checked before it runs.
The Blast Radius Test: nine questions
Run these nine questions against any agent before it goes to production. They take an afternoon. The output is not a vibe; it is a count of your Zone 3 and Zone 4 actions that have no gate — which is a number you can take to a risk committee.
- Inventory. Have you enumerated every distinct action the agent can invoke — every tool, API, and side effect — not just the ones it is designed to use? The tools it can reach but "would never call" are exactly the ones an attacker will.
- Reversibility. For each action, can its effect be undone, by whom, and in what time window? Write down the clock and the cost, not just yes/no.
- Reach. What is the maximum number of records, customers, dollars, or systems a single invocation can touch? Size the worst case, not the typical case.
- Authority source. Where does the agent's permission to act come from — a signed, versioned policy, or text sitting in a prompt or context window it happened to read? If authority is a string in the context, it can be rewritten by anything that reaches the context.
- Injection path. Can untrusted content — retrieved documents, tool outputs, web pages, user input — reach the step where the agent selects an action? If yes, you have a confused-deputy path to every tool the agent holds.
- Pre-execution gate. For your Zone 3 and Zone 4 actions, is there a deterministic decision — ALLOW, BLOCK, or MODIFY — before the action runs, or only monitoring and alerts after? An alert after a wire clears is a notification, not a control.
- Binding. Is the authorization bound to the specific action (this $9,400 refund to this account) or to a broad capability ("the agent may issue refunds")? Broad capabilities are how a small compromise becomes a large one.
- Evidence. If an action causes harm, can you produce a tamper-evident record of exactly what was permitted, by which policy, and why — verifiable by a third party without trusting your own logs? "We have logs" is not the same as "we can prove it."
- Fail state. When the gate is unavailable, times out, or is uncertain, does the action default to blocked or does it proceed? A control that fails open is not a control; it is a formality that disappears under load.
Score it simply. Any Zone 3 or Zone 4 action that answers "no" to question 6 (no pre-execution gate) or question 9 (fails open) is unmitigated exposure. Count them. That count is the honest readiness number for the agent — and it is almost never zero the first time a team runs the test.
A concrete scenario: the refund agent
Consider a support agent deployed to resolve billing complaints. Its intended job is to read a ticket, check an account, and — where policy allows — issue a refund. It aced its evaluation suite: polite, accurate, refuses to promise things it shouldn't. It went live on a Tuesday.
Before. The agent has one tool that matters: issue_refund(account, amount). Reversibility: a cleared refund is practically irreversible. Reach: unbounded — the amount is whatever the agent passes. That is a Zone 4 action wearing a Zone 1 costume, because it "usually" refunds small sums. There is no pre-execution gate; there is a nightly reconciliation report. A support ticket arrives containing text crafted to read like an internal escalation note instructing the agent to issue a full annual refund to a specified account. The model, doing its job, complies. The report catches it sixteen hours later. The money is gone. Nobody can say which policy authorized it, because none did.
After. The same agent, same model, but issue_refund is recognized as Zone 4 and routed through a pre-execution gate. The proposed action — account, amount, reason — is evaluated against a versioned refund policy before it executes. Amounts above a threshold require an authorization bound to that exact refund; injected "escalation notes" are not a policy and carry no authority. The gate returns BLOCK, names the rule, and emits a signed record of the decision. The attack produces an audit artifact instead of a loss. The model did not need to be smarter. The action needed to be governed.
Governing the model asks whether the output is acceptable. Governing the action asks whether this specific effect, against this specific system, is permitted right now — and produces evidence of the answer. The first is necessary. Only the second sizes and stops blast radius.
What a blast-radius control actually requires
Sizing blast radius is the diagnosis. The treatment is a control that sits at the action boundary and has four properties the model-evaluation stack cannot provide. This is where the distinction between pre-execution governance and post-execution monitoring stops being academic.
For Zone 3 and Zone 4 actions, the control evaluates the proposed action and returns ALLOW, BLOCK, or MODIFY before any effect reaches the outside world. The blast radius of a blocked action is zero, because the action never executed.
Authority that lives as text in a prompt can be rewritten by anything that reaches the context — the confused-deputy path. Authority bound to the exact parameters of one action, checked deterministically, cannot be talked into a different action by injected content.
The verdict on a high-blast-radius action must be reproducible and testable, and its default under failure must be to deny. A control an auditor cannot re-perform, or that vanishes when a dependency times out, does not survive contact with a regulator.
When a Zone 4 action is blocked or permitted, the decision should emit a record — the action, the policy version, the verdict, the reason — that a third party can verify independently, months later, with no call back to the vendor.
This is the design point for EVE CoreGuard. It evaluates a proposed action with evaluate_hardened before execution and returns a deterministic ALLOW, BLOCK, or MODIFY verdict against a versioned policy pack — no model inference in the decision path, so the same action and policy produce the same verdict every time. It fails closed. And every evaluation emits a decision certificate — the action digest, policy identity and version, verdict, rule attribution, and a signature (Ed25519 in production, HMAC-SHA256 where asymmetric keys are not configured) — that any party can verify offline with the public key. The blast-radius framework tells you which actions need that treatment. The gate is what applies it.
None of this replaces model evaluation. Keep your evals, your red-teaming, your guardrails — they reduce how often the model produces a bad action in the first place. The blast-radius control is the layer underneath that assumes the bad action will eventually be produced anyway, by error or by an attacker, and makes sure the high-consequence ones cannot execute unauthorized. Defense in depth means governing the model and the action. Today, most deployments do only the first.
The takeaway
The next serious enterprise AI incident will not be a model that said something offensive. It will be an agent that did something irreversible, at scale, because it held authority no one had sized and no one had gated. The organizations that avoid it will be the ones that stopped asking only "is the model safe?" and started asking "what is the blast radius of every action this agent can take, and which of those can execute without a gate?"
Run the nine questions. Count your ungated Zone 3 and Zone 4 actions. That number is your real exposure — and it is the number worth sending to your team.
Frequently Asked Questions
The Blast Radius framework and the nine-question test are an original analytical model presented here for practitioner use; adapt the zone thresholds to your own risk tolerance. External references (OWASP Top 10 for LLM Applications; the "lethal trifecta" formulation) are cited to their sources and reflect those sources as of July 2026. EVE CoreGuard capabilities described here are verified from the EVE AI Core production system; other platforms' capabilities vary — verify current specifics with each vendor.