Agent permission model

How a harness decides what an agent is allowed to do without asking first. The layer between the model's intention and the machine's filesystem, shell and network, and the part of an agentic coding harness that has nothing to do with making the agent better at its job.

The corpus holds two sources on it. claude-code-auto-mode describes a three-way trade between safety, throughput and attention; anthropic-browser-use-tool adds the case where the agent asks for several actions at once and the trade has to be made mid-sequence.

The confirmation-fatigue result

The design most harnesses shipped first is per-action confirmation: the agent proposes, a human approves. It is easy to defend and it produces a number that is hard to defend — human reviewers caught 13.6% of harmful actions, against 89% for anthropic's automatic approval, across 1,053 paid developers.

The mechanism is not that the humans were careless. It is that a prompt asking for approval hundreds of times a session trains the person to dismiss it, so the control degrades in proportion to how much the agent is used. A safety measure that fires constantly is a safety measure that stops being read, and the more useful the agent gets, the less protection the same design provides.

That result is worth keeping separate from the remedy. It stands on its own and it is bad news for every harness in this corpus that treats an approval prompt as its safety story.

What the automatic version moves rather than solves

Handing the decision to the model changes who is inattentive, not whether anything gets through. On the reported figures 11% of harmful actions still pass — now at machine speed, with no human in the loop by design rather than by fatigue.

Two things follow, and neither is settled by anything held here:

• A perfect injection score describes the attack set. 720 attempts, none successful, was measured against a suite chosen for the test and commissioned by the vendor being tested.
• The untested shape is the trusted one. Willison's example is a malicious package whose instructions read as legitimate work. Adversarial-prompt suites test the agent's resistance to something that looks like an attack; a supply chain delivers something that looks like the job.

Batching moves the gate inside the loop (2026-08-21)

claude-browser-use adds a wrinkle the corpus had not hit: Claude can request several browser actions in a single model turn, arriving as multiple tool_use blocks for the developer's executor to run in order. The point is fewer model calls on a long task, and it works.

What it breaks is where you put the check. With one action per turn, the model call is the boundary — you approve, or you don't, and nothing has happened yet. With a batch, a sequence can open on a click nobody would gate and end on something that needs a person, so the executor has to inspect actions as it runs them and stop mid-batch. The gate moves from the protocol boundary into the developer's own loop, and it is now their code deciding what counts as needing permission.

Note what this does to the 13.6% result above. Batching does not fix confirmation fatigue; it makes the prompts rarer per unit of work while giving each one a larger, partly-executed sequence behind it. Written 2026-08-23: Nobody has measured whether a person approving step 4 of 9 reviews it any better than a person approving step 4 of 9 separate prompts. Corrected 2026-08-30: the batched form is unmeasured, the general form is one of the better-measured findings in security usability, and it points the wrong way for everyone here.

Habituation is documented and quantified. A large-scale Chrome study found 50% of users who hit an SSL warning clicked through it in 1.7 seconds or less — too fast to have read it. Neuroimaging work at Brigham Young University showed the visual-processing response to a repeated security warning measurably declining with exposure: the effect is not laziness, it is a documented perceptual process, and it sets in after roughly 20–30 similar interactions.

And it has now been measured on agent prompts specifically. In one study of AI agent use, 3 of 16 participants read prompts carefully and 13 of 16 (81%) used "Always Allow" simply to make them stop. That is the same mechanism arriving in this spoke's own subject, and it is the strongest available evidence that the approval gate degrades under repetition regardless of how it is batched.

What remains genuinely unmeasured is the comparison this page asked for — whether a batch of nine is reviewed better or worse than nine separate prompts. Both arms are subject to habituation and the literature does not settle which arm suffers more. Note also a lead not yet read here: Options, Not Clicks: Lattice Refinement for Consent-Driven MCP Authorization (arXiv 2605.11360), which proposes structuring the choice rather than repeating it.

The correction changes the argument's centre of gravity. The page has been treating confirmation fatigue as a plausible worry; it is a measured effect with a rate attached, which makes KOT's refusal below — that a gate everyone clicks through is not security — an empirical position rather than a provocative one.

The third position: remove the gate (2026-08-23)

KOT states it as flatly as it can be stated: "There is no security, and there will not be. The agent runs commands and edits files with the rights of the user who started it. No sandbox, no allow/deny/ask rules, no confirmation on every step." The reason given is the throughput leg of the trade above — "an agent that asks for permission every other step does not finish the job, it spends your money on a conversation about intentions" — and the remedy is pushed out of the product: "Isolation is a property of the environment, not of the agent." Run it in a container, a VM, or a separate user account.

The argument is not new; the conclusion drawn from it is. nanoclaw reasons from the same premise — that application-level allowlists are not real isolation — and ships containers. KOT reasons from it to shipping nothing, which converts a safety property into an operator deployment step that nobody measures. Both designs above at least produce a number. This one cannot: there is no gate to score, so the only question is how often the container actually gets built, and no source here answers it.

It is also the case where the confirmation-fatigue result gets used as justification rather than as a problem to solve — 13.6% is bad, therefore prompt zero times. The inference skips the alternative the same study supports, which is a better-placed gate rather than no gate.

The fourth position: one approval, then a ceiling underneath (2026-09-23)

agent-workspace-linux takes KOT's premise, that "isolation is a property of the environment", and builds the environment instead of leaving it to the operator. The agent gets its own hidden X11 desktop and browser. The person approves that workspace once (--ack-hidden-workspace), and the design then wants actions inside it to run without "a second generic permission prompt storm". So the confirmation-fatigue problem is handled by moving the gate: one question up front, not one per step.

What makes it a distinct position is where the hard limit lives. With no configuration, the MCP adds nothing and defers to the host's approval flow, like every harness above. With a --permissions file, a ceiling on network, mounts and allowed apps is checked twice: at the MCP front-end and again at the workspace daemon's socket, so apps launched inside the workspace cannot go around it. The ceiling can't be widened at runtime; only a restart with a new file changes it. The human's live pause and read-only controls are explicitly not the boundary. Two limits are stated plainly: without bubblewrap, the mount and network rules are declared but not enforced, and the socket gives no protection between processes of the same user. Like the rest of this page, nothing is measured: no prompt count, no escape test.

The fifth position: borrow the asker's authority, per action (2026-09-28)

company-brain is a different axis from the four above, not another point on the same one. The first four all ask how much oversight does the agent's own authority get — every step, batched, none, or one ceiling set up front. Company Brain instead asks whose authority a write uses: a tool call runs under the asking user's own connected-tool credentials, not a grant the agent holds itself. When a request needs a different person's tool connection, the agent doesn't act and doesn't ask its operator for a broader grant either — it sends that teammate an approve/deny card and waits. There is no ceiling to configure and no prompt-fatigue count to run, because the gate is identity-shaped rather than frequency-shaped: the question is never "how often do we ask," it's "whose credential does this action need."

That sidesteps the confirmation-fatigue result rather than answering it — there is no volume of per-action prompts to fatigue anyone on, since most actions need no prompt at all when they run under the asker's own standing grants. But it inherits agent-scope-isolation's honest admission from qm in a new form: the scheme controls who authorizes, not what a model already holding a conversation's content chooses to repeat into a channel that credential wouldn't have reached. No SECURITY.md-equivalent accompanies the claim here, and nothing is measured — a maker's README, one repo, no independent report.

A sixth axis: prove the gate held, after the fact (2026-09-28)

The five positions above all answer how much oversight does the agent get before it acts. auto-browser answers a different question: how would anyone know a gate that looked like it held actually held? Every governed call chains into an Ed25519-signed "witness receipt," and the exported bundle verifies with a standalone script that imports nothing from the project, so the person checking the log does not have to trust the controller that produced it. That is a record layered on top of whichever authorization design a harness already runs, not a replacement for one.

The project's own public self-audit is the sharper point. Its docs/audits/ writeup names safety controls that "reported success while doing nothing" and were fixed only after the gap was found and written down. That is a live instance of exactly the failure mode this page keeps circling: a gate nobody is separately checking can fail silently, whether the reason is habituation in a human reviewer or a bug in the code enforcing the rule. A signed, independently verifiable receipt does not stop the control from failing; it stops the failure from going unnoticed.

Where this sits against the spoke's thesis

The synthesis argues that the frontier model writes the code and the value moved into the wrapping. Permission is the clearest case of the wrapping doing work no model quality can do: a better model is not a more constrained one, and capability and authority are independent dials.

It is also the dial that runs the opposite way from every other one in this corpus. effort-level, orchestration and skills all exist to let the agent do more; the permission model exists to decide what it may do at all — and the direction of travel documented here is the same as everywhere else, toward removing the human from the loop.