Permission modes are a spectrum

The framing I kept hearing early on was a binary: either you approve every command an agent wants to run, one at a time, or you turn off the guardrails and let it do whatever it wants unsupervised. Neither end of that is where I actually operate, and neither is where anyone I know who runs agents seriously for real work operates either, once the volume of commands gets past what a person can meaningfully approve one by one.

Approve-everything sounds safe and is not, in practice, because it does not survive contact with the actual rate of tool calls a working agent makes. Past a certain volume, a person approving every single command stops reading each one and starts clicking approve on reflex, which is worse than not having the control at all — it is a safety mechanism that is technically present and practically inert, because the attention it depends on has already been exhausted by the fortieth call of the day.

The opposite end — disabled guardrails, full autonomy — trades that failure for a different one: no backstop at all for the specific class of command that is cheap to run and expensive to undo. Those two failure modes point at the same conclusion from opposite directions: the interesting design space is neither extreme. It is the middle, where most of the actual engineering effort in permission systems goes.

What that middle looks like in practice is layered rather than binary. A small set of hard deny rules sit underneath everything else — specific, named, destructive operations that are refused outright regardless of context, with no override available except a deliberate and logged exception. Above that, a classifier or rule layer reads what a proposed command actually does and decides whether it is safe to auto-approve, worth a light confirmation, or worth stopping for. And above that, genuine judgement calls still go to a person, but a much smaller, much more meaningful set of them, because the layer underneath has already absorbed everything routine.

The part that makes this work rather than just adding complexity is that the categories are not static. Routine, once established, gets to stay auto-approved, and anything that looks like it but is not quite gets to fall back to a confirmation rather than either extreme. That is the actual value over a binary: the system’s tolerance for autonomy can track how well understood a given class of action actually is, instead of treating a config file rename and an irreversible history rewrite as if they required the same ceremony.

The hard part of building that middle layer is that it has to judge a command by its text, and text under-describes what a command will actually do. A single shell line can hide its real effect behind a variable, a substitution, or a pipe into something that expands to a path nobody wrote down, and a rule matching on the visible words either misses that or refuses half the harmless commands that happen to resemble it. The only version of this I trust fails closed on ambiguity: anything the layer cannot confidently classify goes to a person rather than through, and the deny rules underneath are written against effects that are hard to disguise rather than against spellings that are easy to. That is less elegant than a clean classifier, and it is the difference between a permission layer that holds under an unusual command and one that was only ever tested against ordinary ones.

What I run day to day is closer to that layered middle than to either pole: hard-blocked destructive operations that no amount of asking nicely gets past, a permission layer that clears the routine work without making me click through it, and my own attention reserved for the handful of decisions per day that are actually worth spending it on. That is not a compromise between safety and speed. It is what both of those things actually require once the volume of decisions exceeds what one person can review one at a time.