TL;DR: Approval is a finite attention budget, not a wall that gets thicker with every prompt. The number of prompts is a multiplication — intents times resources touched times retry rounds — and all three factors are on the system side, not the approver's. Flood the approver and each prompt gets less review, until approving means "make it stop." That is exactly how attackers broke into Uber. The fix is not a more careful human. It is request coalescing: one intent, one prompt, ever — and zero prompts on paths already authorized.
Last week, one account-recovery task in my own operation generated fifty-four approval prompts. Not fifty-four decisions. One decision, shattered fifty-four ways: the page touched dozens of resources, the worker treated each pending prompt as a failure, retried, and each retry minted fresh prompts. A few days earlier the same structure, at smaller scale, had produced eleven prompts in a single day. Nothing about the underlying intent was dangerous. The danger was the shape of the asking.
Here is the arithmetic nobody budgets for. Prompts per window equals intents, times resources per intent, times retry rounds. The approver controls none of those three numbers. The system controls all of them. And review quality is not constant across the sequence: it is the approver's attention divided by the number of prompts competing for it. Double the prompts and you have not doubled the safety. You have halved the review each one receives.
The science settled this decades ago — in hospitals
The clinical literature on alert fatigue, summarized by the AHRQ patient-safety primer, is blunt. When the vast majority of alerts carry no consequence, clinicians learn to override the vast majority of them — including alerts marked critical, warning of serious harm. Fatigue grows with exposure; the longer the flood runs, the worse it gets. A system built to increase safety ends up, in the primer's own framing, paradoxically increasing the chance of harm. Aviation is held up as the counterexample: cockpits are engineered to surface only high-consequence alerts, precisely so the pilot's attention survives to meet them.
Attackers read the same literature. CISA has a name for the weaponized version — MFA fatigue, or push bombing: flood a user with approval requests until one gets accepted. Uber's own security update tells the story in the attacker's favor: repeated login attempts each triggered an approval request; access was, in Uber's words, initially blocked — and then the contractor eventually accepted one. The defender did not fail to care. The defender was worn down. And note CISA's remedy: not training, not exhortation, but changing the factor — number matching, phishing-resistant MFA — so that a blind tap physically cannot approve. Serious systems fix the mechanism, not the human.
So when my own automation retries its way to fifty-four prompts, it is executing the attacker's sequence against the one approver I have. The only missing step is the phone call impersonating IT.
Treat the approver like a backend: coalesce, cache, budget
Distributed systems solved this problem for machines, and the solutions translate directly. Request coalescing — Go's singleflight is the canonical version — keeps an in-flight table keyed by the request: a hundred concurrent calls with the same key trigger one execution, and the rest wait and share its result. Authorization caching is the second piece: a path already granted should produce zero prompts, the way a cache hit produces zero origin fetches. A retry budget is the third: retries are the classic amplifier that keeps a system stuck in an overloaded state long after the original trigger is gone, so each intent gets a small, hard allowance — one prompt in flight, no automatic re-asking — and changing workers or channels does not reset the count.
Applied to approvals, that became four rules in my operation. One intent, identified by intent plus target plus action, may have exactly one prompt in flight; everything else waits on it. Already-authorized paths never prompt. Only high-consequence, irreversible actions may interrupt on their own — in my case, a payment above a fixed threshold always travels alone, never batched, never diluted, because the entire point of cutting the flood is to return full attention to the few prompts that deserve it. Everything low-consequence is batched into a single reviewable list, each item still independently approvable. And externally, the rule runs in reverse: if approval or verification requests suddenly arrive in a burst, treat the burst itself as the attack signal — approve none of them, and verify through a channel you already trust.
Count your prompts the way you count your errors. If one intent can become fifty-four questions, your approval step is not a control. It is a denial-of-service attack you are running on the only person who can say no.
— Jiahui Miao, founder of vertciti, building a personal AI operating system for one.
