Approval Gates That Don't Become Rubber Stamps

Overview

Every agent design review reaches a moment where someone says "we'll put a human in the loop for that." The sentence usually ends the discussion. It shows up as a single box in an architecture diagram, gets typed into a risk register as a mitigating control, and turns a "no" on a vendor security questionnaire into a "yes." Almost nobody engineers what happens inside that box.

Almost no team decides in advance which actions actually deserve that box, either. A gate gets added wherever an action feels consequential in the moment, which is a cheap thing to do in a design review and an expensive thing to live with in production. The box gets drawn once, in an hour-long meeting. The queue behind it gets read, or doesn't, every day after, by whoever drew the short straw.

We treat approval design here as its own engineering problem: which actions warrant a gate, how many approvals a workflow is allowed to generate, what has to be on the reviewer's screen, and which alternatives to synchronous approval actually work. Other posts on this site cover approvals in passing, as one control among many in a permission model. This one stays on the mechanics of the gate itself: firing rate, payload, failure behaviour.

Take a hypothetical accounts-payable agent at a mid-size manufacturer, the example we'll come back to throughout. It reconciles supplier invoices against purchase orders and goods-receipt records, flags mismatches, and in its most consequential mode releases approved payments to the banking connector. Almost everything it does is repetitive and safe. A small fraction of it moves money out of the company, and that part doesn't come back.

What Research Says About Reviewers

Human-factors research has measured this failure mode for decades, in domains where the consequences arrive faster than they do in enterprise software. Two bodies of work matter most here.

The first is automation bias and complacency. Skitka, Mosier and Burdick's 1999 study in the International Journal of Human-Computer Studies framed automation bias as the use of automation as a heuristic replacement for vigilant information seeking, and found that participants working without an automated aid outperformed participants given a highly-but-not-perfectly reliable one on a monitoring task. Parasuraman and Manzey's 2010 review in Human Factors integrated two decades of such studies and concluded that complacency and automation bias are overlapping attentional phenomena arising from the interaction of personal, situational, and automation-related characteristics. That's a predictable property of the system design, not a character flaw in the operator. And it has an ugly corollary. A more reliable agent makes the problem worse, not better. The more often the proposed action is correct, the less rational it feels to check it.

The second is alert fatigue, and here the numbers are blunt. A 2006 systematic review by van der Sijs and colleagues in JAMIA, covering seventeen studies of computerised physician order entry, found that clinicians overrode drug safety alerts in 49% to 96% of cases, with poor signal-to-noise ratio the dominant stated reason; the two studies that assessed appropriateness found 36.5% and 39% of alerts to be false positives. The Joint Commission's Sentinel Event Alert 50, published April 2013, reported 98 alarm-related sentinel events between January 2009 and June 2012, of which 80 resulted in death, and estimated that 85% to 99% of alarm signals in hospitals require no clinical intervention at all. Desensitisation was the mechanism in a large share of those deaths.

Two recent papers turn this into criteria you can actually design against. Sterz and colleagues (arXiv 2404.04059) argue an oversight person is only effective when four conditions hold at once: sufficient causal power to change the outcome, suitable epistemic access to the relevant facts, self-control in the moment of decision, and fitting intentions toward the role. We think most production approval flows fail on the second one alone. The reviewer can click deny. They usually can't see what they'd be denying.

A June 2026 preprint by Turan (arXiv 2606.08919) goes further and models the reviewer as an endogenous, fatiguing resource rather than an oracle. Working from 125 hand-labelled adversarial agent actions, it reports inter-reviewer agreement of Fleiss' kappa 0.52 (moderate; there is often no single correct label) and finds an inverted-U relationship in which escalation rates above an optimum make the system less safe. It's a single-author preprint, and its effect sizes should be read as indicative rather than definitive. But the shape of the claim lines up with sixty years of vigilance research.

Regulators have caught up to the mechanism, if not yet to the engineering. EU AI Act Article 14(4)(b) obliges providers of high-risk systems to enable oversight persons to "remain aware of the possible tendency of automatically relying or over-relying on the output." That's automation bias, named explicitly in statute. Article 26(2) then requires deployers to assign oversight to people with the necessary competence, training and authority.

Those high-risk obligations do not bite yet. The Digital Omnibus on AI, adopted by the Council on 29 June 2026, deferred standalone Annex III compliance to 2 December 2027. We wouldn't read too much comfort into that date: the systems that get reviewed in 2027 are the ones being built now, so the design problem is already here. OWASP's Top 10 for Agentic Applications, published 9 December 2025, gives the adversarial version its own category, ASI09, Human-Agent Trust Exploitation, covering agents whose fluent, confident rationales induce operators to approve actions they'd otherwise reject.

Which Actions Actually Warrant a Gate

The most common way to choose gated actions is to ask which ones make people nervous. We think that's exactly backwards. It selects for salience, not risk. Deleting a row from a staging table feels alarming and is trivially reversible. Sending an email to 4,000 suppliers feels administrative and can't be taken back.

We key a defensible framework on four properties of the action, each of which can be evaluated statically at tool-registration time rather than negotiated per incident.

• Reversibility. Can the effect be undone by one operator, without a vendor ticket, within minutes, and without anyone outside the team noticing? A database write with a transaction log is reversible. A payment settled through a banking rail is not.
• Blast radius. How many records, users, tenants, or downstream systems does the action touch? One invoice is not the same as one supplier's whole ledger, which is not the same as a bulk payment run. Blast radius should be computed from the actual arguments, not from the tool's worst case.
• Cost. Monetary and resource cost, evaluated against a threshold the organisation has actually agreed on. "Any spend" guarantees fatigue, because it isn't a real threshold at all.
• Externality. Does the effect become visible or binding outside the organisation? Anything that reaches a customer, a regulator, a supplier, a public channel, or a contract has a reputational and legal component that internal rollback can't repair.

Run the accounts-payable example through it and the work sorts itself cleanly. Reading purchase orders, matching line items, computing variances and writing a reconciliation note are reversible, single-record, zero-cost and internal. No gate, log everything. Creating a supplier record is internal and reversible, but it acquires a large blast radius later, because it becomes a payment destination. Gate it, or make supplier creation a separate human workflow the agent can only prepare for. Releasing a payment above a threshold is irreversible, external and costly. Gate that too. Releasing a batch of 300 payments is the same action with three hundred times the blast radius, and it should never be one approval.

GATE CANDIDATE | yes -> blast radius bounded to one record? | no --------> GATE CANDIDATE | yes -------> execute + log (no gate) | GATE CANDIDATE +-- external effect? yes --> SYNCHRONOUS GATE +-- cost > threshold? yes --> SYNCHRONOUS GATE +-- otherwise -------------> dry-run + post-hoc review -->

Figure 1 — Gate-or-no-gate keyed on reversibility, blast radius, externality and cost. Nervousness is not an input.

Approval Budgets

Treat approvals as a scarce resource with a fixed daily supply, the way you'd treat on-call pages. Pick a number per reviewer per day. Single digits is a defensible starting point. Hold the workflow to it. If a workflow exceeds its budget, don't recruit more reviewers or build a better queue. Change the workflow instead.

That reframing is useful because it makes the redesign options visible. A workflow generating ninety approvals a day usually has one of four fixable problems: it gates a class of action that's actually reversible, so the classification is wrong. It gates at too fine a granularity, approving each of forty line items rather than the reconciliation run that produced them. It has no precedent mechanism, so the reviewer re-approves the same supplier-and-amount pattern every week instead of approving a standing rule once. Or the agent is doing work that should have been a deterministic pipeline in the first place, and the approvals are a reviewer papering over needless non-determinism.

Budgets also expose the aggregation question. Approving "release 300 payments totalling £2.4m" is one approval by count and three hundred by blast radius. Ask whether the reviewer's judgement actually scales with the batch. If it doesn't, cap the batch size.

Designing the Approval Artifact

We think most approval requests in production fail Sterz's epistemic-access condition before anyone even opens them. They tell the reviewer that something is about to happen and give them no basis for judging it. Something like this is depressingly typical:

{
  "id": "apr_8f31c2",
  "message": "Agent wants to call tool `payments.release`. Approve?",
  "requested_at": "2026-09-08T09:14:22Z"
}

That question can't be answered well. The reviewer doesn't know the amount, the payee, why the agent believes the payment is due, who asked for it, or what happens if they deny. Faced with dozens of these, a competent person approves them, because the cost of blocking legitimate work is immediate and personal, while the cost of approving a bad action is diffuse and deferred.

A sufficient artifact puts six things on one screen. The intended action, in the target system's own vocabulary, not the tool name. The full arguments, rendered rather than serialised. The agent's reasoning: the evidence chain that led here, with links to source records. The projected effect, from a dry run rather than a description. The requesting human, so the reviewer knows on whose authority the agent acts. And the agent identity: which agent, which version, which scopes.

approval_id: apr_8f31c2
expires_at: "2026-09-08T09:29:22Z"   # deny on timeout
on_timeout: deny

action:
  system: "Barclays.Net corporate payments"
  operation: "Release scheduled payment"
  reversible: false
  externality: "funds leave the company; recall not guaranteed"
arguments:
  payee: "Kesterline Components Ltd (supplier 40217)"
  amount: "GBP 48,210.00"
  value_date: "2026-09-09"
  bank_account: "**** 4471 (unchanged since 2023-04-11)"

We split it this way for a reason. The second half of the artifact is what makes the decision possible, not merely informed.

evidence:
  invoice: "INV-2026-11894  (ERP doc 8827411)"
  purchase_order: "PO-44120  approved by j.okafor 2026-08-14"
  goods_receipt: "GR-99871  received 2026-09-02, 3-way match OK"
  variance: "GBP 0.00"
dry_run:
  projected_ledger_effect: "AP 40217 -48210.00; Cash -48210.00"
  duplicate_check: "no payment to 40217 in prior 30d for this invoice"
  anomaly_flags: []
principals:
  requesting_user: "j.okafor@ (Finance Ops, initiated run 09:11Z)"
  agent: "ap-reconciler v4.2.1"
  agent_scopes: ["invoices:read", "po:read", "payments:release<=50000"]
precedent: "17 comparable releases in 90d; amount at 61st percentile"

Two details here do disproportionate work. Expiry with deny-on-timeout means an unattended queue fails closed instead of silently accumulating pending money movements. And precedent, meaning this action's similarity to previously approved ones, tells a reviewer where to spend attention: on the request that's unlike the others. An interface that ranks by arrival time wastes the reviewer's scarcest resource.

ONE REVIEW SCREEN --> decision dry-run diff -------+ |- approve -> execute, bind decision to action id requesting human ---+ |- deny -> reason returned to agent agent identity -----+ |- timeout -> deny + alert owner -->

Figure 2 — The approval artifact. Six inputs, one screen, three terminal outcomes including an explicit timeout path.

Alternatives That Often Work Better

Synchronous human approval is an expensive control, and often the wrong one. We think several cheaper mechanisms deliver more of what the gate was supposed to deliver in the first place.

• Dry run and preview. The dominant pattern in infrastructure tooling, for a reason. terraform plan and kubectl --dry-run=server exist because a described intention and a computed effect are different artifacts. Where a target system offers a preview endpoint, use it. Where it doesn't, a shadow write to a mirrored schema is often achievable. A dry run turns an unanswerable question into a diff.
• Reversibility engineering. The highest-leverage move is upstream of the gate: make the action undoable and the gate may become unnecessary. Soft deletes, versioned objects, staged sends with a recall window, payment rails that support same-day cancellation, and outbound queues with a hold period all convert irreversible actions into reversible ones. Every action you move across that line permanently reduces approval load.
• Staged rollout. Execute against one record, then ten, then the remainder, halting automatically on anomaly between stages. Most of the error-catching of a gate with none of the latency, and it catches classes of error a reviewer reading a payload never would.
• Spend and rate caps. A hard limit enforced by policy is a stronger control than a human who might approve. Caps don't fatigue, don't go on holiday, and don't get socially engineered by a persuasive rationale. Per-action, per-hour and per-day ceilings, plus a distinct ceiling per counterparty, cover a large share of what gates are asked to cover.
• Post-hoc review with fast rollback. For reversible, bounded actions, review the record rather than the intent. A daily digest sorted by unusualness, with a one-click undo, produces more genuine scrutiny per unit of attention than a stream of pre-approvals, because the reviewer reads a few interesting items rather than many boring ones.
• Tripwires that escalate only on anomaly. Let the agent proceed unless a specific condition fires: a new payee bank account, an amount outside the historical distribution, an action outside business hours, a tool call the agent has never made before. Turan's inverted-U result is basically an argument for this shape. Escalate selectively, and keep reviewer capacity in reserve for the cases that actually need it.

Figure 3 — Dry-run plus rollback moves the human from the critical path to the exception path. The human still has causal power; they no longer spend it on routine traffic.

Failure Modes

The following failures are common enough that an approval design should be evaluated against them explicitly, the way a distributed system gets evaluated against partition behaviour.

Bypass under time pressure. Someone will build an override for the month-end run, and it will be the normal path by March. If an emergency bypass is necessary, make it a distinct, individually attributed, loudly logged action with a mandatory written reason and automatic post-incident review. Not a flag someone can leave on.

Bulk approve. A "select all" control converts three hundred decisions into zero. The dividing line is whether the reviewer can verify the set as a whole: a total, a distribution, a count of exceptions, a diff against last month's run. An interface that just concatenates three hundred individual requests behind one button gives the reviewer nothing to verify at all.

The reviewer who cannot judge. Routing payment releases to a platform engineer because they own the agent, or tool-call approvals to a finance analyst who cannot evaluate an API argument, produces signatures without scrutiny. Approval routing is a competence question, and Article 26(2) now makes it a compliance question too. If nobody in the routing group can evaluate the request, the gate is theatre, and the action should be blocked outright until the workflow gets redesigned.

Delegation of approval to another agent. The most seductive failure here. When approval volume becomes unbearable, someone will propose an agent that triages the queue, and it will work well enough to get extended into deciding. At that point the human is approving an agent's opinion about an agent's action, which is closer to two agents agreeing with each other than to oversight. Automated triage that ranks and enriches is valuable. Automated triage that decides is something else entirely: an autonomous policy, and it should be held to the standards of one, including its own reversibility and blast-radius analysis.

Absent approvers. Every gate needs defined behaviour for the case where nobody responds: an expiry, an escalation path, a documented default, and a named alternate. Deny-on-timeout is the right default for irreversible actions. Silent indefinite pending is the wrong answer everywhere, because it converts a safety control into an availability outage and creates pressure for the bypass above.

Persuasion. ASI09 is not hypothetical. A fluent, well-cited rationale for a harmful action is more likely to get approved than a terse request, and reviewers given clear explanations tend to defer more, not less. That's why the artifact leans on verifiable evidence, record ids, computed diffs, three-way match results, rather than prose. Evidence a reviewer can check independently is a different thing entirely from an explanation they merely find convincing.

Conclusion

We'd summarize the sequence that works like this: classify actions by reversibility, blast radius, cost and externality. Engineer reversibility until as much as possible falls below the gate line. Set an approval budget and redesign any workflow that exceeds it. Give every remaining gate an artifact containing the action, the arguments, the reasoning, a dry-run diff, the requesting human and the agent identity. Define explicit behaviour for timeout, bypass, batch and absence.

None of this works without something that can actually say no: an enforcement point outside the agent's reasoning loop, holding both the agent's identity and the identity of the human it acts for, able to refuse one action rather than shut off an entire integration. That's where we think the platform layer earns its place, separate from the approval design itself. Agentic Fabriq enforces permissions at the level of the individual action in the backend, carries both identities on every request, and computes the effective tool list as the intersection of the user's scopes and the agent's. That's what makes an approval artifact populatable in the first place, and a denial real rather than advisory.

Sources

• Does automation bias decision-making? — Skitka, Mosier & Burdick, International Journal of Human-Computer Studies 51:991–1006 (1999)
• Complacency and Bias in Human Use of Automation: An Attentional Integration — Parasuraman & Manzey, Human Factors 52(3):381–410 (2010)
• Overriding of Drug Safety Alerts in Computerized Physician Order Entry — van der Sijs et al., JAMIA 13(2) (2006)
• Sentinel Event Alert 50: Medical device alarm safety in hospitals — The Joint Commission, April 2013
• On the Quest for Effectiveness in Human Oversight: Interdisciplinary Perspectives — Sterz et al., arXiv:2404.04059
• Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human — Turan, arXiv:2606.08919 (June 2026)
• EU AI Act Article 14 — Human Oversight
• Artificial Intelligence: Council gives final green light to simplify and streamline rules (Digital Omnibus on AI, 29 June 2026) — Council of the EU
• OWASP Top 10 for Agentic Applications (published 9 December 2025) — OWASP GenAI Security Project
• Human Oversight under Article 14 of the EU AI Act — Melanie Fink (SSRN)
• LangGraph human-in-the-loop interrupts — LangChain documentation
• Kubernetes API server-side dry run
• Terraform plan — HashiCorp documentation
• 'Human oversight' in the EU artificial intelligence act: what, when and by whom? — Law, Innovation and Technology (2023)
• From Runtime Records to Legal Findings: An Evidentiary-Adequacy Criterion for Agentic AI Oversight — Janssen, arXiv:2607.00941