A team turns on human approval for a new agent because it is the responsible thing to do. In the first week the reviewer gets a dozen prompts a day and reads each one. By the third week there are seventy, almost all of them identical, and the reviewer approves them from a phone between meetings. Then something goes wrong, and the post-incident review asks who approved the action. The answer is a person who approved sixty other things that day in under three seconds each.
That outcome is not a training problem or a discipline problem. It is what the system was designed to produce. The claim of this piece is that past a small number, every additional ask weakens oversight of all the others, and that the way to keep a person meaningfully in the loop is to take most asks away. The strongest objection is that removing an ask removes a control. It does not survive the numbers.
Identical prompts are, quite literally, seen less
Security has run this experiment before. CISA describes MFA fatigue, or push bombing, as an attacker bombarding a user with push notifications until the user approves one by accident or out of annoyance, and notes that a flood of prompts may also convince the user that one of them is legitimate [1]. The approval itself becomes the attack surface. An agent being steered by injected text can produce the same flood: ask, get denied, rephrase, ask again.
Research on browser warnings shows the mechanism from the other side. In a field study of more than 25 million warning impressions, Akhawe and Felt found click-through rates ranging from about a tenth of Firefox's malware and phishing warnings to 70.2% of Chrome's SSL warnings at the time, and concluded that the warning's user experience significantly changes behavior [2]. Anderson and colleagues used fMRI to show that the brain's visual processing response drops sharply after only the second exposure to the same warning, and that warnings which vary their appearance resist that habituation better [3]. Volume and sameness train people to approve without reading, and the design of the prompt, not just its existence, decides whether anyone makes a decision.
Seventy-four asks a day at Calder Freight
Consider an operations agent at Calder Freight, a fictional regional logistics company. It handles shipment exceptions: it reads the shipment database, runs reports in SQL, updates estimated arrival times, emails the customer contact on the shipment, and issues service credits for late deliveries. The team set every tool to ask. By week three, the operations lead was the only approver and was seeing 74 asks a day. The breakdown is illustrative, but its shape is typical.
| Cause of the ask | Asks per day | Approved | What the reviewer actually checked | Consequence |
|---|---|---|---|---|
| SQL reads for reports and lookups | 31 | 100% | Nothing; the query text was too long to read | Read |
| Arrival-time updates on one shipment | 18 | 100% | Whether the shipment ID looked plausible | Reversible change |
| Email to the shipment's customer contact | 12 | 99% | Sometimes the first line of the message | Outbound |
| Service credits under $50 | 9 | 100% | The amount, when it was visible | Money |
| Everything else: deletes, new recipients, larger credits | 4 | 75% | Usually read carefully, when noticed | Irreversible, outbound, money |
Forty-nine of the 74 daily asks were reads and reversible changes that the reviewer approved every time without being able to check anything useful. The four a day that carried real risk were mixed in with them, looking the same. Four design choices produced the flood, and they produce nearly every flood:
- Asks were keyed to tool names, not effects. A rule that says run_sql asks will ask for every SELECT the agent runs to answer a question, which is most of its day.
- The agent held tools it did not need. OWASP lists excessive functionality and excessive permissions alongside excessive autonomy [4]; every unnecessary tool is a source of asks that a smaller tool list removes entirely.
- Approvals did not accumulate. The reviewer approved the same kind of call on Monday, Tuesday and Wednesday, and the system learned nothing from it.
- The prompt showed a transcript instead of a decision. When the reviewer has to read a page of model output to find the recipient, they stop looking for the recipient.
The objection: every ask you remove is a control you remove
Stated at full strength: an approval is the visible proof that a person oversaw the agent, and it is the first thing a post-incident review asks for. OWASP's own Excessive Agency entry recommends human-in-the-loop control [4]. An outbound email approved 300 times without incident is still an outbound email, and the 301st might be the one that matters. Removing asks trades a known control for an argument about attention.
Read OWASP's recommendation closely, though: human-in-the-loop control to approve high-impact actions before they are taken [4]. The qualifier is the point. At Calder, removing the 49 reads and reversible changes did not remove oversight of anything a person could judge; it is what made oversight of the remaining four possible. The objection is right about one thing, and the design below keeps it: an outbound or money cause with a clean history becomes a candidate for a scoped grant reviewed by a named owner, never for silent removal. The usual alternative, adding a second approver to fix rubber-stamping, gives you two fatigued reviewers instead of one. Reduce volume first, and keep two approvers for privileged actions.
Ask by what the call does, read from its arguments
Consequence is the worst realistic outcome of one call, judged by reversibility and reach. A workable scale has five tiers: reads, reversible changes, irreversible changes, outbound or external actions, and money or administrative changes. Reads and reversible changes run. Irreversible changes ask in production. Outbound messages, payments and admin changes always ask unless a named, expiring exception says otherwise.
Classify the call by what it does, including its arguments. The same run_sql tool is a read when it runs SELECT, an irreversible change when it runs DELETE, and an administrative change when it runs GRANT. A send_email call to the contact on file is a different decision from the same call to a new external address. The classifier should only raise a call's tier based on what it finds in the arguments, never lower it because the agent or the client claims the call is harmless. At Calder this removed the 31 SQL reads and the 18 arrival-time updates from the inbox on the first day, and the agent still could not delete a shipment record or email a new address without a person.
An always-approved ask is an unwritten policy; write it down
When the same high-tier ask is approved every day for the same reason, it is really a standing policy that nobody has written down. Write it as a grant with explicit limits, held in the system that executes the action, not in the prompt: one agent, one operation on one system, which resources, per-call and per-day ceilings, an owner and an expiry.
Calder's finance controller accepted one such grant: service credits under $50, only to the account that owns the delayed shipment, capped at a daily total enforced by the billing system, renewed every 90 days. That removed nine asks a day. Anything above the ceiling, to a different account or past the daily cap still asks. Customer emails stayed as asks because they are outbound, so the team made those twelve a day fast to decide instead. A grant without an expiry is how, six months later, nobody remembers why the agent can credit accounts.
Reads and reversible changes stopped asking, and one scoped grant covered small credits. The sixteen asks left are outbound emails and the rare consequential actions, which is the work a reviewer can actually judge. Numbers are illustrative.
Remember the call, not the tool
Approve-and-remember is the most useful and the most dangerous button on an approval screen. Remembering the tool name turns one approval of a harmless call into permission for every future call to that tool, including the destructive ones. Remember a scope instead: the same tool on the same server, the same operation, the same target class, at or below the consequence tier of the call the person approved.
Show the reviewer what the remembered scope never covers before they click; for a remembered email approval, that includes new recipients, attachments and any recipient outside the customer's own domain. Build those conditions on the server from the approved call itself, and let the client choose only between similar calls and this call only. Let remembered approvals expire, and record who created each one. Plans are the other honest way to cut volume: a person approves an agent's stated steps once for that session, with each step's maximum tier visible, and a plan never covers another session, a target it did not name, or a step that would otherwise be blocked.
Ten seconds, five facts, one screen
Ten seconds is a design target, not a measured norm: enough to read four short lines and press a button. If a reviewer needs longer to find the facts that matter, the screen is asking them to do the system's work. Calder rebuilt the email approval around five elements, in a fixed order.
- The effect in plain words: send one email to the customer contact on shipment CF-20418. Not the tool name, and not the model's summary of its own intent.
- The exact target, with what the system already checked: the recipient address and a mark showing it matches the contact on file.
- Why it is asking: the rule or tier that caused the ask, such as outbound messages always ask.
- What is different from usual: a new recipient, an attachment, an amount above the agent's normal range, or a first call to a new system. When nothing is different, say so.
- The agent's stated reason, labeled as the agent's words. It is untrusted text, and an injected instruction will often arrive dressed as a justification.
The effect, target, cause and differences come first, and the agent's own explanation is fenced off as untrusted. Approve-similar shows what it never covers, so a quick decision stays a narrow one.
Borrow two ideas from the warning research. Make high-tier asks look different from routine ones, because habituation is driven by sameness [3]; a payment request should not share a layout and color with an arrival-time change. And for the highest tiers, make the reviewer engage with a specific detail. CISA recommends number matching for push MFA because it forces the user to enter a number from the login screen rather than tap approve [1]; the agent equivalent is confirming the amount or the recipient domain on a payment or an external send.
Bind the approval to the exact call shown. If the arguments change between approval and execution, the approval should not apply. The OWASP Authorization Cheat Sheet says permission should be validated correctly on every request [5]; an approval is one input to that check at execution time, not a substitute for it. Approvals given in chat threads or email are bound to nothing and cannot be audited against what ran.
Count asks by cause, and act on the count monthly
A cause is the specific rule, tier or tool list entry that produced an ask. Total inbox volume tells you something is wrong; asks by cause tell you what to change. Review them monthly with each agent's owner.
| Signal over 30 days | What it usually means | Action |
|---|---|---|
| A cause approved every time, at a read or reversible tier | The rule asks about things that cannot do much harm | Stop asking; let the tier decide |
| A cause approved every time, at a high tier | There is an unwritten standing policy | Write a scoped, expiring grant with ceilings, or keep asking and make the screen faster |
| A cause denied every time | The agent is trying to do something it should never do | Block it outright and fix the agent or its tools |
| Median decision time falling while volume rises | Reviewers have started rubber-stamping | Cut volume before anything else; review the last month's high-tier approvals |
| Repeated denied asks in one session | The agent may be steered, or stuck in a loop | Stop the session after a few denials instead of asking again |
What Intertrace does with an ask
Intertrace reads what each call does from its name and arguments and assigns one of five consequence tiers; an agent's role decides what runs, what asks in production and what always asks, and outbound messages, payments and admin changes always ask. Approvals land in one inbox, approve-and-remember is scoped to calls like the approved one, pre-approvals carry a maximum tier, and plan approvals cover a single agent session. Exceptions are named, agent-scoped and expire. Proposed access or policy changes can be replayed against the last 30 days of real decisions, so you can see which asks a change would remove before you ship it.
Start with one month of one agent's approvals
Export a month of approvals for your busiest agent and group them by cause. Every cause at a read or reversible tier that was approved every time is an ask to delete this week. Every high-tier cause approved every time is a grant to write, with ceilings, an owner and an expiry. Then show five real approval screens to a colleague who has never seen the agent. If they cannot name the effect and the target of each one in ten seconds, the screen is the next thing to fix.
