Why AI agents should stop asking for permission

You have seen this UX. Maybe you are using it right now.

"I want to run this command. Allow?" Sure. "I want to read that file. Allow?" Fine. "I want to call this API. Allow?" Yes. "I want to run the tests. Allow?" Yes, obviously, that is literally what I asked you to do.

Somewhere around the fifth prompt I start asking a different question: so where the hell is the autonomy? I handed the agent a job so I could stop babysitting it, and now I am babysitting it with extra steps.

I build ClarkCant, and this post is me being deliberately one-sided about a choice we made: Clark, the agent, does not ask for permission to do what you already asked it to do. I will also tell you where it still asks, because "never ask" is just as lazy as "always ask".

Here is the uncomfortable thing about permission prompts. They work beautifully on the first one. You read the command, you think about it, you decide. By the twentieth, you are not reading. You are clicking Allow the way you click "I agree" on a terms of service page. Your hand has learned the button faster than your brain could learn the risk.

At that point the prompt is theatre. It still looks like a safety mechanism, and it still lets everybody say "the user approved it", but the human in the loop has quietly left the loop. Worse, the prompts are thickest exactly when you are deep in a long task and most tired, which is also when a strange command is most likely to slip through.

I do not think the people who design these flows are stupid. Asking is the cheapest way to look careful. But a control that depends on a human paying full attention, every time, forever, is not a control. It is a liability waiver with a nice button.

In fairness to everyone else: ClarkCant did exactly this. On 18 September 2026 we merged a change that put every command behind an approval card. The next day we replaced it with an execution policy. The commit messages from that day say it better than I can: "commands run under an execution policy instead of an approval card", and "asking a person is a policy, not the gate".

What we found when we looked honestly was worse than annoyance. The comment we left in packages/contracts/src/execution.ts says the old yes/no flag "made the approval card the load-bearing control: with it removed there was nothing left between a model's proposal and a shell." The card was not one layer of safety. It was the only one. And the comment at the top of apps/runtime/src/preflight.ts admits that a folder restriction had been removed in favour of that card.

So taking the card out of the default path was not the hard part. The hard part was putting real boundaries back into the host, where a model cannot talk its way past them.

Not a dialog. A pipeline. Every effect Clark wants to cause goes through the same order: host preflight, then the execution policy, then the guardrail, then execution, then evidence and audit.

Preflight is deterministic and runs before any model is consulted. A command must resolve inside a folder this node owns, the folder must exist, and the command carries a deadline (two minutes) and an output ceiling (8,000 bytes per stream). The child process gets an allowlisted environment, so SSH_AUTH_SOCK, AWS_* variables, GITHUB_TOKEN and provider keys do not leak into whatever runs. Secrets are metadata to the agent: it knows github_token exists and what it is for, and the value goes straight into one invocation, never back to the model.

Then the policy decides, in a fixed order: a node-wide "deny everything" beats all, OS and account boundaries come next, then your per-category rules, then the mode. Then Jev, the guardrail, may judge the command against your own written rules ("never delete git repositories"). Jev can deny, ask a clarifying question, or shrink the command, and if it tries to widen anything, a longer deadline, a bigger output, a folder outside the one the host chose, the whole answer is refused.

My favourite line in the codebase is a comment in packages/core/src/execution-policy.ts: "Autonomy changes who is asked, never what is checked."

Afterwards, you are not left guessing. Every effect lands in an append-only audit trail, by name and outcome, never by value. Settings has a list called "Effects run without asking", which exists precisely because Autonomous means things ran without a card. Stop is real: POST /stop kills every running child's process group, interrupts turns and cancels queued background work, and a stopped command is recorded as stopped, not failed. And Undo exists where it can be honest: a preference change returns to what was actually there before, a dismissed notice can be restored for five minutes, and a package rollback leaves the previous generation serving.

Now the fair part. Clark still asks, and I think these are exactly the right places.

When the action is outside your intent. Autonomous has a risk gate: if Clark decides on its own to do something in a risky category, writing to something outside this machine, destroying data, spending money, sending a message, recording audio or video, it asks, because you never asked for that. The code comment calls this "the difference between an assistant that carries out what it was told and one that sends mail nobody asked it to send."

When it is not our decision to make. OS permission prompts, OAuth consent, browser camera and microphone permissions and a vendor's own confirmation are asked in every mode, including Autonomous. ClarkCant does not pretend it can grant those on your behalf, and browser and computer control never click a consent screen for you.

When the work came from someone else. A task a paired machine hands over only runs within what this machine's owner allowed that peer. Anything else waits for the owner, in every mode.

When there is genuinely more than one right answer. "Which project should I delete?" is not a permission prompt. It is a question, and it ends the turn, so waiting for your answer costs nothing.

And if you simply prefer to be asked, that is your call, not mine. Settings has four levels: Autonomous, Guarded (local work runs, anything outward, destructive, financial, communicative or recording opens a card), Ask every time, and Deny everything. You can set rules per kind of work, and "Deny" always wins. You can also tell Clark to treat requests from other programs, an AI client over MCP or a script on the API, differently from your own messages. The point is not that asking is evil. The point is that asking should be a policy you chose, not the only thing standing between a model and your shell.

I want to be straight about the weak spots, because a post like this is cheap otherwise.

The guardrail is a judgment layer, not a security boundary. If Jev cannot be reached, the default is to keep going without the judgment step. Preflight and containment still hold, and you can flip it to stop instead, but the default is fail-open and you should know that. Prompt injection from a web page can still steer a model; isolation reduces the damage, it does not prove safety. Undo does not exist for an email that already left, and we refuse to fake one. And ClarkCant is a bootstrap, not a release. The conformance ledger in the repo says so in plain words.

There are smart people who believe every action should be confirmed, and they are not wrong about the risk. I just think confirmation is the wrong tool for it. I might be wrong. Only people actually living with these agents can settle it, so tell me.