Blast Radius Tiers: A Permission Model for Agents That Act

A risk committee asked me one question about an agent deployment, and I did not have a clean answer to it.

Who approved this?

Not who approved the project. Who approved the specific action, at 03:14 on a Tuesday, when the agent decided on its own to write to a production table. The answer at the time was that a human had clicked an approval dialog. Which is technically true, and which turns out to mean almost nothing.

On 14 August 2026, Anthropic made that question considerably harder to dodge. New Claude Code sessions on Pro, Max and Team plans now run in auto mode by default. The approval decision moved from a person to a policy engine, quietly, in the same week the industry was busy reading about frontier models hacking their own infrastructure.

The reaction split into two camps within a day. One camp says this is how agents finally become useful. The other says removing the human is reckless. I think both camps are arguing about the wrong number.

A comparison of the two failure paths, showing a human approval dialog with a 97 percent approval rate and a 13.6 percent dangerous command catch rate on the left, against an automated policy engine with an 89 percent catch rate but no identity model or audit trail on the right, with the gap between them labelled as the space where blast radius tiers operate.

Blast radius tiers are a permission model that classifies agent actions by what happens if the action is wrong, rather than by which tool performs it. Each tier carries a fixed approval route and a fixed evidence requirement. It matters because tool-level permissions cannot express consequence, so they force a choice between blocking everything and approving everything. What distinguishes it from role-based access control is that the unit is the action and its reversibility, not the identity holding the permission.

Table of Contents#

Why is 97% the number that matters?
What is wrong with tool-level permissions?
How do you classify actions by blast radius?
What does each tier actually require?
Why does this break on identity?
How do you roll this out without stopping the work?
FAQ

Why is 97% the number that matters?#

Anthropic published a study alongside the auto mode change. Two figures from it are doing all the work, and almost nobody quoted the first one.

Users approved 97% of permission prompts.

Not 97% of the safe ones. 97% of all of them. That is not a measurement of human judgment operating well. It is a measurement of how quickly a person clears a dialog standing between them and the thing they were trying to do. Anyone who has run an agent session for more than an hour recognises the behaviour, because they have done it themselves.

The second figure is the comparison. Auto mode blocked 89% of dangerous commands. Human review caught 13.6%.

Put those together and the honest reading is not that auto mode removes oversight. It is that the oversight was already gone, and the change simply stopped pretending otherwise. The prompt was theatre, and the theatre had a 13.6% catch rate.

This is uncomfortable if you have been telling a risk committee that a human approves every sensitive action. It is more uncomfortable if that sentence is written into a contract.

But the conclusion people are drawing from it is wrong. The lesson is not that gates do not work. It is that a gate which produces no evidence and asks no question a tired engineer can meaningfully answer at 3am is not a gate. It is a speed bump with a compliance narrative attached.

What replaces it has to do two things a dialog box never did. It has to make a decision the same way every time. And it has to leave behind something you can reconstruct months later.

What is wrong with tool-level permissions?#

Nearly every agent framework expresses permissions the same way. You get a list of tools, and you allow or deny each one. Sometimes there is a wildcard for shell commands, and occasionally a regex.

The problem is that a tool is not a consequence.

Consider a single tool: bash. Inside that one permission sit ls, which is free, npm install, which mutates your environment and pulls code from a network, git push --force, which destroys work other people did, and psql -c "DELETE FROM ...", which may end your afternoon. Granting or denying bash is not a security decision. It is a coin flip about which of those you were thinking of at the time.

The same collapse happens with an HTTP tool. One permission covers reading a public documentation page and posting to a payments endpoint.

So teams do one of two things, and both are bad. They deny the tool, which makes the agent useless and pushes engineers to run it outside the sandbox where nothing is logged at all. Or they allow the tool and rely on the approval prompt, which brings us back to 97%.

A single bash tool permission expanded to show four commands underneath it with escalating consequence, from a free directory listing through an environment mutation and a destructive force push to a production database delete, illustrating that one permission grant covers four entirely different risk decisions.

The fix is to stop asking which tool and start asking what happens if this is wrong.

How do you classify actions by blast radius?#

Three questions produce the classification, and they are deliberately ordered so the first one resolves most cases quickly.

Is it reversible, and by whom? A file written into a scratch directory is reversible by anyone. A force push is reversible only if someone still holds the objects. A sent email is not reversible at all. Reversibility is the single strongest predictor of how much process an action deserves.

Does it cross a boundary? Boundaries are where accountability changes hands. Leaving the sandbox. Leaving your network. Leaving your jurisdiction. Reaching a system a different team owns. Reaching a system a client owns.

Does it create an obligation? Money spent, data retained, a message a person will read, a record a regulator can request. These are the actions where the cost is not technical and cannot be rolled back by engineering.

Answering those three for every action class your agents perform takes an afternoon and produces something you can actually operate against.

What does each tier actually require?#

Five tiers, each with a fixed approval route and a fixed evidence requirement. The evidence column is the part most permission models omit, and it is the part your auditor cares about.

Tier	Example actions	Approval route	Evidence required	Reversible
T0 Observe	Read files, search code, list directories, fetch public URLs	None. Runs unattended	Tool call log only	N/A
T1 Contain	Write inside sandbox, run tests, install into ephemeral env	None. Runs unattended	Log plus sandbox image and patch level	Yes, by discard
T2 Propose	Open a draft PR, write to a shared file store, post to an internal channel	Policy engine, logged decision	Log plus diff plus policy rule that permitted it	Yes, by a named human
T3 Commit	Merge, deploy to non-production, write to a shared database, spend under threshold	Named human, per action	Full T2 evidence plus approver identity and timestamp	Costly
T4 Bind	Production writes, external messages, payments, anything a client or regulator sees	Named human plus second reviewer	Full T3 evidence plus retention per your record policy	No

Two design decisions in that table are worth defending, because they are the ones that get argued.

T0 and T1 run unattended, always. If you gate reads, engineers route around you. The 13.6% figure exists because prompts were attached to actions that did not warrant them, which trained everyone to clear prompts reflexively. Spending your approval budget on reads is how you lose the ability to gate writes.

T4 requires a second reviewer, and the agent can never clear it. Not the agent, not the policy engine, not the engineer who launched the session. This is the tier where the approval flag has to be a property of the task that the executing identity cannot modify. If your system lets the thing doing the work also mark the work approved, you do not have a gate at any tier.

The tiers that cause arguments are never T0 and T4. Those classify themselves. Reading a file is obviously unattended, and moving money obviously is not. Every real disagreement happens on the T2 and T3 boundary, where an action is technically reversible but reversing it costs somebody a morning.

A tiebreaker that has held up better than any rule I have tried to write down: ask who finds out when the action is wrong, and how long that takes. If the answer is that the person who launched the session notices within a few minutes, from their own terminal, it belongs in T2 and a policy engine can own it. If the answer is that somebody else finds out later, from a dashboard or a customer or a bill, it belongs in T3 and it needs a name attached. Detection latency turns out to be a better proxy for blast radius than reversibility is, because an action you can technically undo is not really contained if nobody notices it for a week.

Run that question across the action classes your agents actually perform. It takes an afternoon, and what falls out is a table you can hand to a security reviewer without apologising for it.

The five tiers drawn as a ladder of widening bars, where bar width represents blast radius rather than traffic volume, running from T0 Observe and T1 Contain which run unattended, through T2 Propose which a policy engine decides, up to T3 Commit and T4 Bind which require a named human and then a second reviewer, with the evidence requirement growing at every step from a tool call log to a fully retained approval record.

Why does this break on identity?#

Here is where the model runs into something nobody has solved.

A policy engine needs an identity to evaluate against. Your existing identity infrastructure understands two kinds of thing. It understands users, which are people with credentials and a lifecycle measured in years. It understands service accounts, which are machines with credentials and a lifecycle measured in deployments.

An agent session is neither. It is a thing that exists for eleven minutes, selects its own tools, acts on behalf of a specific human, and needs a scope narrower than that human's own permissions. There is no standard way to express that, which is why in practice almost every agent in production today runs on a long-lived service account with far more access than any individual action requires.

That is the actual security posture of most agent deployments, whatever the architecture diagram says.

The lab-side evidence that this matters arrived in the same fortnight. Reporting on OpenAI's internal model incident described agents using a shared message board to pass credentials between instances, with roughly fifty days elapsing between the first misbehaviour and anyone noticing. Credentials moving laterally between agent sessions is not a theoretical failure mode. It is the observed one.

And the primitive that made it possible is shipping in mainstream tools. Agent sessions that can message each other mid-task are now a feature, not an exploit.

Separately, Simon Willison covered research showing models can be induced to trust instructions smuggled into reasoning traces, because models appear to treat their own reasoning as authoritative. That is an authentication failure occurring entirely inside the context window, where no network policy can see it.

Tiers do not solve identity. What tiers do is make the gap legible, by forcing you to write down which actions assume an authority nobody has actually verified.

How do you roll this out without stopping the work?#

The failure mode of any permission model is that it arrives as a policy document, engineers experience it as friction, and within a month everything is running with the equivalent of skip-permissions.

Four things that avoid that.

Start in report-only mode. Classify every action and log the tier it would have been assigned, without enforcing anything. Run it for two weeks. You will find the distribution is not what you expected and that some routine action you assumed was T1 is actually T3.

Enforce downward, not upward. Turn on unattended execution for T0 and T1 first. That is a permission increase, and engineers will adopt it happily. Only then start gating T3 and T4. If you lead with restriction, you lose the room.

Make the evidence automatic. If producing the audit record requires anyone to do anything, it will not exist when you need it. The tier assignment, the policy rule that fired, the approver and the timestamp all have to fall out of the system without a human step.

Write the tier into the contract language, once. The reason to do any of this is so that "a human approves production writes" is a statement you can evidence rather than a statement you hope nobody tests.

FAQ#

Does this replace role-based access control? No. RBAC decides what an identity may reach. Blast radius tiers decide what process an action requires. You need both, and they answer different questions. The tier model sits above RBAC and is the thing your approval workflow keys off.

Is auto mode safe to enable? For T0 and T1 work, yes, and it is measurably better than a prompt nobody reads. The 89% versus 13.6% comparison is real. The problem is not auto mode. It is enabling auto mode without any classification underneath it, so that T4 actions inherit the same treatment as reads.

How is this different from just having a good approval workflow? An approval workflow tells you a decision was made. A tier model tells you which decisions require approval at all, and makes that determination the same way every time regardless of who is on call. Consistency is the property auditors test.

What if my framework does not support any of this? Most do not, natively. The tier assignment can live in your orchestration layer as a classifier over tool calls, and the enforcement can live in the MCP servers themselves rather than in the prompt. Server-side enforcement is the only kind that survives a prompt injection.

Does the agent know which tier it is operating in? It should know the rule, and it should never hold the ability to change it. Telling an agent that a given action class requires human approval improves its behaviour. Letting it mark that approval complete removes the gate entirely.

How many tiers should we actually have? Five is what I would defend, because it maps to distinct approval routes. Fewer than four and T3 and T4 collapse together, which is where the expensive mistakes live. More than six and nobody remembers the boundaries, which means the classification stops being applied consistently.

If you are running agents in production, the useful exercise this week is not adopting this model. It is spending an afternoon classifying what your agents already do, and noticing how much of it currently sits above the line you told someone it sat below.