Permission theater sucks. Agent speed needs real boundaries.
As agents get faster, permission prompts cannot be vague interruptions. They need blast-radius context, smart review, and visible boundaries inside the coding surface.
The worst permission systems teach users to stop reading. They interrupt constantly, explain nothing, and reduce every decision to a reflexive “allow.” That is not safety. That is permission theater.
Agents make the problem sharper. A fast agent can read, edit, run, install, delete, push, and call tools before the user has mentally caught up. The answer is not to slow everything down. The answer is to make risk visible where decisions happen.
Permission theater
A generic modal that says “allow command?” is almost useless. It does not tell the user what the command touches, whether it is destructive, whether it leaves the repo, whether it escalates privilege, or whether it downloads code and runs it. It only moves liability to the person clicking.
Blast radius
A useful approval surface names the action, target, risk class, and evidence. Reading a file is not editing release config. Running tests is not running a remote shell script. Deleting generated output is not deleting source. The UI should reflect those differences.
Permission prompts should answer
- What is the exact action?
- What files, commands, or external systems are involved?
- Can this mutate source, config, secrets, git state, or external state?
- Is there enough evidence to allow, reject, or ask for human context?
Smart approve
MendCode’s smart approval path treats risky shell permissions as reviewable objects. It detects dangerous commands, scripts, destructive flags, privilege escalation patterns, remote execution shapes, and commands that need context. Then a reviewer model can return a strict decision: allow, reject, or ask.
{
"decision": "allow | reject | ask",
"reason": "short reason"
}The point is not to let AI rubber-stamp AI. The point is to add a bounded reviewer in front of high-risk actions and preserve the human’s ability to stay in control.
Not autopilot
Smart approval is not a magic permission bypass. It should be more conservative than a tired human, not more reckless. The useful behavior is to allow clearly bounded actions, reject obviously dangerous ones, and ask when context is missing. “Ask” is not failure. It is the correct output when the blast radius cannot be understood.
That distinction matters because agents will increasingly operate inside loops. A loop that can wake up later should not be able to expand its own authority just because the next command looks similar to the last one. Permission decisions need context, scope, and memory of what was approved.
Smart approval decisions
| Decision | Meaning | Example |
|---|---|---|
| allow | Bounded, local, reversible enough | Run the project test command in the repo |
| reject | Destructive, exfiltrating, privileged, or remote-execution shaped | Pipe curl into shell or remove broad paths |
| ask | Risk depends on context the reviewer cannot know | Run a migration, rotate files, or touch deployment config |
Surface placement
Permissions belong in the coding surface, not as disconnected popups. If the user is inside a session, the pending permission should be tied to the session, tool call, mode, and current risk posture. The approval decision is part of the work, not an interruption from another product.
Workflow diagram
Agent requests a risky action
Smart approval classifies blast radius
Human sees allow/reject/ask with context
Speed needs boundaries
The faster agents get, the more important boundaries become. A slow assistant can be manually supervised. A looped agent needs policy. Report-only defaults, explicit gates, permission modes, and smart approval are not enterprise decoration. They are what makes speed usable.
Permission modes should match the work
| Mode | Use it when | Failure mode it avoids |
|---|---|---|
| Require approval | The user wants manual control | Silent mutation |
| Smart approval | Risk can be classified with command/context | Click-through fatigue |
| Report-only | A loop should inspect before editing | Background agent overreach |
Loop permissions
Loops change permission design because the user may not be staring at the terminal every second. The safe default for recurring or background work is report-only. Let the loop inspect, summarize, and propose. Promote it to editing only when the objective, stop conditions, gates, and permission mode are explicit.
A good loop permission model answers: what can this loop do while I am away, what must it ask before doing, when does it stop, and what evidence will I see when I return? Without those answers, background autonomy is just unattended risk.
loop.draft({
objective: "Monitor stale docs and report fixes",
permissionMode: "report-only",
gates: ["do not edit files", "cite stale pages", "stop if release docs changed"]
})Audit trail
Permission decisions should leave evidence. If an agent ran a command, the user should be able to see the command. If smart approval allowed it, the user should see why. If a risky command was rejected, that should be visible too. Invisible safety is not safety the user can learn from.
The audit trail is also how teams improve policy. If the same safe command gets manually approved twenty times, maybe it needs a narrower allow rule. If the same dangerous command keeps appearing, maybe a package or prompt is wrong. Permissions are feedback, not just gates.
A useful audit trail includes
- The exact command or tool request.
- The session, loop, package, or mode that caused it.
- The decision: allow, reject, or ask.
- The short reason and any missing context.
The right feeling
A good permission system should feel calm. Safe actions move. Risky actions explain themselves. Dangerous actions stop. Ambiguous actions ask. The user is not forced to babysit every tool call, and the agent is not allowed to blur the line between help and control.
Agent speed is only valuable when the boundaries are sharp enough to trust.