Why 'always allow' is the most dangerous button in enterprise AI software

Every agent product ships a checkbox that says some version of do not ask me again. It exists because the prompts are unbearable. It also silently deletes the only control the architecture had.

Part of Agent tool-call gating

Watching someone use it

The developer had been at it for forty minutes. The agent was refactoring a service, and every file write produced a dialog: allow this tool to write to this path?

She read the first four. By the twelfth she was clicking through them while looking at the terminal. At the nineteenth she found the checkbox, ticked it, and did not see another dialog that afternoon.

She is a careful engineer. Nothing about her judgement failed. The interface presented her with a decision nineteen times in forty minutes and gave her a mechanism to stop, so she used it.

What the click actually does

The semantics vary and are rarely stated clearly. Depending on the product, one click can mean any of:

A user cannot distinguish these from the dialog. The grant they think they are giving and the grant they are giving differ, and the difference is invisible until something goes wrong.

The fatigue is arithmetic, not character

Approval fatigue is well documented in security contexts — push notification fatigue, certificate warning fatigue, alert fatigue in operations centres. The pattern is consistent: as prompt frequency rises, considered response rate falls, and it falls faster than linearly.

An agent performing a coding task may execute dozens of tool calls per minute. A system that prompts on each of them is not implementing human oversight; it is implementing a rate limiter that the human will remove.

The friction ladder

The design answer is to stop treating all tool calls as equivalent. Four rungs, and most calls belong on the first.

The critical design move is rung 1. A system that does not prompt on reads reduces prompt volume by an order of magnitude, which restores the meaning of the prompts that remain.

Classifying reliably

The ladder only works if classification is trustworthy, and it cannot be inferred from a tool's name or description — both are attacker-controlled when the tool server is third-party.

Classify at the registry level, by review, and bind the classification into the signed registry entry. A tool server that changes its schema after approval no longer matches, and the runtime can detect that.

If a persistent grant must exist

Sometimes it genuinely must — a long-running agent, an overnight batch, a workflow nobody will be present for. The answer is not to forbid it but to bound it.

grant:
  tool:      write_file
  scope:     path_prefix = /workspace/service-a/
  excludes:  **/*.env, **/secrets/**
  max_calls: 500
  notAfter:  2026-06-25T18:00:00Z
  signed_by: [human credential]

Four bounds — scope, exclusions, count, expiry — and a signature. The user has still escaped the prompts, and the escape has edges.

What to measure in your own product

1. Prompts per user per session. If the median exceeds single digits, users will find the escape hatch.
2. Time-to-decision distribution. A median under two seconds means the prompts are being dismissed rather than read.
3. Persistent grant rate: share of users who have enabled one, and how broad it is.
4. Grant breadth: for each persistent grant, what could be done under it. Most products have never computed this.

That fourth number is usually the one that changes the roadmap, because it reveals that a single click three weeks ago authorises everything the agent has done since.

Why the button exists and what to do instead

The fix is not to remove the button but to make the prompts rare enough that nobody wants it: gate the irreversible subset, render the effect, and offer a bounded scope grant instead of an unbounded one.

Objections and honest limits

“Users should just be careful.” They are being careful about the fortieth prompt in a session, which is a different cognitive task from the first. Designing around that expectation is how the button got clicked.

“Record which actions were auto-approved.” Worth doing and it is telemetry rather than control. It tells you afterwards that nobody looked; it does not stop the action.

Making always-allow unnecessary

1. Gate only irreversible effects. So the prompt is rare.
2. Render the effect, not the command. Row counts, recoverability, environment.
3. Offer a bounded grant instead of always. Scope, ceiling and expiry, signed once.
4. Enforce at the endpoint. So a client setting cannot disable the control.

Terms used here

Approval fatigue

The degradation of attention caused by frequent prompts, converting review into reflex.

Bounded grant

A scoped, expiring authorisation covering a class of actions — the alternative to an unbounded always-allow.

Endpoint enforcement

Gating at the service that performs the effect rather than in the client the user configures.

Frequently asked questions

Should the button be removed? No. Removing it without reducing prompt volume produces users who abandon the product or route around it. Fix the volume first, then bound the grant.

Why not prompt on everything to be safe? Because it is not safe. High prompt volume produces reflexive dismissal, which is worse than a well-designed ladder with genuine attention on rung 4.

How do we classify third-party tools? By review at registry level, bound into a signed registry entry with a schema hash, so a post-approval change is detectable.

What about long-running autonomous workflows? A bounded persistent grant with scope, exclusions, a call ceiling and an expiry, signed by a human. The human signs the envelope rather than each action.

Why do users click always-allow? Because per-command confirmation is slower than doing the work manually. It is a rational response to a badly posed choice.

What should the prompt show? The effect — rows affected, recoverability, environment — not the command string.

Sources and further reading

• Published research on alert, certificate and multi-factor approval fatigue.
• Model Context Protocol specification
• 2 CFR Part 200 — Uniform Administrative Requirements for Federal Awards
• Reported incidents involving broadly scoped agent tool approvals.
• Anthropic — Claude Code security and permissions
• OWASP Top 10 for Large Language Model Applications