Autonomy without losing control

In "Why AI agents should stop asking for permission" I picked a fight with the permission prompt. That post was the punch. This one is the engineering behind it, because "stop asking" only works if something better is standing where the prompt used to be.

The lazy version of an autonomous agent is easy to build: give the model a shell, turn off the confirmations, and pray. I have no interest in that, and neither should you. The question I actually care about is harder: how does an agent act on its own, for minutes or hours, while the person stays the final authority over what happens on their machine?

My answer, after a lot of rewriting in the ClarkCant codebase, is that authority is not a dialog box. It is a set of things the person holds: the policy, the ability to stop, the record of what happened, the right to settle anything uncertain, and the limits nothing can exceed. Here is each one, where it lives in the code, and where it is still weak.

Start with who is allowed to decide. In ClarkCant only a user principal can approve an operation; that is enforced in the grant contracts, not in the UI. The open interfaces make it sharper: there is deliberately no approval tool on MCP. An AI client that could call "approve" could approve its own guarded action, so every route that records a person's decision answers 403 PERSON_ONLY when it arrives over MCP or the generic relays.

So the person is not asked about everything. But the things only a person may do, approving, deciding an install, trusting a paired machine, issuing a grant, reconciling an unknown outcome, cannot be done by anything else. That is what "final authority" means in practice.

Until 19 September 2026, every seam in ClarkCant decided for itself whether to ask. Now there is one function, decideExecution in packages/core/src/execution-policy.ts, and every effect goes through it: a command, a widget action that is not just a view change, an install. Its order is written at the top of the file: prohibition, then hard boundary, then rules, then mode.

A node-wide "deny everything" beats all. Hard boundaries come next: an OS permission, an OAuth grant, a browser device permission or a vendor's own consent screen is asked for in every mode, because it is not this application's decision to make. Then your rules per category of effect, where "deny" always wins. Then the mode: Autonomous (the default), Guarded, Ask every time.

Autonomous has a risk gate. If the agent decides on its own to write outside the machine, destroy something, spend money, communicate or capture audio or video, it asks, because no person's instruction covers it. Work handed over by a paired node runs only within what this node's owner allowed that peer. And a mode the build does not recognise fails closed: the honest answer to "may I?" is no, not a guess.

Policy decides who is asked. Preflight decides what is possible, and it runs before any model is consulted. In apps/runtime/src/preflight.ts every command must resolve inside a folder the node owns, the folder must exist, and the operation carries its budget: two minutes and 8,000 bytes of output per stream for run_command. A capability the node has not discovered cannot be invoked, whatever the proposal claims.

Jev, the guardrail, sits after that and is explicitly a judgment layer, not a security boundary. It can allow, deny, ask a clarifying question, or narrow. If its answer would widen anything, a longer deadline, a bigger output, a directory outside the one the host resolved, applyGuardrailConstraints refuses the whole answer rather than quietly clamping it.

Isolation is concrete rather than aspirational. A child process inherits an allowlisted environment, so SSH_AUTH_SOCK, AWS_* variables, GITHUB_TOKEN and provider keys are dropped. Every child runs in its own process group so a stop reaches grandchildren. A dispatched task worker has no shell at all: its commands cross an IPC channel to the host and go through the same preflight, policy, guardrail and audit, and where that path would need an approval card, the broker refuses instead, because a background task should never wait on a question nobody is looking at. A browser task gets its own Playwright profile under the node's data directory, never your browser, limited to the sites you named, with private-network addresses refused and the profile deleted when the run ends.

The docs are honest that none of this is a perfect sandbox. They say outright not to advertise a lease as one, and that a browser context is not a security boundary.

Autonomy turns on one question: whose intent is this? ClarkCant records it on every task. Interactive means a person asked in the conversation. Delegated means a paired node handed it over under a grant. Persistent means an automation a person set up earlier, limited to the effects they gave it. System means the node's own work, which nobody asked for, and which the policy treats accordingly.

Within interactive turns, the node also records which surface the message came from: the person, an AI client over MCP, a relay, a program on the HTTP API. By default a program is treated like you, and the Settings copy is frank that a program holding the node token could change that setting anyway. If you opt in, risky effects asked for by a program wait for you.

Provenance also covers what goes into the model. Project instructions from a .clarkcant folder are framed as data that grants nothing. Page text from a browser task reaches the model as data, never as instructions. A signal from a paired node is recorded under the sender the authenticated channel names, not the one the message claims. And the design rule for widgets is that nothing claims "live" when it is a snapshot or a sample.

The audit trail in packages/storage/src/audit.ts answers the question you ask after something surprising: what ran, when, and how it ended. Nothing in that module updates or deletes a row. It records commands, each use of a secret by name and consumer, approvals, stops, which model a worker was started on and where its key came from, and more. It never records a value. The comment puts it plainly: a secret that appears in the audit is a secret that has leaked.

It also refuses to blur outcomes. A stopped command is recorded as stopped, not failed, because a trail that cannot tell them apart misleads whoever reads it later. In the interface, Settings has an "Effects run without asking" list, which is where Autonomous mode owes you a trace.

I would love to say everything has Undo. It does not, and the design document forbids promising Undo for irreversible external actions. What exists is real. Every preference write keeps the value it replaced, so undoing returns to what was actually there, including deleting the row if there was nothing before. A dismissed inbox notice can be restored for five minutes, after which the server answers UNDO_EXPIRED rather than pretending. A package install creates immutable generations, and rollback leaves the previous generation serving.

Revoking a paired machine blocks its future operations. It does not roll back effects that already happened, and the docs say exactly that.

This is the part I am proudest of, and it is the least flashy. Every external effect goes through a ledger: prepared, submitted, then confirmed, failed or unknown. If the acknowledgement is lost, the effect is unknown, and unknown is never retried into success or failure. The task moves to uncertain, the inbox gets one notice quoting what happened, and only the person can settle it. In a browser task, while a submit is unknown, no further click of that task reaches the page, so the button is never pressed twice.

Success has the same discipline. The only path into succeeded is verification with recorded evidence: an exit status, a file version, an API receipt, observed browser state. A worker going idle, a model ending its turn or a socket closing is not success. The architecture doc even says: if there is no test count, do not invent a test count. That is what I mean when I say Clark should be able to say "I don't know". It is not a personality trait. It is a state in the state machine.

Machines crash and laptops close. After a restart, apps/runtime/src/work-recovery.ts reports every unfinished run once, in the conversation where it was asked for. An orphaned process is stopped only when the machine boot and the kernel's start time for that pid match what was recorded, so a recycled pid is never touched. Background work with no effects is re-run once, only in Autonomous mode and only within a day. Work with effects is never re-run: it becomes uncertain and waits for a person.

Stop is the other half. POST /stop kills the process group of every running command, worker and terminal, interrupts turns and cancels queued background work. You can also just ask Clark to list or stop work. A peer that has not answered for more than 10 minutes gets one notice that says what is owed and what to do, not a spinner.

ClarkCant is a bootstrap, not a release, and the conformance ledger in the repository marks nothing complete. Some specifics. The guardrail fails open by default when it cannot be reached; preflight and containment remain, and you can switch it to stop. The link between paired nodes has no TLS yet: key verification is a fingerprint comparison over plain HTTP. Epoch fencing at the point an effect is submitted is not wired yet. Browser tasks have no human takeover or live preview yet, and Computer Use is partial, waiting on a signed native binding. Prompt injection can still steer a model; isolation limits the damage, it does not prove safety.

I would rather publish that list than have you find it.

The permission prompt gives you the feeling of control before the action. What I want is control that holds during and after it: a policy you chose, boundaries a model cannot argue with, a record you can read, a Stop that actually stops, an Undo that never lies, and an agent that says "unknown" instead of "done" when it does not know.

That is not a YOLO agent. It is closer to a good colleague: you hand over the job, they get on with it, and when something is outside what you asked or they are not sure what happened, they come back to you. I might have the balance wrong in places. Tell me which control you would need before you let an agent run while you sleep.