Human Approval Fatigue in Agentic Systems
An AI agent drafts an email and asks a user to approve it. Minutes later, it requests permission to update a customer record, download a file, query a database, and create a support ticket.
Each request may be reasonable alone, but when they start to build up, they can become a stream of interruptions that receives less attention over time. Reviewers may begin approving familiar prompts automatically, especially when requests are repetitive or vague. This is approval fatigue. Repetition can create habituation, causing people to pay less attention.
Why More Approval Does Not Always Mean More Safety
Requiring approval for every tool call can make an agent appear tightly controlled. In practice, routine prompts compete for the same attention as actions that could expose private data, spend money, or modify production systems.
After approving dozens of ordinary operations, a reviewer may give the next request only a glance. Prompts such as “Allow agent to continue?” make the problem worse because they say little about what will happen. Urgency may also encourage someone to approve a request simply to remove the interruption. NIST’s Generative AI Profile identifies automation bias and over-reliance as risks that can arise from interactions with generative AI systems.
Ask for Approval When the Risk Justifies It
Approval requirements should reflect the action's risk, including the target system, data involved, monetary value, user permissions, and whether the action can be reversed. An agent might read a public document automatically but require approval before sending information outside the organization, deleting a record, running code in production, transferring money, changing permissions, or acting on someone else’s behalf.
The decision should come from deterministic policy logic using trusted application state. A model can describe the action, but it should not decide whether its own request deserves review. OWASP describes excessive agency as a risk that occurs when an AI system receives more functionality, permissions, or autonomy than it needs. Its guidance recommends limiting tools and requiring approval for high-impact actions.
Risk tiers can reduce interruptions. Low-risk operations may run automatically within strict limits, while unusual or high-risk actions go to an authorized reviewer.
Show the Reviewer Exactly What Will Happen
An approval screen should identify the operation, target, affected data, authority being used, expected effect, and whether the action can be reversed. “Send an email” is not enough. The reviewer needs to see the recipient, message, attachments, and classification of any shared data.
The interface should separate the agent’s explanation from verified facts. An agent may claim that a recipient is authorized even though a policy service has not confirmed it. Presenting both statements alike can create false confidence.
Approval should remain tied to what the reviewer saw. If a recipient, payment amount, attachment, or command changes, the earlier approval should no longer apply. Before execution, the runtime should confirm that the approval remains valid, the reviewer had authority to grant it, and current policy permits the action. Approval should never override mandatory access restrictions.
Reduce Fatigue and Measure the Results
Similar low-risk requests can sometimes be grouped, but reviewers should still be able to inspect or reject individual actions. Standing authorization can also reduce interruptions. A user might allow an agent to schedule internal meetings for one hour on a specific calendar. That permission should have narrow limits, a clear expiration, and an easy way to revoke it.
Requests should go to people who understand the decision. A manager may approve spending, a security reviewer may handle sensitive data transfers, and a system owner may authorize production changes. Sensitive workflows may require more than one approval, although using this control too broadly can recreate the fatigue problem.
Teams should track response times, rejection rates, canceled actions, policy violations caught, and approvals granted almost immediately. A high approval rate does not prove the requests were safe. Periodic reviews and simulated incidents can test whether people notice changed recipients, unusual transfers, elevated permissions, or misleading explanations.
Human approval can reduce the risks created by capable agents, but a confirmation button alone is not meaningful oversight. The process should protect the reviewer’s attention, clearly present the decision, and preserve the connection between what was approved and what the system eventually does.