Compare approving every step manually: at first you read everything the llm proposes carefully, convinced that you'll catch it out. After a while you get faster and faster until at some point you find yourself hitting "approve" the second the text appears, long before you actually could absorb what it said.

This is called "approval fatigue".

If you think this can't possibly happen to you, you might be in for a surprise. This is an almost textbook case of classic conditioning. You'll find yourself hitting that button faster and faster even while fighting back the urge. So a human is no guaranteed backstop.

This is the scenario that cc auto mode guards against. It cuts down the number of permission prompts to something manageable, so that your fingers don't get trained into clicking 'approve' on 'rm -rf' in the very eyeblink that it appears.

So maybe you feel it doesn't work in theory; but weirdly enough, in practice this particular approach is actually one of the better ones; especially when used in combination with other common sense measures where practical.

I'm not claiming auto is worse than manual; I'm claiming it cannot be compared with anything security-wise because it does not aim to provide any guarantees, there's no systematic way to reason about what it will and won't allow, etc

With e.g. VM or container sandboxing, we can say things like "If there are no vulnerabilities in the hypervisor or hardware, then the agent can only access these files, these network services, etc". Auto mode doesn't even try to provide any guarantees, so it's impossible to reason about. It amounts to just using the models judgment about what's "malicious" or not, a definition which is subjective, changes model to model, and can be influenced by attacker input.

Empirical evaluations of how many vulnerabilities manual vs auto mode let through are not super meaningful because auto mode changes dramatically with model releases, the type of task being performed, whether the attacker is making targeted attacks designed to bypass auto mode, etc. A security feature cannot rely on these sorts of factors if it's to be taken seriously.

Further, percent of malicious tool calls accepted is a bad metric. It's like measuring the security of ssh in terms of what percent of unauthenticated logins succeed. The only acceptable value is zero. It's pass/fail, not a spectrum. So both auto and manual mode should fail equally here. Further, the set of malicious tool calls admitted in auto mode may not be a subset of those admitted in manual mode.

As real as approval fatigue is, it can't really be considered worse than effectively leaving the decision up to the party that proposed the action in the first place.

>This is called "approval fatigue".

Doesn't matter, that would be on me.

It's also a false dillema. Those aren't the only options. A strictly enforced sandbox with sane defaults (for example ~/.ssh), that acts as a hard OS level limit, and not just as a suggestion to the agent, would not have "approval fatigue".

This is the conundrum we find ourselves in. Do we submit to approval fatigue and press “Don’t ask again”? Because that’s the dream. We all wish we could just trust the agent to do the task start to finish, unsupervised.

But this is the downside. It might be fine 99% of the time, but 1% of the time you get a critical secret published to GitHub, even after human review.

Is this even worse than what us humans did on our own before LLMs? I’m not sure. It’s not like secrets never got accidentally committed before, it just illustrates the new paradigm we’re working in.

Either you let your agents run wild, and you cross your fingers that they don’t do anything bad, or you need to accept that your new job is to be an agent babysitter, and audit every command.

No, this is the way I have worked for a long time, and I have not suffered from any approval fatigue.

Rather what has happened is that I have gotten very good at scanning what it is trying to do and know within a second or two whether there is anything fishy I need to look at more closely.

And by "fishy", I do not mean only security issues, but also architecture, code, etc issues. Sometimes it even adds unrelated unapproved changes to what it is supposed to be working on, and I stop it.

And I'm glad I work this way, because countless times I have stopped it from going down a path that is nonsensical or I strongly dislike.

There are techniques I have adopted to speed up working this. Sometimes I allow Claude to make larger changes at once, to batch several changes at once, etc. But these decisions are under my control.

I prefer to work this way than to wade through enormous PRs trying to wrap my head around what was done, where I am likely to just give up and approve it after a cursory review.

[flagged]

[dead]