How do you stop an approval gate from becoming a rubber stamp?

Why doesn’t “add a human in the loop” solve this?

Because a gate is only as good as the attention behind it, and attention is the thing that degrades. The instinct to put a person between an agent and anything that writes to a real system is correct. The mistake is treating that gate as a permanent fix instead of something that has to be actively maintained, the same way a firewall rule or an access grant does.

Public discussion of this exact problem, from engineers building approval-gate infrastructure, names the failure mode plainly: give a reviewer enough good outcomes in a row and they stop reviewing. They start clicking approve on the pattern, not the specific request. The gate is still there. It has stopped doing anything.

What is automation bias, and why does it always show up?

Automation bias is the tendency to trust a system more than the evidence warrants once it has been right enough times. It isn’t a character flaw in the specific reviewer assigned to the gate. It’s a predictable outcome of putting a repetitive judgment call in front of a human over and over, most of which turn out fine. The same discussion that named this problem raised a second, sharper version of it: some approvals genuinely require domain knowledge to evaluate, and a reviewer who doesn’t have that knowledge but approves anyway isn’t adding safety. They’re adding a delay in front of a decision the model already made.

Both versions end the same way. A gate that reads as “safe” on an architecture diagram is, in practice, a click.

Where should the approval gate go?

Not on everything, because a gate on everything is a gate nobody can actually evaluate. Narrow it to the writes where a mistake is expensive and hard to undo: anything that moves money, anything that reaches a customer directly, or anything that changes a record a downstream system trusts. An agent drafting a reply for a human to send doesn’t need the same gate as an agent issuing a refund. Treating them identically is how a reviewer ends up approving fifty low-stakes items a day and losing the habit of scrutiny by the time the one expensive item shows up.

This is the same logic as scoping an agent’s permissions narrowly in the first place: the gate should be sized to the actual risk of the specific write, not applied uniformly because uniform is easier to build.

How do you design a gate that doesn’t decay?

Three things that address the mechanism directly, rather than adding more process on top of it.

1. Keep the gate narrow enough to actually evaluate. If a reviewer is approving dozens of requests an hour, they are not evaluating, they are clicking. Fewer, higher-stakes gates get real attention. More, lower-stakes gates get rubber-stamped.

2. Instrument the approval rate, not just the existence of the gate. A gate that approves 99% of requests for months and then approves the one that shouldn’t have gone through isn’t a safety mechanism that failed once. It’s a safety mechanism that had already failed, silently, long before that request arrived. Track approval rate over time and treat a rate climbing toward 100% as a signal the gate needs attention, not proof it’s working well.

3. Route by domain knowledge, not by title. If evaluating a request requires knowing something specific, a customer’s contract terms, a regulatory exception, a pricing edge case, route it to the person who actually has that knowledge. A generic “manager approves” step in front of a domain-specific decision reproduces the second failure mode above: a click standing in for judgment nobody at that step actually has.

None of this removes the human. It makes sure the human is still doing something when they click.

Where do we put our own gates?

On the specific writes that move money or touch a customer, sized to the actual risk instead of applied everywhere out of convenience. Scoped access and audit logging ship on every agent alongside them, by default. The founder ran security for finance and payments companies before agents were the product, and that background is where the discipline comes from. Read it as our delivery practice, not a claim about how the rest of the category handles it.

If you’re evaluating a vendor’s approval-gate design rather than building your own, ask them the same question this guide asks: which specific writes get gated, and how do they know the gate is still being read six months from now.