Redesign AI approval prompts so users stop missing threats

Every approval prompt should earn its place

A yes/no prompt appears after every read, write, and test run. A reviewer clicks yes, and the dangerous command arrives with the same visual weight as the harmless one.

The receipts are blunt. In an August 2026 browser-game data point, players missed about one-third of threats even though they knew they were being tested. An internal study cited by Anthropic found that an ask-the-user-for-everything approval approach missed 86.4% of threats across 1,053 testers. In the Scale X browser game, threats appeared in about 34% of the commands players saw. The dataset behind that game included more than 40,000 runs and 409,000 approve/deny decisions.

The misses are not evenly spread. In the Scale X game, npm run analyze was the single most-missed command and was approved 64.7% of the time. Three exfiltration commands hidden behind familiar script names were missed 52.5% of the time across 9,482 decisions, compared with 28.4% for other exfiltration-style attacks. In that same game, 32.9% of sessions closed at a loss because the harm from approved threats and denied safe commands outweighed the benefit of right calls.

When a reviewer is asked to decide too often, each decision still gets less attention. A prompt that interrupts routine work trains the reviewer to ignore it. Approval fatigue is a design failure. The interface is asking for too much. Redesigning the flow means changing what they see, not just what the agent can do. It also means deciding which actions are safe enough to run quietly and which ones need a clear, expandable explanation.

The approve/deny modal should follow risk, not volume

Use the five-pattern approval redesign checklist below. Each step reduces the prompts that require judgment and makes the remaining prompts easier to read.

• Scope task permissions before the agent starts. A session card appears before any command: what the agent can read, run, or change, and what it cannot. The card names the task and hides unrelated tools. The boundary is visible, so the reviewer is not asked to infer it from a prompt.
• Expand command previews before they choose. A finished modal shows the command, the files it will touch, the network calls it will make, and the output it will write. If the preview says only run script, they are guessing. A good preview answers the key questions: what will change, what will leave the machine, and what can be undone.
• Set default deny permissions for actions that are hard to reverse. Hard-to-reverse actions are blocked unless they explicitly allow them. Default deny protects the reviewer from becoming a rubber stamp. They should see the category, not just the command, so they can learn the boundary.
• Skip prompts for safe reversible reads. Safe reversible reads run without a modal. A compact log replaces the wall of yes/no choices. The log should be skimmable, with timestamps and a way to replay the sequence. The reviewer can quickly see what happened without interrupting the agent.
• Narrow allowlists as the agent learns. A command moves from ask to allow only within a tight scope, with an audit trail showing what was allowed, when, and by whom. The allowlist should shrink as the agent gets better, not grow into a permanent exception set. If a command keeps failing the allowlist, the fix is usually a better preview or a narrower task, not a broader exception.

The approval surface should be small enough to remember

Keep the approval surface small enough that the reviewer can clearly remember recent decisions. If the interface requires scrolling through a long queue of pending actions, the threat that matters most will compete with routine work. The modal should show the current action, the reason it is risky, and the smallest scope that would let the agent continue. The log should show the rest of the history, including who allowed the action and what changed.