Most permission systems for coding agents are allowlists: read files yes, write files yes, run tests yes, everything else ask. That works until someone marks an agent “fully trusted” to stop the prompts, and the agent runs git push --force on a Friday.
Our position is that four categories of action should stop for a human every time, regardless of how trusted the agent or the requester is. Trust levels decide how many other things need approval. These four are never silent.
The four
1. Pushing to a shared branch. A commit on a feature branch is a suggestion. A push to main or release is a decision the whole team inherits, often with a deploy attached. The action is cheap to ask about and expensive to walk back.
2. Deleting. Files, branches, tables, buckets, resources. Deletion is the one operation where a wrong guess about intent cannot be undone by a second guess. Agents are confident, and confident deletion is how backups get tested.
3. Spending money. Calling a paid API, provisioning a resource, buying a domain, sending a campaign. The person who asked may not know the request costs anything. The person who pays should.
4. Touching credentials. Reading a key file, exporting environment variables, logging into a service, completing two-factor authentication. Anything here is about identity, and identity belongs to the machine’s owner, not to whoever is in the room.
Why “fully trusted” should still pause here
A permission mode describes a person’s relationship to the agent: read-only, edit but don’t push, full trust. That is the right granularity for the hundreds of ordinary calls an agent makes in a session. It is the wrong granularity for the four above, because they are rare, irreversible or expensive, and because the cost lands on someone other than the requester.
So the rule in muti is simple: no permission template can set these four to run silently. Even in “full trust” mode they stop and are highlighted in the timeline. The prompt is rare enough not to be annoying, and the categories are precise enough that the answer is usually obvious.
How this maps onto Claude Code’s permission modes
Claude Code already has a ladder: plan (read only), default (ask before edits and commands), acceptEdits (edits run, commands ask) and bypassPermissions (nothing asks). Those modes describe how much the agent asks you. The four actions describe what must ask the owner when someone else is asking. They stack.
The last column is the room’s addition and is the same in every row. See permission modes, explained.
Who should be asked
This is the part most designs skip. When a shared agent needs a human, which human?
- Credentials go to the owner. Logins, two-factor codes and key access are about the owner’s identity. They route to the owner no matter who started the task. The requester sees that a takeover happened, not the secret.
- Intent questions go to the requester. “Did you mean the staging database?” is about what the person wanted. It routes to the person who asked.
- Both see the same timeline. Neither has to relay context to the other; the question and its answer sit in the same thread as the work.
Credential and dangerous-action prompts route to the owner; intent questions route to the requester; both see the exchange.
Anatomy of a good approval card
An approval that people can decide in five seconds has five parts.
Give it three buttons: approve, reject, and continue read-only. The third one is underrated. It lets the work go on while the risky step waits.
Let approvals be answered anywhere the owner already is: the console, a phone, or a chat platform card. Deciding in one place should apply everywhere. Set an expiry so a forgotten card doesn’t run a week later.
Approval fatigue is the real enemy
Every prompt trains the person who sees it. Too many, and they will find the setting that turns them off. Three things keep the rate low without loosening the four rules.
- Scope the agent. One working directory per agent means fewer files it could touch, and fewer prompts about touching them.
- Use the ordinary modes for ordinary calls. Read-only for exploring, edit-without-push for most work. Reserve “full trust” for people who would otherwise be typing on your keyboard.
- Make the default templates honest. Ship read-only, edit-but-don’t-push and full-trust as named presets, so nobody has to build a policy from scratch and get it wrong.
The audit line
Every request and every approval should produce one line the owner can export: who asked, who decided, when, which rule, what happened, what it used. Not because anyone reads it daily, but because the day something goes wrong is not the day to start logging.
Frequently asked questions
Doesn’t asking every time slow the agent down? Only for these four categories, which are rare in a normal session. The cost of the pause is seconds; the cost of the mistake is measured in hours or in money.
What about the owner using their own agent? The owner isn’t subject to permission modes on their own agent, but the four actions are still recorded in the timeline so the history is complete.
Can a requester approve for themselves? No. Approval belongs to the machine’s owner. The requester can cancel, retry or add context.
The personal agents launched in 2026 converged on similar gates for their owners' own requests; how Muse, dots, Grok Bot, WorkBuddy and QoderWake compare is in allow once, always allow, deny.
Rooms in muti ship with these rules on and no way to switch them off. If that sounds like the right default, give your agent a room.
Published · Updated