Autonomy levels and blast radius

The near-miss stories are starting to sound alike, across companies that have never spoken to each other.

An engineer gives a coding agent shell access to move faster on a cleanup task. The agent, pursuing a goal that looked reasonable at each individual step, runs a command against the wrong directory. Or force-pushes over a branch nobody backed up. Or seeds a local database with the word "test" and then, three steps later, points that same command at a connection string it found in an environment file.

Nobody meant to grant that. Somebody granted broad tool access once, for convenience, and never went back to it.

The model wasn't the problem in any of those. The scope was.

Autonomy is a dial, not a switch

Most teams treat "can this agent make changes" as a single yes or no, set once when the tool gets installed.

It's a dial. Several distinct positions, and different tasks belong at different ones.

At the low end it only suggests. Proposes a diff, a person applies it by hand.

One notch up, it applies the change itself but nothing runs until a person reviews it, and further up again it applies the change and runs the whole suite, so that a person's first look is at something already checked rather than at a raw guess. Further still, it commits to a branch or opens a pull request with nobody present for any of the intermediate steps. At the top it merges to a default branch, or triggers a deploy, on its own judgment that the work is finished.

Most of the value in the rest of this track lives in the middle of that range. Changes applied and tests run unattended, so a human's first look is at something already partly verified.

Most of the risk concentrates from "commits without review" upward, and very few teams should be running production agents at the top of that dial today. The ones that are should be able to say, in a sentence, exactly why that particular class of task has earned it.

The actual question: what can it touch

Model capability gets all the attention in vendor conversations. Wrong axis for a governance decision.

What determines your exposure is scope: what this agent can read, what it can write or execute, and how far a mistake is able to travel before any human sees it.

Read access to a codebase is close to free. Write access to a feature branch in a sandbox is low risk, because the undo is trivial. Delete the branch.

Write access to a shared branch, a shell with unrestricted execution, or credentials reaching production data is a different category entirely. The undo might not exist. A dropped table doesn't roll back because somebody apologises for it.

The practical move is ordinary security practice, applied to a new kind of actor.

Scoped credentials rather than broad ones. Execution inside a container or an isolated worktree rather than directly against a live checkout, and no path at all from the agent's tools into production systems without a human step somewhere in between.

It's the same discipline you'd already be applying to a new hire's laptop on day one, extended to something that works a great deal faster than a new hire and never gets tired enough to go back and double-check itself.

Match autonomy to reversibility, not to task difficulty

The intuitive mistake is granting autonomy by how hard a task looks. More freedom on hard problems, because that's where the help is wanted. Short leash for the easy stuff.

That gets the variable backwards.

The right axis is reversibility.

A genuinely hard refactor on a feature branch, with tests and a human gate before merge, can run with real autonomy. A bad attempt costs a discarded branch and an hour.

An easy-looking task with an unforgiving undo deserves a short leash regardless of how simple it looks. A schema migration against a live database. A script that emails every customer. A change to billing logic. The cost of a mistake doesn't scale with how hard the task appeared going in.

Ask, for anything you're about to grant autonomy over: if this goes wrong, what does undoing it cost, and who notices before it compounds. That single question sorts most of the ambiguous cases correctly.

Who's on call for it

Borrow the discipline from any other risky infrastructure decision. Before granting a new capability, name the person on call for what it does with that capability.

Not a team. A name.

If nobody can answer in one sentence, the capability isn't ready to grant, however good the model has got.

Don't take the permission back

There's a reflex worth naming and resisting. When something goes wrong under an agent's autonomy, the instinct is to narrow the permission. It feels like the responsible move, it's quick, it's visible, and it fixes nothing.

The permission wasn't the defect. The missing validation was, and it's still missing after you've shortened the leash, sitting there waiting for the next thing that finds it. Narrowing the grant buys you the appearance of a response while leaving the actual hole exactly where it was.

So autonomy ratchets one way, and every incident gets spent on the gate rather than on the leash.

Something reached production that shouldn't have? Then something wasn't validated. Name it. Add the check.

That's the harder discipline of the two, and it's harder for an unglamorous reason: taking a permission away takes an afternoon and looks decisive, while building the validation that would actually have caught the thing takes much longer and shows up on nobody's dashboard.