Approval Fatigue: When Human-in-the-Loop Becomes a Rubber Stamp

“Require human approval before the agent does anything sensitive” is the first governance control most teams reach for, and it’s a reasonable one — a person looking at a refund, a production delete, or an external email before it fires is a real check that a fully autonomous agent doesn’t get. The trouble isn’t the control itself. It’s that the control was designed around a human reading a handful of requests a day, and agentic AI doesn’t stay at a handful of requests a day for long.

The failure: an approval gate that becomes a reflex

A team wires up requireApproval for anything over a threshold — a refund above $500, a schema change, a message sent to someone outside the company. In week one, three or four requests land per day. Someone reads each one, checks it against what the customer actually asked for, and clicks approve or deny with real judgment behind it. The control works exactly as designed.

By week eight the agent is wired into ten workflows instead of one, and the approval queue has eighty items in it before lunch. Nobody budgeted more reviewer time for that growth, because nobody thought of “approvals per day” as a capacity number that scales with agent adoption — it scaled anyway. The reviewer starts pattern-matching instead of reading: same shape, same amount, same customer tier as the last twenty, approve. That’s not laziness, it’s a rational response to volume — and it’s indistinguishable, from the queue’s point of view, from a rubber stamp. The one request in that batch that’s actually a confused deputy acting on a poisoned instruction, or the one call that’s part of a lethal-trifecta exfiltration chain, looks exactly like the other seventy-nine on the screen. The gate is still there. It just stopped gating.

Why this isn’t a bug you catch by adding more approval gates

The instinct when an incident review turns up a rubber-stamped approval is to add more gates — require a second sign-off, lower the threshold, flag more action types for review. That makes the volume problem worse, not better, because it doesn’t touch the actual failure mode: an undifferentiated approval queue treats a $600 refund and a bulk export of customer records as the same one-click decision, so the reviewer’s attention gets spread evenly across requests that don’t carry anywhere near the same risk. Security teams learned this the hard way with alert fatigue — a SOC drowning in low-value alerts doesn’t get safer when you add more alert rules, it gets an analyst who dismisses faster. An approval queue for agent actions is the same mechanism with a different name.

It’s also a problem observability doesn’t catch by itself. Every approval in the fatigue scenario logs cleanly: a human account clicked approve, at a timestamp, on a request that was correctly presented. Nothing about that log line is wrong. What’s missing is the context that would tell a reviewer of the log — not the request — that the approving human had clicked approve nine hundred times that week in under two seconds each. The system did exactly what it was told; it just wasn’t told to watch the humans as closely as it watches the agents.

Where the fix actually has to live

• Approval has to be risk-tiered, not blanket. If everything over a low, static threshold requires the same one-click sign-off, volume degrades every approval to the same reflex regardless of what’s actually at stake. Reserve human review for the calls that genuinely need judgment, and let policy — not a person clicking fast — handle the rest the way scoped, short-lived credentials already limit what a routine call can do in the first place.
• Each approval request needs enough context to be judged on its own, not just an opaque “approve/deny” against a call the reviewer has to reconstruct meaning from. A request that shows what changed, why the policy engine flagged it, and how it compares to the last few similar decisions is judged faster and more accurately than a bare button.
• An approval has to be scoped to the exact arguments it was granted for, and expire fast. A decision made for one specific call shouldn’t be reusable against a different, larger one just because it superficially matches — and it shouldn’t sit valid for hours after being granted, waiting for something to replay it.
• Reviewer behavior belongs in the audit trail as its own signal. Traceability for agents usually means “what did the agent do.” It also has to mean “how is the human gate behaving” — approval latency, click-through rate, and streaks of identical fast decisions are exactly the pattern that should surface in incident forensics before an incident, not just during the postmortem of one.
• A spike in approval volume is itself a signal, not just a staffing problem. A sudden burst of similar-looking requests is what a compromised or malfunctioning agent produces, and it’s also exactly the condition under which fatigue sets in — the same moment a kill switch should be tightening scrutiny is the moment volume is quietly loosening it.

The business case: approval that scales without becoming decoration

This is the shape Fullmakt’s approval flow is built around, because a governance control that degrades under its own success isn’t a control:

• requireApproval is a per-rule policy — scoped to specific endpoints, methods, or data classes rather than a blanket setting — so human review stays reserved for calls that are actually high-stakes instead of being sprayed across every routine one. Fewer, sharper approval requests is the same design principle as scoping a credential: less surface, more attention per decision.
• Every approval is bound to the exact call it was granted for. The broker matches a retry against the specific arguments that were approved; a different argument set produces a fresh approval requirement rather than silently consuming an old decision, so a rubber-stamped “yes” on one call can never quietly cover a different one later.
• Approvals are short-lived on both ends — an hour to decide, minutes to consume once granted — so a stale decision can’t sit around waiting to be replayed against something riskier than what the reviewer actually looked at.
• Every decision, approval and expiry alike, lands in the same cryptographically chained audit trail as the calls themselves. That makes “is our human gate still doing real work” a query against the record — approval latency, streaks of fast decisions, ratios of approve-to-deny — instead of a question nobody thinks to ask until an incident forces it.
• Because policy evaluation sits at the broker, on the data plane, spikes in approval volume are visible at the same chokepoint that would need to escalate or throttle in response — the system that decides whether a call needs a human is the same system that can tell when the humans are underwater, instead of those being two disconnected pieces of infrastructure that only meet in a postmortem.

FAQ

Isn’t approval fatigue a people problem, not something a platform can fix? The behavior is human, but the conditions that produce it — undifferentiated volume, no context per request, no visibility into reviewer patterns — are design choices. A platform that scopes what needs review and surfaces reviewer behavior in the audit trail changes those conditions; it can’t change human attention spans, but it can stop demanding more of them than the design should ask for.

Doesn’t requiring approval for more actions make things safer? Only up to the point where volume outpaces attention. Past that point, each additional gate dilutes the scrutiny available for every other one — the total amount of careful judgment a team can apply per day doesn’t grow just because the policy asks for more of it.

How would a team notice fatigue is happening before an incident forces the question? Look at the audit trail for approval latency and approve/deny ratios over time. A gate that used to take a minute of consideration and now resolves in under two seconds, consistently, is the signal — the same way a security team watches alert-dismissal rates, not just alert volume.

Does this mean fewer actions should require human approval? It means the actions that require it should be chosen deliberately, by risk, rather than by a single static threshold applied everywhere. Fewer, better-targeted approval gates typically produce more real scrutiny than many shallow ones.

Is this the same problem as alert fatigue in security operations? It’s the same mechanism wearing a different name — a human review step that degrades predictably under volume it wasn’t sized for. The fix in both cases is the same: reduce what reaches the human to what actually needs a human, and watch the review step itself for signs it’s stopped working.

A human-in-the-loop control is only as strong as the attention it actually gets, and attention doesn’t scale for free just because an organization added more agents. The fix isn’t more approval gates or more reviewers — it’s making sure the gates that exist are scoped tightly enough, and watched closely enough, that “approved” still means someone looked.