The uncomfortable starting point
Let us start with the newest and hardest piece of data, because it sets up everything that follows.
In a single-blind, randomised clinical trial, 44 doctors worked through six clinical cases in 75 minutes. One group got accurate AI recommendations, the other got deliberately wrong ones in three cases out of six. Consulting the AI was voluntary, and every participant had been through twenty hours of AI literacy training beforehand.
| Measure | With accurate recommendations | With wrong recommendations | Adjusted difference |
|---|---|---|---|
| Diagnostic reasoning accuracy | 84.9% | 73.3% | −14.0 percentage points |
| Top-ranked diagnosis | 90.5% | 76.1% | −18.3 percentage points |
Both differences are strongly significant. The third column is the study's adjusted difference with a confidence interval (between −8.3 and −19.7, and between −26.6 and −10.0 points respectively), not the subtraction of the two columns.
Why this is the cornerstone of the article: the participants were not laypeople, and they had been specifically prepared for the risks of AI. It happened anyway. Preparing the human who approves is not enough on its own.
And training does not fix it
This is not a new phenomenon, only a new context for it. The standard review of the field — with more than twelve hundred references — says three things about it:
- complacency shows up when several tasks are competing for attention at the same time, which is exactly the real workplace situation;
- it affects experienced and novice users alike, and practice does not remove it;
- it resists training interventions, both for individuals and for teams.
There are two kinds of error inside it, and both deserve a name: the omission error (the system did not flag it and the human did not spot it either) and the commission error (the system said something wrong and the human went along with it).
How many approvals before approval stops existing?
For agents specifically there is no measured data on this. There is, however, an almost perfect analogy with hard numbers: clinical alert fatigue.
According to a systematic review covering 23 studies, the override rate for system alerts ranged from 46.2% to 96.2% — and only part of those overrides were professionally justified (between 29% and 100%, depending on the type).
Read the upper figure one more time: 96.2%.
Where twenty-four alerts out of twenty-five get clicked away, the approval point has stopped existing — it survives only in the log. On paper everything is fine: there is a control, there is an approval, there is a trail. In practice there is not.
This is the strongest argument for having few approval points but real ones. The question is not how many places you put them. It is whether the ones you have actually get looked at.
Where do the rules require it?
Four sources, from four levels.
The legislation. Article 14 of the EU AI Act requires human oversight for high-risk systems: they have to be designed so that natural persons can effectively oversee them while they are in use. The person overseeing must be able to disregard the output, override it and stop the system.
And there is one point that lands directly here: the regulation names automation bias explicitly — the person carrying out the oversight has to be aware of that risk.
(Important dates: the obligations for high-risk systems under Annex III apply from 2 December 2027; the transparency rules, however, have been in force since 2 August 2026, and the compliance deadline for marking synthetic content is 2 December 2026.)
The protocol. The standard used for wiring up tools states that the host must obtain explicit user consent before invoking any tool, and that the user must understand what the tool does. The same document adds that it cannot enforce this at the protocol level.
The industry risk list. The risk list for large language models has a separate entry for excessive agency, with three causes: too much functionality, too many permissions, too much autonomy. One of its eight recommendations: require human approval for high-impact actions. And there is an entry that names, as a risk in its own right, the fact that the human trusts the agent too much.
The developer tool. Practical frameworks give you an approval switch at tool level: either always ask for approval, or let a function decide call by call. There is also a "sticky" option, which makes the same decision apply to every further call — and that is precisely how complacency gets institutionalised. A double-edged tool: it is convenient, and that is exactly what turns the control into a formality.
What do they actually do in practice?
According to a 2026 survey of more than 1,300 professionals, most teams do one of two things: they either give the agent read-only access, or they require human approval for writes and deletes. Very few let the agent read, write and delete freely.
Large enterprises are more cautious: they lean heavily towards read-only permissions.
And one instructive number from the same place: as the main obstacle to going into production they picked neither cost nor security, but the quality of the output — rating it more than twice as serious as any other factor.
Three places where approval really protects
All three follow from the above, and all three go back to one principle: you need approval where the mistake cannot be undone.
1. IRREVERSIBLE OPERATION
Deleting, paying, overwriting live data, placing an
order. Anything with no "back" button after it.
2. OUTBOUND COMMUNICATION
Email, message, publishing, a customer reply. Here it
is not the system that gets damaged but the trust —
and that cannot be restored from a backup.
3. PERMISSION OR SCOPE EXPANSION
Wiring in a new tool, new access, a new rule.
This is the step that changes all the other ones too.
The third is the least obvious and the most important. If the agent can expand its own scope, then every other limit you have is temporary.
Where it only slows you down
And here is the other side, because an approval in the wrong place is not just expensive, it actively harms — the 96% override rate above is exactly what it produces.
- Reading, searching, querying. If nothing changes, there is nothing to approve.
- A draft that will not go out by itself anyway. You read the draft when you use it — no need to do it twice.
- Internal notes, tags, categorisation. Reversible, cheap, frequent.
- Versioned changes. If there is history and a rollback, the approval can be replaced by the rollback button.
- Repetitive, identical operations. These are exactly where the mechanical "yes" takes hold — and from then on your other approvals degrade as well.
That last point matters most. Approval points are not independent of each other: if a person clicks yes fifty times a day, then they will click yes on the fifty-first too — including when that one is the important one.
What does it cost?
On how much a single approval point slows a process down, there is no direct measurement. The closest analogy is instructive though — and contradictory in itself.
In a randomised experiment in July 2025, with 16 experienced developers and 246 tasks, randomised at task level, using AI increased completion time by 19%. The same people had expected a 24% speed-up beforehand, and still believed in a 20% speed-up afterwards.
The same group repeated it in February 2026 on a much larger sample — 57 developers, 143 repos, more than 800 tasks: an 18% speed-up on the subsample of original participants, and 4% for the newly recruited ones.
Same research group, same method, opposite sign seven months apart — and they themselves warn that the second one has to be read carefully: 30–50% of the developers did not submit tasks they would not have wanted to do without AI, which is a serious selection bias.
The lesson for approvals: the slow-down is a real cost, but measuring it is hard, and self-assessment on this subject is demonstrably poor. Which is why it is worth counting approval points rather than feeling them.
Common misconceptions
- "If a trained person approves it, it is safe." The participants of the trial cited above had twenty hours of training, and still dropped 14 percentage points when the recommendation was wrong.
- "More approval points, more safety." The opposite. Lots of questions breed a mechanical yes, and the mechanical yes will be there at the important point too.
- "They will get used to it and get better at it." The reviews say the phenomenon hits experienced users too, and resists training.
- "There is an approval, therefore there is control." If the override rate is 96%, the control exists in the log, not in reality.
- "The agent only reads, no approval needed." Until it can wire in a new tool or acquire a permission. That step overrides everything else.
- "Approval slows us down, so it is expensive." It may be — but there is no measurement for that, and the best proxy data on the same question flipped sign within seven months.
What to take away
Approval is not a question of quantity but of placement.
Put it in three places: irreversible operations, outbound communication, scope expansion. Those are the three where the mistake cannot be repaired afterwards.
Take it out everywhere else. Not for convenience — but because every superfluous approval degrades the quality of the ones that remain.
And one metric worth tracking: what share of them gets approved. If that stays above 95%, what you have is not a control but a ritual. In that case either the point is in the wrong place, or you have too many of them.
How much access the agent should have at all — and why scope is the most important limit — is what the least-privilege agent post covers, with documented incidents; the link between step count and reliability is worked through in the agent reliability math post, with the numbers.