Approval Fatigue Is a Control Failure

Before the detail — Decision: treat approval fatigue as a control that has already failed, not a training gap in the approver. Outcome: a small, named set of actions asking for approval, each one rare enough to earn attention. Artifact: the approval wallet plus a receipt query that counts how often ask fires, accepted when the count is low and the actions on it are the ones that deserve two eyes. Status of what follows: reusable guidance, built on one vendor’s own published numbers.

Prompt first: count what you’re actually asking

Pull last week's receipts for mu-ai-011. For every row where the
envelope decision was "ask", list: the action, how many times it
fired, and how many of those were approved without the approver
opening the plan hash first (if you can't tell, say so - that gap is
itself the finding).

Do not propose adding more approval steps as the fix for a high
approve-rate. Propose which of the actions currently on `ask` could
move to a bounded, receipted allow instead, and which one - if any -
genuinely needs a human every time because it is irreversible.

The prompt asks for a count before it asks for a fix, because the fix for fatigue is never “explain it to people more clearly.” It is reducing how often the question gets asked at all.

The honest number, and what it actually measures

Anthropic’s 2026-03-25 Claude Code auto-mode post stated: “Claude Code users approve 93% of permission prompts.” In separate evaluations, the full pipeline produced a 0.4 percent false-positive rate on 10,000 real-traffic cases and a 17 percent false-negative rate on 52 real overeager actions. Those figures measure different populations and different controls: the approval rate does not measure classifier accuracy, and the classifier result does not measure what a human would have caught. Anthropic cautioned: “Auto mode is not a drop-in replacement for careful human review on high-stakes infrastructure.”

A 2026-05-25 follow-up reported “roughly 93%” again and stated: “The more approvals a user sees, the less attention they pay to each, becoming over time much less diligent in their supervision.” That supports the fatigue finding directly; it does not establish a human-versus-classifier effectiveness comparison. AI Assurance 4.3 (a separate training in this series) named the same fragility in its addendum, in one clause — fatigue makes prompts weak evidence — and stopped there, because building the fix is this training’s job, not the release gate’s.

A 93-percent approval rate is weak evidence of careful review, while the separate 17-percent false-negative rate shows that automation remains fallible; neither number validates the other control — an audit finding avoided by keeping the datasets separate.

MCP’s own warning is the same shape, from the protocol side

MCP — the protocol linking assistants to tools — carries, in its current revision’s authorization design, a warning about its own step-up mechanism: when a server needs a broader scope mid-session, the client has to re-authorize on the union of what it already had plus the new ask, and the specification itself says incremental challenges “force multiple authorization round-trips… and degrades user experience.” A protocol built to ask for consent, written by the people who specified how the asking works, flags that asking too often is itself the failure mode — not a side effect to tolerate, the thing to design against. Fatigue is not a training problem that shows up in an interface; it is a property of how often the interface has to ask, built into the protocol layer as much as the approver’s attention span.

Design ask to be rare and specific

The fix is not a better prompt or a training module for approvers. It is fewer, better-labeled requests to approve, and a way to measure whether that is actually happening. Three pieces:

The wallet. One file holds every token an approver has issued for a given agent’s run — not a chat thread of individual yeses, a single artifact with one entry per approved action, each bound to its own request hash, action, and expiry. The wallet for MU-AI-011 — Meridian’s crew-dispatch agent — carries exactly two tokens across its storm-night run: one for a compensable crew pre-positioning, one for the irreversible dispatch notice — and its own header states the design intent plainly: “one file, several actions… There is exactly ONE token for the dispatch notice, and the notice is two-person — so one token is a refusal waiting to happen.” A wallet with two entries for a nine-call run is what “rare” looks like in receipts, not in a policy.

The TTL ceiling. During guarded execution, approval.max_ttl_seconds is read from policy and passed to token verification; the standalone verifier enforces the same ceiling only when its caller supplies --max-ttl. Either way, an approver cannot be asked for a longer grant than the policy allows, so there is no accumulation of standing yeses to get fatigued about in the first place.

The receipt-derived approval-load query. The same receipt query used to build an incident timeline also answers “how much am I actually asking?” — a stats pass over the storm-night chain reports the decision mix directly: by decision allow=3 ask=1 compensation=1 deny=4 halted=1. One ask among ten receipt decisions — nine calls plus one compensation row — is what a rare, specific gate looks like as a number, and it is the number an operations lead should be watching, not the approve rate on the ones that did get asked. A rising ask count against a flat action volume is the leading indicator that the envelope has drifted, before the approve rate ever has a chance to climb toward 93 percent.

Stop and escalate when approval load rises while action volume stays flat, or when approvers cannot show that they reviewed the plan hash. Pause that action’s unattended path and route the receipts to the named action owner; any later authority change requires Module 6’s signed autonomy-change record, never an envelope edit by the approver on duty.

Key takeaway

Ninety-three percent approved is not a passing grade, and the separate false-negative result is not evidence that a human would have caught the classifier’s misses; both numbers describe a system that asks too often for anyone to keep reading closely. The fix lives in the envelope and the wallet, not in the approver: a small, named set of actions on ask, each bound by a policy-set TTL, counted by a query anyone can run against the receipt chain. The next lesson moves past who approves to who can stop everything at once — the switch that has to live where the agent cannot reach it.

LEADERSHIP DECISION   approval fatigue is treated as a designed
                      control failure, fixed by reducing what asks
                      for approval, never by asking approvers to pay
                      closer attention
PRACTITIONER ACTION   run the receipt-derived approval-load query
                      every review cycle; move any action that asks
                      often and denies rarely into a bounded,
                      receipted allow
SUCCESS MEASURE       the ask count per run stays flat or falls while
                      action volume grows - audit finding avoided
                      before an assessor has to name it