Approval Fatigue: When Users Click Yes to Everything

Approval fatigue is what happens when an AI app asks for permission so often that people stop reading the prompts. They click "approve" or choose "always allow" to get on with their work. The safety check is still there on paper, but it no longer protects anyone.

MCP leans heavily on human approval. The tools specification says "there SHOULD always be a human in the loop with the ability to deny tool invocations." If that human is worn out, the main safety net is gone.

Anthropic named the problem directly when it added sandboxing to Claude Code. Its engineering post warned that constant approval "can lead to 'approval fatigue'" where users "might not pay close attention to what they're approving." This page explains how to keep approvals meaningful. Sources were checked on 28 October 2026.

Why approval fatigue is a security problem

Each prompt asks a person to make a security decision in a few seconds. Most prompts are harmless, such as reading a file or listing records. After dozens of harmless prompts, the risky one looks the same.

People respond in predictable ways. They approve without reading. They pick "always allow" for a whole server. Or they switch on a mode that skips prompts entirely.

The result is visible in research. In Invariant Labs' GitHub MCP demonstration, a malicious public issue led an agent to leak private repository data. The report notes the user had the agent set to "Always Allow." No prompt appeared at the moment it mattered.

The spec's own authors see the same trade-off with OAuth. The best practices page lists "consent abandonment" as a risk when consent screens show too many scopes.

An illustrative example

This scenario is illustrative, not a real incident.

An operations manager uses an AI assistant with five MCP servers. In the first week, it asks for approval about 40 times a day. Almost all are reads.

By week two, the manager clicks "always allow" on every server. A month later, the assistant processes a vendor email with hidden instructions. It calls the payments server to update a supplier's bank details. No prompt appears, because the manager approved that server weeks ago.

Who is at risk

• Heavy daily users of AI apps with many connected servers.
• Teams that copy permissive settings from a colleague or online guide.
• Developers who turn on "skip all prompts" modes to work faster.
• Organizations without central policy, where each user makes their own permission choices.

How to detect it

• Review client settings for "always allow" on servers that can write, send or pay.
• Check whether anyone uses a prompt-skipping mode outside isolated environments.
• Ask users how many prompts they see per day. A high count predicts rubber-stamping.
• In logs, look at approval times. Approvals in under a second suggest no one is reading.

How to reduce the risk

Client side

The tools spec says applications SHOULD make clear which tools are exposed, show visual indicators when tools run, and present confirmation prompts. Clients SHOULD also show tool inputs before calling the server.

Good prompts share three traits:

1. They are rare. Reserve them for actions that change, send, delete or pay.
2. They are specific. Show the server, the tool and the full inputs, not just "Allow tool?"
3. They are scoped. Offer "allow this once" and "allow this tool," not only "allow everything from this server."

Use allow and deny rules

Many clients let you pre-approve safe tools and block dangerous ones. For example, Claude Code's permissions docs describe rules such as mcp__github__get_* to allow one server's read tools. Rules "are evaluated in order: deny, then ask, then allow," so a deny rule always wins.

The same docs warn that its bypassPermissions mode, which skips prompts, should only be used "in isolated environments like containers or VMs." Administrators can disable that mode through managed settings.

Sandbox instead of prompting

Sandboxing replaces many prompts with hard limits. Anthropic's post describes "filesystem isolation" and "network isolation." It reports that "in our internal usage, we've found that sandboxing safely reduces permission prompts by 84%." Fewer prompts means the remaining ones get attention. See sandboxing local MCP servers.

Server side

• Use tool annotations to mark read-only and destructive tools honestly. Clients treat annotations from untrusted servers as untrusted, so this helps most for servers you trust.
• Split read and write actions into separate tools, so clients can allow one and prompt for the other.
• Request narrow OAuth scopes and step up only when needed. The spec's scope minimization guidance aims to reduce "consent churn." Our page on excessive permissions covers scope design.

Organization side

• Set default allow and deny lists centrally, so users do not invent their own.
• Ban "always allow" on servers that can move money, send external messages or delete data.
• Train staff on the few prompts that matter. Our AI and MCP acceptable use policy template includes approval rules.

What the spec says

The core specification page states that "hosts must obtain explicit user consent before invoking any tool." Users "should understand what each tool does before authorizing its use."

For local servers, the best practices page is stricter. One-click install dialogs MUST show the exact command "without truncation" and require explicit approval. For elicitation, clients MUST show which server is asking, per the elicitation spec.

The spec does not say how many prompts is too many. That is a design choice for each client and organization.

Next step

Count how many approval prompts your team sees in a day, then cut the harmless ones with allow rules and keep prompts for risky actions. Our MCP readiness audit reviews client permission settings and recommends a default policy. For related threats, see the MCP Security Center.

Frequently asked questions