Human approval gates in agent workflows: which actions need one

What it is

A gate is a point in the agent loop where a proposed action (a tool call with its arguments) is shown to a person, who allows, denies or edits it before it executes. The Model Context Protocol specification says there should always be a human in the loop with the ability to deny tool invocations and that applications should present confirmation prompts for operations. OWASP's Excessive Agency entry traces the risk to excessive functionality, permissions and autonomy, and lists requiring user approval for high-impact actions among the mitigations. Products implement gates as per-tool policies; Anthropic's managed-agents documentation, for example, describes always_allow, always_ask and an auto mode in which the server evaluates each call and runs, denies or pauses it, with the warning that auto is not a human checkpoint.

Why it matters

Gating everything makes the agent slower than doing the task by hand and trains the person to click "allow" without reading. Gating nothing hands an agent that can be steered by content it reads the power to send, pay, delete and deploy. The gate is where autonomy and consequence are traded off explicitly.

How to apply

• Classify each tool by consequence: read-only and reversible actions run without a gate; irreversible ones (delete, send, publish, pay, merge), externally visible ones, and anything that changes credentials or permissions get one.
• Gate on arguments, not only on tool names: a shell tool may be free for listing and gated for removal; a payment tool may be free under an amount and gated above it.
• Show the exact call: tool, arguments, target and a one-line reason from the agent. A gate that shows only "run command?" is decoration.
• Make denial informative: return it to the agent as a tool result so it can replan instead of retrying the same call.
• Log every decision with who approved and what ran; review the log for gates that are always approved (candidates for automation) and for denials (candidates for a tighter tool).
• Prefer removing a capability over gating it if the task rarely needs it.

Pitfalls

Approval fatigue. Gates that an equivalent tool bypasses (a gated delete next to an ungated shell). Batching many actions under one approval. Treating one approval as consent for the rest of the session.

Reading the approval log

A gate that is always approved is not thereby a candidate for automation. Gates on rare, irreversible actions are approved almost every time because the agent proposes them correctly almost every time; the approval rate reflects the base rate of bad proposals, not the gate's value. Ask two questions of the log instead. Is the worst call this gate could pass acceptable to run unattended? If not, the gate stays whatever its history. Is the gate firing on calls that cannot carry that worst case? If so, narrow it to the argument pattern that does (the path, the recipient, the amount) rather than removing it. Denials remain the strongest signal for a tool that is too broad.