Anyone who has processed documents in batch mode knows what a glazed-over approval is. They just never had a name for it — and now it has arrived in a system where the click can move money.
I did not learn this from agents. I learned it from ERP.
If you have ever run batch processing in an enterprise system, you know the shape of it. The system asks you to confirm every step. You read the first few dialogs. Then you start recognising them by outline rather than content. An hour in, you are clicking yes before the text finishes rendering — not because you are careless, but because fifty previous prompts carried no information, so the fifty-first probably carries none either.
And usually it doesn't. Until, occasionally, it does.
So when the phrase glazed-over approvals turned up in a discussion of human-in-the-loop controls for AI agents, there was nothing to work out. It is the same mechanism, moved into a new system and run at a much higher clock speed.
That matters more than it sounds, because most of the current conversation treats this as a novel property of agents. It isn't. It is a property of any interface that asks for confirmation repeatedly — ERP, banking systems, admin consoles, installers, OS permission dialogs. Wherever the same request returns often enough, it stops being a question and becomes part of the background that the eye passes through.
What's new is only the rate. A coding assistant can generate more approval requests in an hour than a batch process generates in a working day. The threshold at which a person stops reading gets crossed sooner and less visibly.
Start at the end, with the artefact that survives
Something has gone wrong. An agent did what it should not have — wrote to the wrong place, sent the wrong thing, moved money that should have stayed. Someone is reconstructing what happened, and the reconstruction produces a line:
14:32:07 — action approved by user@company
That line carries a great deal of weight. It establishes that the system did not act alone, that a person was present, was shown the operation, and said yes. Whatever else failed, oversight worked as designed.
Except the person does not remember the decision. Not because they were negligent — because there was no decision to remember. It was the fortieth approval that day, it looked like the thirty-nine before it, and it was gone in under a second.
The log is not wrong. It records exactly what happened: a click. It just describes it in language reserved for something that did not happen: a judgement.
Two ways a checkpoint stops working
I wrote earlier about approval dialogs that lie — windows showing a harmless label while the agent writes somewhere else entirely. The lesson there was information parity: at the moment of decision, the human has to see what the agent already knows. Resolve the path before rendering. Show the consequence, not the intent.
That fix is real and it works. It also exposes the second failure, which the first was hiding.
Once the window tells the truth, the question is no longer whether the human could have known. It is whether they looked. And for any system that asks often enough, the honest answer is eventually no.
The first failure says couldn't have known. The second says could have, didn't look. Only the first has a technical fix. The second gets worse the better your window becomes, because a good window catches more edge cases, which means it fires more often, which means it means less.
The person clicking is reasoning correctly
This is where most discussions of the problem go wrong.
Take someone who has approved two hundred operations over a week. One hundred and ninety-nine were routine. What should they conclude about the two hundredth?
That it is probably routine. And they would be right — not lazy, not negligent, right. Given the evidence available to them, treating the next prompt as low-risk is sound inference. They learned precisely what the system taught them.
Automation bias — the tendency to accept a system's output without independent verification — is documented across decades of human factors research. Its central finding is uncomfortable for anyone designing oversight: the reliability of the system is itself the risk factor. The better the automation performs, the less scrutiny it receives, and the more consequential the one case where it fails.
Alert fatigue in hospital systems taught the same lesson with a sharper edge. Drug interaction warnings were, individually, correct. Clinicians dismissed them anyway — including the ones that mattered. The problem was never the quality of the alerts. It was the number.
An approval is a signal
Here is the part that inverts the standard advice.
A consent prompt is a signal. Its value comes from how rarely it fires, not from the fact that it exists. A checkpoint that triggers on every operation communicates exactly what no checkpoint communicates — nothing. Its false positive rate approaches one, and humans are very good at learning to ignore signals like that.
Which means the reflex after an incident — add more approval gates — can make a system less safe while making it look safer. More gates raise the number of prompts and lower the value of each. The audit improves. The oversight degrades.
The trade underneath is one almost nobody states out loud: you can supervise a few things genuinely, or everything theatrically. Most organisations picked the second without knowing there was a choice.
What the record actually records
Which brings us back to the log line.
When oversight is real, an approval is evidence that someone weighed a specific action and accepted it. When oversight has gone glassy, the same log line is produced by a reflex. The artefact is identical. What it purports to represent is not.
This has a consequence beyond engineering. An approval gate that nobody reads does not make the system safer. It makes the outcome attributable. Risk has not been reduced — it has been moved, from the organisation that deployed the agent to the individual who clicked.
And the individual clicked because the system trained them to. That is the part worth sitting with: we build mechanisms that manufacture accountability out of behaviour we caused, and then we point at the record.
The failure here is not a bug in the dialog. It is a governance pattern that produces a defensible paper trail and calls it control.
What follows, practically
If the value of an approval comes from scarcity, designing oversight means spending scarcity carefully.
Gate boundaries, not operations. Asking about every file write produces a hundred meaningless prompts. Asking when a write leaves the working directory produces one that means something.
Use budgets where actions are countable. Let the agent run to a limit and ask when the limit is reached — one question instead of a hundred.
Escalate by irreversibility, not by operation type. Anything you can undo with a single command probably deserves a log entry rather than a gate. Reserve interruption for what cannot be taken back.
Make rare approvals look rare. If the serious prompt is visually identical to the routine one, it will be processed by the same reflex. It has to break the pattern, not just carry different text.
And measure the count. If your agent generates more approval requests this month than last, that is a security regression even if every individual request is correct. Track the rejection rate too: if it approaches zero, either you are asking about things that need no asking, or people have stopped reading. Both call for the same response.
What I do not know
Two things this argument does not settle.
Where the threshold sits. There is presumably a number of daily prompts below which attention holds and above which it collapses, and it almost certainly varies by person, by task, and by whatever else is competing for the same attention. I have not seen it measured for agent workflows, and I would not trust a figure produced by reasoning rather than observation.
And whether the trade is acceptable. Fewer gates means the agent acts unsupervised more of the time. That is a real reduction in oversight, not a clever way of avoiding one. The argument here is that it buys genuine attention on the few things that matter, in exchange for none on the many that do not. Whether that is the right exchange depends on what the agent can reach — which is a question about permissions, not about dialogs.
What I am confident about is narrower. Batch processing taught this lesson decades ago and the software industry did not learn it; it simply lived with clicking through confirmations, because the worst case was a document posted to the wrong period. The worst case is no longer that.
If you want to know whether your oversight is real, don't count the gates. Count how often somebody says no.
The design side of this — how to build approval that survives repetition — is covered separately on webflux.pl, along with a Polish-language glossary entry for the phenomenon. The four mechanisms by which approval controls are bypassed, including fatigue exploitation, are catalogued in MCP-38, a threat taxonomy for Model Context Protocol systems.
