A human approval gate pauses an AI agent before a risky action and asks a person to approve the exact thing it is about to do. It works when you gate by reversibility and impact, show the real parameters, and bind the approval to that one action. It fails when it becomes a wall of generic confirm buttons.
Why gate at all?
OWASP names excessive autonomy as one root cause of agent harm, with its example being an extension that deletes a user's documents without any confirmation. The same page lists excessive functionality and excessive permissions as the other two causes. A gate addresses autonomy; it does not fix the other two, so cut permissions as well.
The gate must also hold when the model is wrong or manipulated. OWASP notes the trigger can be hallucination, prompt injection, or a compromised peer agent. A control that depends on the model behaving cannot be the control.
Which actions need a gate?
Sort every tool the agent has by two questions: can the effect be undone, and how far does it reach?
- Read only, low reach: no gate. Log it.
- Reversible write, narrow reach: log, maybe sample review. An example is editing a draft in a sandbox.
- Irreversible or wide reach: gate. Deleting records, sending external messages, moving money, changing permissions, deploying to production, merging code.
A constructed example: a support agent can look up orders (no gate), add an internal note (log), issue a refund up to a small limit (gate above the limit), and delete a customer account (always gate, with a second approver).
What makes an approval meaningful?
The approver must see the action, not the agent's description of it. Show the tool name, the target, the exact arguments and the data affected, in plain words. A message such as "agent wants to continue" teaches people to click yes.
Bind the approval to that action and a short time window. If the agent changes the arguments after approval, the approval is void. Record who approved, what they saw and when.
Pick the approver by authority, not availability. The person who can approve a refund is not necessarily the person who can approve a permissions change. Prevent self-approval where the requester and approver would be the same person.
How do you avoid approval fatigue?
Too many gates train people to rubber stamp. Keep the gated set small and well chosen, use thresholds so low-risk cases pass, and batch similar requests when each can be reviewed individually. Track the approval rate. A gate that approves 100 percent for months is either guarding nothing or being ignored, and both are worth a look.
What about speed?
Define what happens while waiting: the agent should pause or move to other work, not retry in a loop or look for a side route. Set an expiry so stale requests do not pile up. For out-of-hours risks, name an escalation path, or default to deny.
How to check or apply this
- List every tool and mark it reversible or not, narrow or wide.
- Gate the irreversible and wide set, and leave the rest logged.
- Show approvers the real parameters in plain language.
- Bind approvals to one action and a time limit.
- Forbid self-approval and record approvals.
- Review approval rates monthly and tune thresholds.
- Test that the gate cannot be bypassed by a second tool with the same effect.
Safeguard's autonomous remediation is an example of the pattern: fix pull requests are off by default, so a person turns on that action and reviews the result.
Quick check
Is a confirmation prompt in the chat enough?
Only if it shows the exact action and is enforced outside the model. A prompt the model can skip is advice, not a control.
Should every tool call need approval?
No. Gate irreversible and wide-reach actions, and log the rest, or approvals become noise.
Sources
Last reviewed: 18 October 2026.
