Your agent's approval gate is a SHOULD, and nobody read the capitals

In March, Anthropic published a number about its own product that most vendors would have kept in a drawer. Claude Code users approve 93% of permission prompts. The post, written by John Hughes and published on 25 March 2026, names the problem outright: over time that leads to approval fatigue, where people stop paying close attention to what they're approving.

Then they went and built something else. Auto mode delegates the decision to model-based classifiers, which the post describes as a middle ground between manual review and no guardrails. Two months later a second engineering post repeated the 93% and described moving further still, towards sandboxes and virtual machines, on the reasoning that a boundary which does not depend on a human decision at each step is a boundary you can actually rely on.

When the people who built the prompt stop trusting the prompt, that's worth more than any survey. And it raises a question I had assumed was settled, which turns out not to be settled at all.

The human in the loop requirement that was never a requirement

Go to the front page of the MCP specification and read the Tool Safety principles. One of them says: hosts must obtain explicit user consent before invoking any tool.

Now scroll back up to the top of the same page, where the document sets out how to read itself. The key words MUST, SHOULD, MAY and the rest are to be interpreted as described in BCP 14, and the sentence ends with a qualifier that does all the work: when, and only when, they appear in all capitals, as shown here.

That consent sentence is lowercase. So is "users must explicitly consent to and understand all data access and operations". By the specification's own reading rule, neither is a protocol requirement. They're prose. The only capitalised obligation in that entire section lands on implementors, and it is a SHOULD: build robust consent and authorization flows into their applications. The paragraph introducing it says the quiet part out loud, that MCP itself cannot enforce these security principles at the protocol level.

This matters more than a pedantic reading usually would, because the sentence gets quoted with the capitals put back in. Changkun Ou's piece on confirmation fatigue, published 18 February 2026 and the most careful thing I have read on this subject, quotes it as "Hosts MUST obtain explicit user consent before invoking any tool". It's an easy slip and his conclusions survive it, since he goes on to argue the enforcement gap himself. But a field has spent a year arguing about how to implement a requirement that was never written as one.

The tools page is where the real guidance sits, and it is all SHOULD. There should always be a human in the loop with the ability to deny tool invocations. Applications should present confirmation prompts to the user for operations, with no qualifier on which operations. Clients should prompt for user confirmation on sensitive operations, and the word sensitive is never defined anywhere in the document. The one metadata channel that could carry risk information, annotations, comes with its own warning that clients MUST treat annotations as untrusted unless they come from a trusted server.

So the protocol asks you to gate the sensitive operations, declines to say which those are, and tells you not to trust the field where a server might have told you.

The shape of that gap is one I've written about from the other end, in the ZCode upload piece: a consent control placed at the point of capture while the thing that matters happens at the point of use. Here the control sits on the individual call, and the thing that matters is what the calls add up to.

Approval fatigue is not an attention problem you can train away

The instinct, when a gate stops working, is to talk to the people clicking the button. That instinct has been tested and it doesn't hold up.

Raja Parasuraman and Dietrich Manzey published the integrating review of this in Human Factors in 2010, volume 52, pages 381 to 410. Two findings from the abstract are the ones that end the argument. Automation complacency is found in both naive and expert participants and cannot be overcome with simple practice. Automation bias occurs in both naive and expert participants, cannot be prevented by training or instructions, and shows up in teams as well as individuals.

Read those twice if you've ever written "reviewers must read carefully" into a process document. Seniority doesn't fix it. Training doesn't fix it. Putting a second person on it doesn't fix it. It's a property of doing a monitoring task alongside other work, which is the exact situation every approver in your organisation is in.

Medicine has the longest run of data on this, because clinical decision support has been firing alerts at people since the 1990s. Yoo and colleagues, in JMIR Medical Informatics in November 2020, looked at one academic emergency department: 611 physicians, 748,339 medication orders, 102,887 alerts, which works out at 13.75 alerts for every 100 orders. Of those alerts, 65,616 were overridden. That's 63.77%, and the detail worth sitting with is that the authors present it as a good result, comparing it favourably with prior literature reporting override rates between 72.8% and 93%.

Put Anthropic's number next to that range and it lands at the top of it. A permission prompt in a coding tool in 2026 is producing the same compliance behaviour as a drug interaction alert in a hospital in 2010, which shouldn't be surprising and somehow still is.

The approval failure nobody writes about is the gate that hangs

Everything above treats fatigue as a human attention problem, which is how all the existing writing treats it. There's a second failure mode and it has nothing to do with attention. Issue trackers are full of it, and three days before I wrote this Sam Hartley published the rule that answers it, which I'll come back to.

On 8 July 2026, martijnwalraven filed issue 31565 against openai/codex. Running a delegated review, MCP tool calls that require approval simply never happen. The transcript announces the call. The call never reaches the server. The reporter waited 23 minutes on version 0.142.5 and more than 15 on 0.143.0 before killing it by hand, and the 300 second default timeout never fired once. It reproduced five times out of five.

The fix, for anyone who needs to ship today, is in the issue: set the approval mode to approve, and the same command finishes in seconds. Remove the approval requirement from the tool annotations and the hang disappears entirely. The control is the outage.

The underlying cause is a missing handler in the delegated path, and there's a TODO in the source admitting it. But the protocol doesn't bound this either, and that part isn't a bug in anyone's client. The multi round-trip request pattern that 2026-07-28 made mandatory says servers MUST NOT assume that clients will fulfill the input requests or retry the original request, and that servers MAY return the same input-required result on multiple attempts if they want to keep prompting until they have what they need. If the client fails to send what was asked for, the server SHOULD respond with a new input-required result asking again, rather than returning an error. There is a TTL in the pattern, and it lives inside the opaque request state as a replay defence. Nothing anywhere puts a clock on a pending human decision.

So an unanswered approval is specified to be asked again, indefinitely, and it's the client's problem to decide when to stop.

This is the part I recognise from release engineering. A gate with no timeout and no default isn't a gate. It's an incident waiting for the afternoon when the approver is in a meeting. And the second-order effect is the one that actually costs you, because every hang teaches the team that the control is the thing that broke the build. Nobody votes to disable a safety control in a meeting. They disable it at 6pm on a release day, and it stays disabled.

Hartley's rule, from 21 September, is the cleanest statement of the fix I've seen: if I don't answer, the answer is no. He gets there by running a trading bot. I got here by reading the spec. Two of his lines are worth stealing either way. A blocked agent isn't a safe agent, it's a stopped one. And a notification channel that nags gets muted, which is worse than no channel because it still feels like oversight.

What the alert people did about it

Clinical informatics arrived here twenty years ago and the response is worth copying, because it's unglamorous and it worked.

They stopped treating alert burden as a quality of the individual alert and started treating it as a rate. That's why the Yoo paper reports 13.75 alerts per 100 orders instead of a raw count. A rate can be a target, and a target can be argued down over time. Then they tuned, in stages, and published the before and after so the next hospital could compare. And they put a standing multidisciplinary committee in charge of which alerts fire, with its own agenda and its own minutes.

The mapping is direct enough to be boring. Approvals per hundred agent actions is your alert rate. The gate's approval rate belongs on a dashboard beside your build metrics, not in a security review once a quarter. And the body that decides which actions require a human is a change advisory board, which most delivery organisations already have and which currently has no idea this decision exists.

Acceptance criteria for a human in the loop approval gate

The best published guidance names the right measurements and then stops. AWS's Well-Architected Agentic AI Lens says a human reviewer is only as effective as the workload lets them be, tells you to track average review time, approval rate and decision reversal rate, and to alarm on unusually short review times or abnormally high approval rates during periods of high queue volume. It gives no numbers. Neither does anyone else.

So here is a starting set. These are proposed, not measured, and the derivations are in brackets so you can disagree with the arithmetic rather than the vibe.

A sustained approval rate above 90% means the gate has failed, not that the agent is well behaved. (Anthropic measured 93% and treated it as sufficient reason to replace the mechanism. Yoo's emergency department sat at 63.77% and that was considered good.)

A median decision latency shorter than the time it takes to read the action is a failed gate. For a command plus its arguments that's somewhere around two seconds. Track the median and the shape. A mean hides the reflex clicks underneath the handful of decisions somebody actually thought about.

A rejection rate of zero over a month is a finding, not a clean record. Either nothing risky was proposed, which is worth verifying, or nothing is being read.

Run an adversarial sample and publish the catch rate. Inject a known-bad action into the real queue at a low rate, a handful per hundred, and measure how often it is stopped. If you can't state your catch rate, you don't know whether the gate works. You know it exists. This is the one I would put in a definition of done, because every other item on this list describes the control and this one tests it.

Every gate gets a timeout and a written default. Decide now whether an unanswered approval fails open or fails closed, put a clock on it, and make the timeout surface as an error somebody can see. A gate that can silently absorb 23 minutes isn't one your team will keep.

Prior art

The question of which actions deserve a prompt is not open, and pretending otherwise would be dishonest. It has been answered several times and the answers converge on the same three properties: whether the action is reversible, whether it reaches outside your boundary, and whether it changes the agent's own permissions. Changkun Ou argued for classifying by reversibility rather than abstract risk and put a target of 5 to 15% of calls reaching a person. Tian Pan wrote the rubber stamp decay problem twice, in April and June, and named detection signals including near-zero uniform approval latency and a rejection rate of approximately zero, which is where two of my thresholds above come from. Mitchel Lairscey framed prompts as a finite attention budget. AWS wrote the tiered version into its guidance. Emre Turan's August preprint models the inverted U formally and finds that escalating everything increases the harm that gets through.

The availability half is taken too, which I only established after drafting: Hartley on the timeout rule, plus a run of open issues across unrelated agent projects where an unanswered approval blocks work indefinitely, plus at least one MCP server shipping fail-closed gates with a TTL as its whole premise.

So what is actually left is three things. The note about the capitals, which I have not seen anyone make. The observation that the protocol itself specifies indefinite re-asking, so the hang is conformant behaviour, which makes it more than one project's bug. And the acceptance criteria with real numbers behind them, derived from Anthropic's 93% and the emergency department's 63.77%, which is a thin evidence base and still more than anyone else has put on the table.

Marking my confidence

Established. The consent sentences on the specification index are lowercase and the same page limits BCP 14 keywords to all-capital use. The tools page guidance is SHOULD throughout, "sensitive" is undefined, and annotations carry an explicit untrusted warning. The MRTR pattern instructs servers to re-request rather than error and puts its only TTL inside the request state as a replay defence. Codex issue 31565 was opened on 8 July 2026 and reports 23 minutes, a 300 second timeout that never fires, five reproductions out of five, and a fix by disabling approval. Anthropic published 93% on 25 March 2026 and repeated it on 25 May. Parasuraman and Manzey 2010 and Yoo and colleagues 2020 are quoted from their own abstracts and text. All of those were opened rather than taken from coverage.

Inferred. That the hang and the fatigue are the same design defect seen from two ends, and that approval fatigue and clinical alert fatigue are the same phenomenon with different alert text. The numbers line up and the human factors literature covers both, but nobody has run the comparison properly and I'm asserting it from adjacency.

Proposed, not measured. Every threshold in the acceptance criteria section. They are derived from two data points and an argument, which is enough to start a conversation in a team and not enough to cite as a standard.

What would change my mind. Evidence that approval rate and catch rate are uncorrelated, which would make the whole threshold set meaningless. That's testable by anyone running an adversarial sample, and if you run one I'd like to see it.

The specification says, in its own words, that MCP cannot enforce these security principles at the protocol level. That sentence carries more weight than everything in the section around it. The gate is yours. Its timeout, its default, its rate and its number are all yours, and nobody's going to fail your build for getting them wrong.