Approval Fatigue is a security issue, not a UX problem

TLDR: An AI security guardrail that asks for approval too often just gets turned off. I’m pretty sure most people almost immediately from manual mode to auto or bypass-permissions. A switched off guardrail protects nothing. Most auth prompts get approved anyway so people just run their agents in bypass mode and that is that state agents are often in when it deletes a production database. The fix is to reduce false positives and make every authentication mean something, not to show more of them; Tiered approvals, a short memory for exact repeat commands, hard blocks that don’t require the user and no way to loosen any of this silently without explicit user instruction.

Repo: https://github.com/DobermanCore/Doberman-Core

Discord: https://discord.gg/Sfy5XGNqty

Nine Seconds

In April, a Cursor agent wokring on PocketOS , a car rental SaaS, hit a credential mismatch. Instead of stopping there, it found a Railway API token that was configured over-permissioend in the codebase and utilized it to delete the production database and all of the volume backups. According to the founder, this all happened in a span of nine seconds. Afterwards the agent wrote in a postmortem that began with “I violated every principle I was given” [LiveScience, TheRegister]

Just a month prior , claude code ran terraform destory agaubst DataTalks.Club’s production setup and took with it over two years worth of records, database, snapshots and all. Luckily this was recovered but only because AWS stored a internal snapshjot and was able to restore it for them a day later.

Neither of these were external attacks, jailbreaks or malicious injections. Both times, the agent reached a irreversible harmful action and there was no moment where a human was actually asked for permission. Either approvals were turned off, or the prompt was fired as one of a couple dozen that day and got the same reflex approval as all the others.

The issue with approval prompts

Anthropic’s own data says that Claude Code users approve 93% of permission prompts.

This is the entire issue in one figure. If 19/20 prompts are just noise, people stop looking at them and eventually people stop looking at them. Bypass-permissions has a nickname, YOLO mode, it became a popular preference as the alternative was death by dialog.

Anthropic’s answer to this was auto mode which was supposed to be an increase security level comparable to sandboxing while keeping the autonomy level similar to bypass permissions. It’s a classifier that clears approvals you would let through anyway and stops the model after three denials in a row. I think the instinct is right and also an AI deciding exactly when a model’s agent requires human intervention, is the exact kind of boundary I mentioned last time. But this belongs alongside a deterministic layer instead of in replacement of it.

Attackers have also noticed this exploitation; An open threat rulesset added a technique in March.

Human Approval Fatigue Exploitation: ATR-2026-00118: Bury one risky call in a batch of benign ones and let the reflex do the rest.

The gap between belief and practice is huge. In Gravitee’s 2026 survey, 88% of organizations confirmed or at least suspected an agent related security incident in the last year even though 82% of executives were confident in their security policies in preventing unauthorized agentic actions.

From this, I stopped treating approval fatigue as a usability problem. It’s a security flaw. If the security depends on human review but the design almost guarantees the humans skip the review, the security is broken.

What a prompt has to earn.

This is the updated design I landed for Doberman in the last two weeks in v0.18.4

Three Verdicts, not one dialog: PASS is routine work, automatic approval. BLOCK is dangerous and stopped cold without ever reaching you. (i.e. rm -rf outside a temp dir, a forced push to a protected branch or a curl that posts your AWS credentials to a host that isn’t on the whitelist) Those don’t require a prompt because there is almost never a scenario where those situations would be safe. AUTH sits in the middle of these, situations and that is the exact and only place where approval is needed.

Tiers within AUTH. Even in AUTH we should be creating tiers to further reduce the fatigue. A soft confirm is one click, local auth is a preset password and Two Factor or Windows Hello. Role elevation, is a narrow, time-limited grant. The tiers of authentcation matches the risk, with low risk actions costing just a click and high-risk ones requiring identity-proof.

A short term memory. This was added recently as I noticed that agents often repeat themselves or need retries of the same command to the same target three times in a minute. Before these latest changes each attempt required a full two factor auth. It became so annoying even I turned off Doberman. Now after you approve something with two factor you have the option to remember this approval, and for the next five minutes it will reduce risk threat of identical actions to soft confirm. This identicalness is measured, not guesswork, using HMAC fingerprints over the action type, tool used, normalized commands and arguments and the target. Change one of these flags and the risk is raised right back.

Some things don’t get added to memory. Certain commands, especcially irreversible ones like force push, deletes, history rewrites and so on do not get added. A soft confirm never seeds the memory so approvals can’t chain preventing attacks like ATR-2026-00118. Also only the fingerprint of the action is stored, never the actual command or path, and decision logs are all recorded differentiating between normal and memory approval so you can distinguish it later.

Nothing loosens silently. This is the rule I have kept the same, even if it means added friction. Every knob in Doberman can tighten with no human approval, but every loosening requires a human authentication with Two factor at the veryu least. This week a contirbutor wired the egress velocity thresholds in to the CLI and the first thing we checkes was that raising the threshold required the two factor auth but lowering it was automatic.

Uncertainty is denied. Doberman does not assume it is correct, if Doberman cannot classify a call it’s blocked, if it is repeated, it gets reduced to two factor auth.

Why the memory is not a vulnerability

The obvious thing to point out is that the memory represents a huge security flaw. A hijacked agent only needs one approval and the maliciuous action is allowed by memory to loop.

But think it through, the first approval requires identity proof. The proceeding actions still require soft confirm and only in the short 5 minute window. A different action, even if only slightly, gets raised right back to two factor. Anything irreversible could never enter memory and the dangerous actions that run are the ones that humans have approved. Attackers gain nothing that the users hasn’t approved, and memory allows for less decision fatigue for the user.

Try out Doberman

Two commands is all it takes

Pip install doberman-core
doberman setup

It’s local first, apache 2.0 and works with Claude Code, Codex, Open claw and any MCP Agent.