Permission Fatigue Is Not a UX Problem. It Is a Security Failure.

esc to close

Every AI coding agent that asks "Allow this action?" is relying on a security model that has already failed in every other context where it has been tried.

Windows UAC. Android permissions. Browser notification prompts. Cookie consent banners. The pattern is always the same: present the user with a decision, rely on them to make the right one, and discover that they stop reading after the third prompt.

AI coding agents have adopted this model wholesale - and the consequences are worse, because the actions being approved aren't "show notifications" or "access your camera." They are "execute this shell command" and "read this file" and "make this network request." The stakes are higher, the volume is higher, and the human attention budget is the same.

The numbers

A typical AI coding session involves hundreds of tool calls. The agent reads files, runs commands, edits code, runs tests, reads more files, runs more commands. Each action is a discrete operation that, in a permission-prompt model, could require approval.

Most agents mitigate this with allowlists - ls, cat, whoami execute without prompts. But allowlists are coarse. They approve categories of commands, not specific invocations. curl to localhost and curl to an attacker's server are the same command. cat ~/.ssh/id_rsa and cat src/utils.ts are the same command.

The operations that matter - the ones that could be malicious - look identical to the ones that are routine. And they are buried in a stream of dozens or hundreds of legitimate actions.

Even at a 95% auto-approve rate, a session with 300 tool calls surfaces 15 prompts for manual review. That is 15 interruptions where the developer must context-switch from their actual work, parse the operation, assess the risk, and make a decision. Research on interruption costs found that developers take an average of 10-15 minutes to return to productive work after an interruption, passing through multiple intervening tasks before resuming¹. Even when the interruption is brief, the cognitive cost is not - each prompt breaks flow state and forces a context reload.

Developers are not going to do this. They are going to press Enter.

The research says the same thing

This is not speculation. Every domain that has tried the "ask the user" model has measured the same result.

Windows UAC: Microsoft introduced User Account Control in Windows Vista to prompt users before privileged operations. Microsoft's own telemetry showed that consumer administrators approved 89% of UAC prompts, and only 13% of lab study participants could explain why they were seeing the dialog². Microsoft themselves stated they were "obviously concerned users are responding out of habit due to the large number of prompts rather than focusing on the critical prompts." They responded by reducing the frequency of prompts in Windows 7, which improved user satisfaction but reduced the security value to near zero.

Android permissions: Felt et al. studied 308 Android users and found that only 17% paid attention to permissions during installation³. The remaining 83% either ignored them entirely or did not understand what the permissions meant. The same study found that fewer than 3% of users were both attentive to and capable of comprehending the permissions they were granting.

Browser security warnings: Akhawe and Felt analysed over 25 million browser security warning impressions and found clickthrough rates of 33% for Firefox SSL warnings and 70% for Chrome SSL warnings⁴. Users treated security warnings as obstacles to their goal, not as information relevant to their safety.

Clinical alarm fatigue: In healthcare, alarm fatigue from patient monitors leads clinicians to disable or ignore alarms, contributing to patient deaths. The Joint Commission identified alarm fatigue as a national patient safety concern - of 98 alarm-related events reported between 2009 and 2012, 80 resulted in death⁵. The parallel is direct: when safety-critical alerts fire too frequently, the humans responsible for responding to them stop responding.

The consistent finding across every domain: when the rate of safety prompts exceeds human attention capacity, the prompts become a ritual rather than a review. Users develop heuristics ("I'll just click yes"), and those heuristics override the security model.

Why AI agents make this worse

AI coding agents have three properties that make permission fatigue more severe than in any previous context:

1. Volume. A coding session generates more actionable operations per minute than any previous permission-prompt context. UAC prompts fire a few times per day. Android permissions fire once per install. AI agent tool calls fire continuously throughout a session.

2. Ambiguity. In the UAC model, the user can at least see what program is requesting elevation. In the AI agent model, the agent generates novel commands dynamically. The user has not seen this exact command before and cannot predict whether it is safe from its syntax alone. python -c "import urllib..." could be a legitimate test helper or an exfiltration payload. The user has no way to distinguish them in the 2-3 seconds they spend reading the prompt.

3. Adversarial context. AI agents process untrusted input - project files, web content, MCP server responses - that can contain prompt injection. The malicious action is generated by the agent's own reasoning, in response to instructions the user never saw. The user is not reviewing their own decisions. They are reviewing the output of a system that may have been manipulated.

Permission prompts only work when the user can understand what is being requested, assess whether it is safe, and make a decision without time pressure. AI coding agents satisfy none of these conditions.

The approval theatre problem

The result is what we call approval theatre: a security mechanism that creates the appearance of human oversight without providing the substance.

The agent prompts. The developer approves. A log records that the action was "user-approved." If something goes wrong, the system can point to the approval and claim the human was in the loop.

But the human was not in the loop. The human was habituated, fatigued, and making automatic decisions at a rate that precluded meaningful evaluation. The approval is a record of ritual, not review.

This is worse than having no security model at all, because it creates a false sense of safety. A developer using a tool with no permission prompts knows they have no safety net. A developer using a tool with permission prompts believes they have one - and behaves accordingly.

What the failure mode looks like

The attack chain enabled by permission fatigue is simple:

1. The agent processes untrusted input containing a prompt injection
2. The agent generates a sequence of operations: several legitimate, one malicious
3. The developer approves the first few operations, establishing automatic approval behaviour
4. The malicious operation arrives in the stream, syntactically similar to the legitimate ones
5. The developer approves it without evaluation
6. The attack succeeds with a logged "user approval"

This is exactly the pattern demonstrated in CVE-2025-55284 (Claude Code DNS exfiltration)⁶ and CVE-2025-54135 (Cursor remote code execution via prompt injection)⁷. In both cases, the exploit relied on the agent generating operations that looked routine, embedded in a stream of operations that were routine. The permission model did not fail because it was absent - it failed because humans cannot operate it at the required throughput.

The alternative

The solution is to remove humans from the per-operation decision loop and replace them with programmatic evaluation that does not fatigue, does not habituate, and does not rubber-stamp.

This means:

• Per-syscall scoring, not per-command prompting. Evaluate every file read, shell command, and network request against multiple independent filters - path sensitivity, destination reputation, data taint tracking, behavioural anomaly detection.
• Deterministic thresholds. Low-risk operations auto-allow. High-risk operations auto-deny. Ambiguous operations queue for human review - but "ambiguous" means 5-10 operations per session, not 15-30.
• Context-aware decisions. cat src/utils.ts and cat ~/.ssh/id_rsa are not the same operation, even though they are the same command. A scoring system evaluates what is being accessed, not just how.

This is the model grith implements. The human stays in the loop for genuinely ambiguous decisions - the 1-2% of operations where automated scoring cannot make a confident determination. Everything else is handled by filters that evaluate at machine speed, with consistent criteria, across every operation in the session.

Permission prompts are not security. They are a user interface that creates the illusion of security while depending on a human capacity that does not exist at the required scale. The answer is not better prompts. It is a different architecture.

What this looks like in practice

Wrap any AI coding agent with grith and the permission model inverts. Instead of prompting a human for every ambiguous action, grith's 17 independent security filters evaluate every syscall in under 15ms:

The routine operations auto-allow. The SSH key read and the connection to an untrusted destination auto-deny. The developer sees none of these decisions as interruptions - they scroll past in the status bar while the agent runs normally above. 80-90% auto-allow. 1-5% auto-deny. The remaining 5-15% - genuinely ambiguous calls - are batched into a quarantine digest for review at the developer's convenience, not as interruptions during flow state.

No habituation. No approval theatre. No "just click yes."

grith is open source (AGPL v3) and works with Claude Code, Codex, Aider, Cline, Open Interpreter, and any other CLI tool. One command to wrap your existing workflow with architectural security: grith exec -- <your-agent>.

Footnotes

1. Mark, Gonzalez & Harris: No Task Left Behind? Examining the Nature of Fragmented Work (CHI 2005) ↩

2. Fathi: User Account Control (Engineering Windows 7 Blog, October 2008) ↩

3. Felt et al.: Android Permissions - User Attention, Comprehension, and Behavior (SOUPS 2012) ↩

4. Akhawe & Felt: Alice in Warningland - A Large-Scale Field Study of Browser Security Warning Effectiveness (USENIX Security 2013) ↩

5. The Joint Commission: Medical Device Alarm Safety in Hospitals (Sentinel Event Alert 2013) ↩

6. NVD: CVE-2025-55284 ↩

7. HiddenLayer: How Hidden Prompt Injections Can Hijack AI Code Assistants Like Cursor ↩