Permission Architecture

Two weeks into a rollout where every agent action requires approval, an engineering manager pulls the permission log to see how the trial is going. What she finds is a run of eleven prompts approved within four seconds of each other — a file diff, a shell command, a network request, in sequence, each cleared faster than a competent reviewer could read the first line. The eleventh prompt was a force-push to a shared branch. Nobody remembers approving that one specifically, because by prompt eleven nobody was reading them specifically. The harness had done exactly what it was configured to do: ask before every write. The human on the other end of the prompt had stopped being able to answer the question it was asking.

A second team, further along the same rollout, drew the opposite conclusion from a similar frustration and flipped the harness to its most permissive mode — no prompts, no pauses, full autonomy inside the repository. A week later an agent tasked with tidying a stale scratch directory swept up files that had existed before the session started, and there was no pause point where anything could have stopped it. Both teams were answering the same design question, and both answers were wrong in the direction each team was leaning. One had turned a safety mechanism into ceremony until ceremony was all that was left of it. The other had removed the mechanism entirely and called the removal efficiency.

What repeated approval trains out of a reviewer

Neither failure is speculative, and neither is specific to AI agents. Security operations centers have studied the first one for years under the name alert fatigue: when warnings arrive faster than an analyst can meaningfully evaluate them, the rate of true-positive detection collapses regardless of the analyst’s skill or diligence, because the bottleneck was never competence — it was volume against a fixed budget of attention. Code review has its own well-documented version of the same collapse, usually called rubber-stamping: once a reviewer has approved enough pull requests that look like the last one, approval becomes a reflex triggered by the shape of the request rather than a judgment about its content.

A harness that asks permission for everything is, mechanically, an approval queue, and approval queues degrade the same way regardless of what is in them. A team that has been trained to click "yes" on a hundred harmless file edits has not been trained to notice the hundred-and-first request that quietly asks for something else. This is a close cousin of a failure Volume III named directly in its discussion of plan-mode gates — the ceremony failure mode, where a safety step performed on every task regardless of its actual risk stops functioning as a safety step and starts functioning as a tax that gets paid without being felt. Permission prompts are the same gate applied continuously instead of once per session, and they degrade faster because there are more of them.

Gate by risk, not by category

The industry answer that has converged across harnesses by 2026 is not "ask less" or "ask more." It is ask proportionally to what could go wrong. Reading a file, searching a codebase, running an existing test suite, or checking git history cannot corrupt anything on their own — gating them teaches reflexive approval and buys no safety in return, so mature harnesses auto-approve this category outright. Writing a file, running a command with a side effect, or installing something new can cause damage that is usually recoverable — a bad edit shows up in a diff, a bad command leaves a trace — so this category earns an actual pause, one a reviewer still has the attention left to take seriously because it is not competing with a hundred read-only prompts for the same budget. A third category is not merely risky but hard or impossible to undo — force-pushing over history, deleting a branch, committing straight to the branch a whole team ships from, touching a credential, reaching into production infrastructure — and harnesses increasingly treat this category as default-deny even in their most autonomous modes, requiring something closer to a named, explicit override than an approval click.

This is not a novel idea borrowed from AI safety research. It is the principle of least privilege, formalized in computer security half a century before agentic coding existed: every program and every user should operate with the least set of privileges necessary to do its job, specifically because that discipline bounds the damage an accident or an error can do without requiring anyone to predict every accident in advance. What is new is not the principle. It is applying it at the grain of a single tool call, continuously, to an actor that can act at a speed no human approval queue was ever designed to keep pace with.

Four tiers of operation

Stripped of any one vendor’s naming, the tiers that recur across harnesses look like this. The table lists representative operations at each tier and the default policy a well-designed harness applies to it — not what any single tool calls the tier, but the shape every tool converges toward.

Never main

One convention inside the fourth tier deserves its own name because of how much damage it converts on its own: agents work on feature branches, never on the branch a team actually ships from. The rule sounds almost too simple to be a design decision, but its effect is structural rather than incidental. A bad edit on a feature branch is an annoyance a human review step catches before it reaches anything that matters. The exact same bad edit committed directly to the protected default branch is an incident. The operation did not change; the blast radius attached to where it landed did. Treating "never commit to main" as a hard rule rather than a habit converts an entire class of catastrophic mistakes — the ones that reach production, or a teammate’s working copy, before anyone reviews them — into merely annoying ones that get caught in the normal course of a pull request.

This is also why the highest tier increasingly resists override even from a harness’s most trusting mode. A push that reroutes around review, a commit that lands on a branch other people build on top of, a rewrite of history someone else has already pulled — these are exactly the operations where "the agent seemed confident" is the weakest possible justification, because confidence is not the variable that determines whether the mistake is recoverable.

A reference architecture, named precisely

Claude Code’s permission modes are worth walking through in detail because they are the most fully documented instance of this consensus in production, and because the names matter for anyone reading a team’s configuration later. A manual mode auto-approves nothing beyond reads and prompts for everything else — the default, and the right choice for sensitive work or a session nobody has calibrated trust for yet. An edit-accepting mode auto-approves file edits and common in-scope filesystem commands while still gating anything with a side effect outside the working directory — useful once a team trusts the agent to make changes it will review afterward via diff rather than inline. A restricted planning mode, covered in this Library’s Volume III, permits reads and exploration only, producing a proposal rather than a diff. A locked-down mode auto-denies anything not on an explicit allowlist, built for CI and scripted, unattended runs where there is no human to ask. And a mode that skips checks entirely exists, deliberately scoped to isolated containers with nothing valuable to damage — its own documentation is explicit that it offers no protection against a bad decision or a hostile one.

The more sophisticated point in the design sits in the mode built to eliminate prompts without eliminating oversight. A separate classifier model reviews each proposed action against the same tiers this chapter has already described — blocking scope escalation, unfamiliar infrastructure, and anything that looks driven by content the agent read rather than an instruction a person gave — and lets everything else through without interrupting the session. Comparable machinery has shown up independently elsewhere: OpenAI’s Codex CLI shipped a background-review mode in the same period that a maker reports cuts human approval interruptions roughly two-hundred-fold relative to manual approval, evaluating actions at the point they would cross a sandbox boundary rather than asking a person to clear each one. Two harnesses building the same shape of solution to the same problem, independently, is itself evidence that this is where the field has actually converged and not merely where one vendor happened to land.

The classifier that never reads the output

One design detail in Claude Code’s classifier is worth stating precisely, because it is a structural defense against a specific attack rather than an added layer of caution. Indirect prompt injection — hostile instructions hidden inside a file, a web page, or a command’s output that an agent then reads and, in effect, obeys — is now formally cataloged as the top risk in the OWASP framework for large-language-model applications, and the person who named the underlying vulnerability class described it as directly analogous to SQL injection: untrusted data quietly reinterpreted as instructions. An approval system built to defend against it has to answer an uncomfortable question — what happens when the thing deciding whether to approve an action has already read the poisoned content that action is meant to act on?

The documented answer is that the classifier making the approval decision is shown the user’s messages, the pending tool call, and the project’s standing instructions — and is explicitly never shown the results any tool has already returned. Injected text sitting inside a file, a search result, or a command’s output has no channel to reach the approver, because the approver was never built to read that channel in the first place. This is not a filter trying to detect and strip malicious-looking instructions from tool output, an approach that only ever chases the newest evasion. It is an architecture where the attack surface does not exist for the approving component regardless of how the injection is phrased. The distinction matters because most prompt-injection mitigation in production still works the first way — scan the content, look for known bad patterns — while this works the second way, which fails closed rather than fails detected.

The classifier does not need to detect the injection. It is architected so the injection has nothing to talk to.

What a harness should be logging

Operon does not yet run enough sessions across enough teams to publish measured figures for how permission-tier design changes approval behavior in the field. What follows is illustrative — the shape of the telemetry this chapter’s claims should eventually be checked against, not a result.

Putting the tiers into practice

1. Stop gating reads. If an operation cannot corrupt state, approving it teaches nothing and costs attention that the next real decision needs.
2. Give writes a real pause, not a rubber-stamp queue. A gate a reviewer can actually attend to beats a gate that fires on everything and is attended to by nobody.
3. Name the default-deny tier explicitly, in writing, before a session starts — force-push, protected-branch commits, credential access, production infrastructure — rather than discovering its boundaries from an incident.
4. Make "never main" a structural rule the harness enforces, not a convention repeated in onboarding docs that erodes the first time someone is in a hurry.
5. If adopting a background-review or classifier-style mode, verify what it can see. A reviewer that reads tool output is a reviewer that can be talked to by whatever hostile content that output contains.

None of this eliminates judgment calls — a team still has to decide where its own boundary between "reversible" and "not worth the risk" sits, and that boundary will differ between a side project and a production payments system. What a tiered permission architecture removes is the false choice between an approval queue nobody reads and an agent nobody can stop. The next chapter in this volume moves one layer down, from what an agent is allowed to do to what it is physically able to reach at all — sandboxing, network egress, and blast radius as a design budget rather than an afterthought.