Most teams now agree on the first rule: an AI should not change production without a person deciding. The OWASP Top 10 for LLM applications says it directly: “require a human to approve high-impact actions before they are taken”. The objection that follows is approval fatigue. If people are asked to approve everything, they stop reading and start clicking, and the gate turns into a ritual.
Fatigue is a design problem, and design can solve it without dropping the gate. This piece covers how to keep a human in the loop and still move fast. It is one part of zero-trust AI operations, an open specification: the AI does the legwork, and a person keeps the keys.
Why does approval fatigue happen?
It usually comes from four sources at once.
- Gating the wrong things. Asking for approval on every command, including reads, buries the few decisions that matter.
- Requests nobody can judge quickly. “Restart the service to clear the issue” asks the reviewer to redo the investigation before they can say yes.
- Volume. Ten near-identical requests for ten hosts is ten chances to stop paying attention.
- Approvals that mean little. If the reviewer cannot see exactly what will run, or the content can change after they approve, a careful review is wasted effort.
The MCP security best practices describe the same effect with access scopes: users decline consent dialogs that list too much, and over-broad requests become “normalised”. People adapt to whatever the system asks of them. If it asks for too many decisions, they make worse ones.
Should reads need approval?
No. A read changes nothing, so gating it buys no safety and teaches people to click. The safety for reads comes from scope: the AI reads with the permissions of the person who asked, and its reads should be recorded.
That split matters for speed too. Most of an investigation is reading: configuration, events, recent changes. If reads run straight away, the AI can do the slow part of the work while nobody waits. Only the change at the end needs a person.
What makes a proposal quick to review?
A good proposal answers the reviewer’s questions before they ask them.
- The reason, in a sentence or two.
- The evidence it rests on, from the same investigation, so the reviewer can check the reasoning instead of rebuilding it.
- The exact content that will run, not a summary of it.
- The target, and a risk rating.
- Optional guard rails: preconditions that must hold, conditions to stop, and a rollback plan.
Keep proposals small. One change per proposal is easier to judge than five bundled together, and a rejection then costs one change, not five. Fingerprint the approved content as well. If what runs is guaranteed to be what was approved, the reviewer reads it once and is done.
How do you avoid approving the same thing fifty times?
Two patterns cut the volume without weakening the gate.
Fan-out under one decision. When the same change applies to many hosts, approve it once for the set. Each host should still get its own record of what ran, so the audit trail stays per host.
Schedules for known, recurring work. Patch runs and routine maintenance do not need fresh judgment every week. Let a person with the right role set up a schedule for an approved, stored job, and let it run on its own. The decision is made once, deliberately, by the person accountable for it. The AI should not be able to create or change those schedules.
When is a second factor worth it?
A second factor, such as a push to the approver’s phone, makes each approval deliberate. It also adds friction, so it belongs where the damage it could prevent justifies it: identity, production networks, anything hard to undo. Saying no should never need one. A rejection should always be the cheapest action on the screen.
How do you know the gate is still working?
Watch the gate itself. If approvals pile up for hours, proposals are too big or too many. If nothing is ever rejected or questioned, the gate may have become a rubber stamp. Both show up in a record of who approved what, over which channel, and how long the decision took. Review that record the way you review on-call load. For the enforcement side of the gate, see how to enforce human approval for AI changes.
How GAEZLA does it
- Investigation reads run without approval, inside the operator’s scope. Only the changes the AI asks for are drafted as proposals that wait for an operator.
- A proposal carries its reason, a risk rating, the target and the content. A change to a system must cite live evidence from the same case, and it can declare preconditions, stop conditions and a rollback plan. The proposal is fingerprinted at approval and checked again when it runs.
- One approval can cover the same playbook on many hosts, and each host gets its own signed queue item.
- Playbook schedules are set up by an operator with the schedules role and run the stored, signed playbook without a new approval each run. The AI only reads schedules.
- Unattended routine runs cannot change a system or open a proposal. The one exception is mail a routine’s owner allows it to send, to recipients you allow.
- With multi-factor authentication on approvals, every approval needs a push on the approver’s phone, and rejections never do. It is a Complete-plan feature and off by default.
- Each decision records who approved it, over which channel, the multi-factor result, when, and what ran.
Sources
- OWASP Top 10 for LLM Applications 2025, LLM06: Excessive Agency (mitigation 6, “Require user approval”)
- MCP Security Best Practices, Scope Minimization