How to Stop Your AI Agent Asking Permission for Everything (Without YOLO Mode)
Stop approving every action by drawing one line: auto-approve the reversible actions (file edits under version control, reads, local builds) and keep a human gate only on the irreversible ones (money, publishing, messaging, identity). The dividing line is reversibility, not trust. A mistake in the first group is one revert away; a mistake in the second cannot be taken back, so it waits for a person.
This solves what you could call the autonomy paradox: if you approve every action, you are not faster, you are just a slow human bottleneck sitting in front of a fast machine. Clicking approve on 200 file edits is not oversight, it is theater. But the usual escape hatch, YOLO mode or auto-approve-all, swings too far the other way and lets the agent spend money or publish live with no gate at all. The middle ground is not a trust dial you turn up over time. It is a structural split between what can be undone and what cannot.
This article is the HOW. If you want the full WHAT (the exact list of actions that should always require a human), read our companion piece on what an agent should never do without asking. Here we focus on reducing the clicking without adding risk.
Which approvals can you safely turn off?
Turn off approvals for the reversible ones: file edits under git, reads, and local builds, because a mistake is one revert away. These are the actions that make up the bulk of an agent's work and almost none of its danger. Reading a file changes nothing. Editing a file that is tracked in version control leaves a diff you can inspect and undo. Running the site build locally produces output you can throw away.
In our own setup, this reversible group is an allowlist: a named set of operations the agent just does without stopping to ask. It edits its own working files, it reads anything in the project, and it runs the static-site build to check its work. Across a multi-hour session that is easily a few hundred individual operations that never once interrupt a human, and every one of them is recoverable from git history. The point is not that the agent never errs. It is that when it does, the cost of the error is a single command.
Reversibility is only real if you actually keep restore points, which is why the auto-approve list and the commit habit are one system, not two. We checkpoint with a git commit roughly every hour and after every finished task. That cadence is the safety net under the whole allowlist: if the agent produces an hour of bad edits, the worst case is losing up to an hour and running one revert. Without the commits, "reversible" is a claim; with them, it is a fact you can execute in seconds.
What stays human-approved no matter what?
Five categories stay human-approved no matter what, because they are irreversible or high-stakes: spending money, publishing or creating accounts, messaging real people, acting under the owner's identity, and stepping outside the allowed tools. These are the never-alone list. Money leaves the account and does not come back on a revert. A published page or a sent message is seen by real people the instant it goes out. An action taken under the owner's name cannot be un-said. So each of these five waits for a human, every time, with no exceptions earned by good behavior.
The list is deliberately short and blunt, because a gate you have to reason about at 2am is a gate that leaks. The agent does not weigh whether a given spend is small enough to skip the ask. In our system it must request approval for any spend at all, even a few dollars. That is the whole value of a bright line: it removes judgment from the moment of action, where judgment is most likely to be wrong or rushed.
There is a narrow, honest exception to keep this from being rigid, and we log it. A carve-out is a specific permission granted permanently after it has been earned and written down. Our agent, for example, sets product prices on its own, because pricing is reversible and we decided in advance it could own that call. But it must still ask for any spend. One category moved from the gated side to the allowed side, explicitly, in writing, once. That is different from the agent quietly deciding on its own that a rule no longer applies to it.
The net effect of the split is a system that is faster and safer at the same time, which is what the autonomy paradox says should be impossible. It works because "faster" comes from the reversible allowlist and "safer" comes from the irreversible gate, and the two never touch the same action.
FAQ
Is YOLO mode ever OK?
Only inside a sandbox or isolated environment where nothing it touches is real: a throwaway container, a scratch repo, a test account with no money and no audience. In that setting there is nothing to break, so full auto-approve is fine and often useful. Never run YOLO mode on your live files, real accounts, or actual money, where a single wrong action is irreversible.
What if the agent needs something that is off the allowlist?
It writes the request into a human-inbox file (we call ours FOR_HUMAN) and waits. The ask-first inbox turns a blocker into a queued proposal: instead of stopping dead or acting without permission, the agent records exactly what it needs and why, then moves on to other work. When a human next appears, they read the queue and approve or reject in one pass.
Does auto-approving actions reduce safety?
Not if you auto-approve only reversible actions. Reversibility plus git makes those mistakes recoverable, which is actually safer than trusting the agent to be careful, because it does not depend on the agent being right. A careful agent that spends real money can still ruin your day; a careless agent whose edits are all under version control cannot do lasting damage. Recoverability beats good intentions.