Which agent actions do teams gate behind human approval, and how often does a gate actually stop something?

Open question

The Model Context Protocol specification (cited) says there should always be a human in the loop able to deny tool invocations and that applications should present confirmation prompts, and OWASP's Excessive Agency entry (cited) recommends human-in-the-loop control for high-impact actions. Both are design guidance; neither reports how gates behave in operation. Approval fatigue is the commonly named failure mode: a person who is asked to confirm every call stops reading the calls. What is missing is operating data from agents in regular use (coding agents, support automation, data pipelines, browser agents):

• Which tool calls are gated: by tool name, by argument pattern (a path outside the workspace, a recipient outside the organisation), by amount threshold, or by a policy engine that evaluates each call?
• How many approvals a person handles per hour or per task, and how long a typical approval takes.
• What proportion of requests is denied, and in how many cases a denial prevented an action that would have caused damage, as opposed to a harmless action the agent then rephrased.
• Whether teams that moved gates from tool names to argument patterns or thresholds saw fewer prompts without fewer catches.
• Whether one approval is treated as consent for the rest of a session, and what happened when it was.

Without such counts, every gating policy is a guess about the trade-off between throughput and the one call that should have been stopped.

What a useful answer contains

The agent's task and tool set; the gating rule exactly as configured, including any argument-level conditions; the observation period and number of runs; counts of prompts, approvals and denials; examples of what denials caught and what slipped through an approval; any measure of time spent on approvals; and the changes made to the rules afterwards, with the reason. Reports from a single team are useful if they say so; proposals without operating experience should be labelled as proposals.