Human-in-the-loop approval policies that people do not learn to ignore

The Model Context Protocol's tools specification says that, for trust and safety, there SHOULD always be a human in the loop with the ability to deny tool invocations. That is sound advice, and it is easy to implement badly. The simplest implementation (a confirmation dialog on every call) produces a predictable result: after the first few dozen harmless prompts, people stop reading them. The one prompt that mattered looks exactly like the ones before it and gets the same reflexive click.

This is approval fatigue, the agent version of alert fatigue. It gets worse as agents get more capable, because a capable agent makes more calls per task. A coding agent can easily run dozens of shell commands to fix one bug; in code mode a single step can fire many tool calls that no one sees individually.

The fix is not to remove the human. It is to spend the human's attention where it changes outcomes.

A useful policy splits actions into three bands instead of "allowed" and "needs approval":

1. Clearly fine: read-only or low-impact actions that match what the user asked. Run them.
2. Uncertain or high-impact: the model is unsure, the arguments are not clearly grounded in the request, or the action is production-mutating. Ask a human.
3. Clearly unacceptable: injected instructions, exfiltration of secrets, actions far outside the task. Block them, and tell the agent why so it can recover.

MCP Guard's verdict follows this shape: allow, ask or block. Its approval_policy head predicts which of auto_approve, require_human and reject a careful reviewer would choose, and the default verdict combines it with the overall risk score: block if P(unsafe) is at least 0.8 or the policy says reject; ask if P(unsafe) is at least 0.3, the policy says require_human, or the arguments look ungrounded (args_grounded below 0.5); otherwise allow.

The value is in band 1. Every action that can safely skip the human is one less prompt competing for attention, which makes band 2 prompts rarer and more likely to be read.

When you do ask, make the question easy to answer well:

• Show the reason. The guard returns reasons and per-head scores. "Sends customer data to an external address not mentioned in the request" is answerable; "Approve tool call send_email?" is not.
• Show the action, not the transcript. The exact tool, the arguments that matter (recipient, amount, target environment) and the user's original request, side by side.
• Batch related approvals. If an agent is about to run ten similar migrations, ask once about the plan rather than ten times about each step. The batch endpoint checks up to 64 actions in one request, which makes it practical to evaluate a whole plan before any of it runs.
• Remember decisions within a scope. "Allow writes to ./build for this session" is a reasonable memory; "always allow shell" is not. Scope remembered approvals by tool, target and time, and expire them.
• Make deny useful. A denial should go back to the agent as information ("the user declined sending to external recipients") so it can change course instead of retrying.

Two numbers tell you most of what you need:

• Approval rate of asked actions. If humans approve nearly everything they are asked, the ask band is too wide and fatigue will follow. Raise the ask threshold, or add deterministic allow rules for actions that are always fine in your setup.
• Override rate: how often a human reverses the guard (approves an ask that the guard leaned against, or flags an allowed action after the fact). Overrides are your best labelled data. A few hundred of them are enough to recalibrate thresholds for your own traffic, as described in calibrated scores and thresholds.

Also track time to decision. If asks sit unanswered for hours, agents stall and people start granting broad standing approvals to get work done, which quietly removes the human from the loop.

A guard narrows what reaches a person; it does not make the decision for them, and it can be wrong in both directions. Keep the controls that do not depend on anyone's attention: least-privilege credentials, hard denylists for operations that must never happen, and backups for the ones that might. MCP Guard reduces risk; it does not guarantee safety. The point of a good approval policy is that when a human is asked, the question deserves their attention and gets it.