Autonomy Is a Ladder, Not a Switch: Govern by Blast Radius

Almost every agent conversation I sit in ends at the same binary. Either the team locks the agent down so hard that a human approves every step, which means the agent automates nothing, or they give it full trust and let it run, which means its worst mistake lands with no one watching. Both answers feel like reasonable safety. Both are governance failures, and the research firms are starting to put a number on how common they are. Gartner projects that by 2027, 40% of enterprises will demote or decommission autonomous AI agents after governance gaps surface only once a production incident happens.¹

The root cause is not a weak model or a missing feature. It is that most teams are asking the wrong question. They ask whether an agent should be autonomous. The real question is how autonomous it should be, and that is not one answer for the whole fleet. An agent that summarizes internal documents and an agent that issues refunds to customers sit at completely different trust boundaries, and treating them with the same rule fails in opposite directions. Autonomy is a ladder, and each agent belongs on a specific rung.

The ladder gives you a vocabulary you are missing

The first thing standing between you and sane agent governance is that the word agent means too much. It can describe a chatbot that suggests replies for a human to send, or a system that changes configuration and moves money on its own. You cannot assess risk, assign controls, or explain a deployment to a board if one label covers both extremes.² The Cloud Security Alliance makes the point by analogy to driverless cars: the automotive world converged on a shared autonomy scale, SAE J3016, so that saying a vehicle is Level 2 automation means the same thing to a regulator, an insurer, and an engineer. Agentic AI has no equivalent, so teams make autonomy decisions ad hoc and rarely enforce them technically.²

Gartner has proposed the cleanest version of that shared scale, and it is worth adopting as your own internal vocabulary because it separates what an agent may do from how much scope it is given.¹

At the lowest rung, an observe agent holds read-only access to defined data and can summarize, retrieve, or explain. Its risk is limited mostly to data exposure and whether its output is accurate, so controls stay light and targeted. One rung up, an advise agent drafts and recommends but keeps no write access; a human executes every action. That rung hides a subtle danger: when an advisory agent's output is trusted without enough scrutiny, a confident but wrong draft can anchor a decision, what researchers call automation bias. The governance for advise agents has to extend beyond access controls into output quality, because the agent now influences what a human decides to do.¹

The two upper rungs are where the real decisions live. An act-with-approval agent can write data, send messages, or change configuration, but only after explicit human approval of each action. That is the rung most consequential business agents should sit on. An act-autonomously agent executes inside defined guardrails, with humans reviewing exceptions, audit logs, and outcomes instead of individual decisions. This is the rung where agents run at a scale and speed that outpace human oversight, which is exactly why Gartner says it demands the most rigorous governance: continuous monitoring, enforced guardrails, rapid rollback, circuit breakers that halt the agent on a threshold violation, and clear ownership for its behavior.¹

Uniform governance fails in both directions

Once you can classify agents onto rungs, the temptation is to apply one governance policy to all of them and call it done. Gartner's warning is aimed straight at that instinct: applying the same controls to every agent, regardless of autonomy level and scope, is a common path to failure. The typical failure is confusing an agent's ability to act with the scope of access it is granted.¹

Two failure modes come out of it. Over-restriction hits the simple, low-risk agents first. When a read-only research or drafting agent has to clear the same heavyweight approval gate as one that touches money, delivery slows to a crawl and the controls add nothing but friction. Teams do not accept that friction. They route around the governed system and build their own shadow tools, which then run with no oversight at all, strictly worse than the agent they were escaping. Under-restriction is the opposite and scarier failure. An agent that can write to systems, send external messages, or change configuration is governed with the same light touch as a chatbot, so nothing sits between it and a consequential action. Its risk grows with its access, and the compliance, security, and operational exposure compounds quietly until an incident makes it visible.¹

The fix in both cases is the same: classify autonomy first, then make the controls proportional to the rung and its trust boundary. A research agent gets baseline access control, usage logging, and accuracy testing. An autonomous agent that sends messages gets a real approval workflow, an audit trail, security testing, and an incident response procedure. The depth of governance should track the depth of the risk the agent can reach, never a fleet-wide standard that happens to fit neither end.

Set the rung by the worst irreversible action

Classification needs a concrete method, and the method that holds up is to place an agent by the most damaging irreversible thing it could do. That sounds obvious and almost nobody does it, because they classify by what the agent is for rather than by what its tools make possible. An agent pitched as a support assistant sounds low risk until you notice it can also close an account, which is irreversible and wide. The ceiling an agent is allowed to reach should be set by its worst possible action, not by the ambition of its demo.³

Arthur's guidance on human-in-the-loop governance sharpens this into five factors to score for any agent you are placing: reversibility, blast radius, data sensitivity, how much the agent is deciding on its own, and the domain it operates in.³ Reversibility is the load-bearing one. Reading a record is reversible, so it needs no gate. Sending an external email, wiring funds, or deleting data is not, and irreversible actions are the strongest possible case for a human in front of them. Blast radius decides the size of the gate: an action that touches one internal record is different from one that changes thousands of customer accounts. Data sensitivity raises the bar for anything that touches personal, financial, or health information. Autonomy and confidence matter because a long chain of low-confidence autonomous steps can go wrong even when every individual step looks minor. And some domains, credit decisions, benefits, clinical steps, warrant approval regardless of how well the agent usually performs, because the cost of a wrong call is not measured in effort but in consequence.³

There is an important subtlety in how far down you take this. Gartner and the Cloud Security Alliance classify agents to a rung; Arthur makes the sharper point that the approval decision should really be scored per action, not just per agent.³ The two are compatible. The rung sets the ceiling for the whole agent, the level of trust you grant it at all. Inside that ceiling, individual actions still get their own treatment based on the five factors. The clean example is one support agent with three different oversight rules: it drafts replies with no approval at all, it requires a human before issuing a refund over a threshold, and it is blocked entirely from closing an account. One agent, one autonomy ceiling, three per-action rules.³ Get the boundary wrong in either direction and the whole thing stops working. Too much review means you have automated nothing and reviewers learn to click approve without reading, which is worse than no gate because it manufactures the appearance of oversight. Too little review means an agent takes a consequential action no one signed off on, and the blast radius of its worst action applies every single time it runs.³

Design the gates a higher rung actually demands

If you grant an agent a rung that can act, the gates you build determine whether the grant is safe. Four design choices separate a gate that means something from a checkbox. Approve-before-act should be reserved for the irreversible, high-impact actions that justify the latency; lower-risk actions can run and be reviewed after the fact, which keeps the agent fast while still creating an accountability record. Thresholds turn an all-or-nothing gate into a graduated one: refunds under a set amount run automatically, refunds above it require a human, so the agent handles the common case and escalates only the consequential one. For the highest-stakes actions, finance's maker-checker pattern applies: the agent proposes and a separate human or second control approves, a structure auditors recognize and trust. And gate depth should track the agent's own risk tier, so a critical agent gets approval on every consequential action while a low-tier one may need none.³

Escalation design is where most implementations fall apart, because an approval gate is only as good as what happens when it fires. Route approvals by risk and domain so the right person sees the right decision instead of everything landing in one queue. Handle timeouts with a safe default: if no approver responds within the window, the action denies by default rather than silently proceeding, because an approval that times out into execution is a gate that does not exist. And watch for approver fatigue. If a gate fires so often that reviewers stop reading, the threshold is wrong. A gate that cries wolf trains people to ignore it, and a gate everyone ignores is how a false sense of safety takes hold.³ Gartner warns this exact failure on the act-with-approval rung: without strong security testing, clean approval workflows, and audit trails, approvals degrade under time pressure and approval fatigue, expanding the attack surface while feeling safe.¹

The whole apparatus only counts as governance if you can prove it ran. Every approval, denial, override, and timeout should be logged as an event with the context behind it: what the agent proposed, who decided, and why. That log is what turns oversight from a feature into auditable governance. When a regulator or an internal reviewer asks how a consequential action was authorized, the answer should be a record, not a recollection. It is also how you catch the quiet failures, gates that never fire because they were misconfigured, or overrides that have quietly become routine.³

Autonomy should be earned, and it should stay reversible

The rung an agent sits on is not a permanent grant. The strongest operating model treats autonomy like a promotion: you start an agent low, run it under an audit and eval regime, gather evidence that it behaves over real production runs, and only then advance it one rung at a time, with a named owner signing the change. Removing a human from the loop should be a decision backed by data about the agent's actual pass rate and incident history, not an assumption, and it should stay reversible if the agent's behavior changes. The moment an unexplained incident appears, the agent drops back a rung until you understand what happened.³

That discipline only works because of the infrastructure underneath it, and this is where production agent operations converges with the security fundamentals we have written about elsewhere. An agent that is allowed to act must run inside a least-privilege boundary so a mistake cannot become a disaster; Thoughtworks' Technology Radar calls sandboxed execution, zero trust, and defense in depth non-negotiable table stakes for agents, not best practice.⁴ Its output must be verified before it counts, because in production nobody is grading it in real time, which is why evaluations and structured-output checks moved from nice-to-have to prerequisite.⁴ Every step must be observable and traceable so a bad run is debuggable rather than a black box. And it needs an escape hatch, a hard step counter, a token or dollar budget that triggers an abort, and a circuit breaker that halts execution on a threshold violation.¹ When you have least privilege confining the agent, an audit log proving what it did, observability showing why, continuous evals catching regressions, and a circuit breaker stopping a runaway, you have earned the right to trust a higher rung. Without those, a higher rung is just a longer lever with nobody holding it.

Adroit on the Ground: what running a tiered agent fleet taught us

We run a delivery crew of specialist agents at Adroit that does real, scheduled work unattended, and it has forced us to answer the autonomy question one agent at a time rather than once for the fleet. The writing agents produce content all day, which is a real action in the world, but nothing reaches a public surface until an editor reviews and approves it. They sit at act-with-approval: they act freely, and publishing is gated behind a human. The agent that watches model pricing reads live rates and raises an alert, but it cannot change which provider routes our traffic on its own; that change sits behind a human decision, so it holds at the advise rung. Every agent is pinned to a least-privilege write boundary, and scheduled runs that drift outside their allowed configuration get blocked rather than executing wrong. None of it is a single autonomous-or-not setting. Each agent is classified by what it can actually touch, and the ones that can touch consequential things are the ones with a human in front of them.

The transferable lesson is not that we happen to run this way. It is that the classification is the load-bearing decision, and you can make it without waiting for any vendor. Take your own agent list, write down for each one the worst irreversible thing its tools could do, and set its rung from that answer. Start the ones with real reach at act-with-approval. Put the ones that can only read and recommend at advise. Give the autonomous rung only to the agents that are confined, observed, evaluated, and capped, and even then let them earn it. The organizations that get agent autonomy right are not the ones that trust models the most. They are the ones that match each agent's freedom to its blast radius and keep the match reversible.

A working path to classify your fleet this week

You do not need a governance platform to start, though the controls are easier to enforce when they live in the agent's execution path rather than as a prompt asking the agent to behave.³ The work is classification, and it fits in a day. List every agent you run or plan to run. For each, answer one question: what is the worst irreversible thing this agent could do with the access it has, and what would that require of a human if it happened? Score the five factors from above, reversibility, blast radius, data sensitivity, self-directedness, and domain, and write the rung each agent is allowed to reach. Then look for the mismatch that every audit of this kind turns up: agents whose access is wider than the rung you assigned, which is the gap that turns a careful classification into a false sense of safety. Close the access to match the rung before you trust the classification.

From there the pattern is mechanical and it composes with the reliability work we have covered separately. An agent that can act needs the durable state and idempotency that let a long run crash and resume without repeating a side effect, which we wrote about in durable execution, and it needs its own changes versioned, gated, canaried, and rolled back like any other service, which we covered in release engineering. An agent given an identity can finally be held to the access you grant it, the who-is-your-agent problem we covered in agent identity. None of that replaces the autonomy classification. It makes the classification safe to act on. Classify first, confine second, gate the irreversible actions, and let every agent earn the freedom it gets. The switch mindset is what gets fleets decommissioned. The ladder mindset is what lets them keep working.