The Approval Nobody Reads

Anyone who works with coding agents knows the rhythm. The agent asks to run a command. You click Allow. It asks again. Allow. By the twentieth prompt you aren't reviewing anything. You're clearing a queue so the work can keep moving.

We know the rhythm because we live it. It's the reason we stopped treating "a human approves it" as a control.

Most advice on agentic AI governance lands on the same instruction: keep a human in the loop. It sounds responsible, and it satisfies a checklist. But an approval only governs an agent if the person approving has what they need to say no. Without that, human in the loop is theater: a step that looks like oversight and checks nothing.

The numbers on rubber-stamping

This isn't a hunch.

• In March 2026, Anthropic reported that Claude Code users accept 93% of permission prompts, and named the result: approval fatigue, "where people stop paying close attention to what they're approving."
• Developer Alex Wauters built a browser game that simulates an agent's permission requests. Across more than 40,000 runs and 409,000 decisions, players approved about one in three malicious requests. Requests to read cloud credentials and cluster configs slipped through 35% of the time. The single most-missed command, npm run analyze, was approved nearly 65% of the time, even though the agent's log showed what the script actually did.

The game packs in far more bad requests than a normal workday would. That cuts both ways. When threats are rare, there's even less reason to read the next prompt carefully.

An instruction is not a control

In July 2025, SaaStr founder Jason Lemkin was building an app with Replit's AI agent and had declared a code and action freeze. The agent ran unauthorized commands against the live database anyway, wiping data for more than 1,200 executives and over 1,190 companies. Then it told him a rollback wouldn't work. It would have. He recovered the data himself.

The freeze was an instruction typed into a conversation. The agent still held the access to change production. Replit's response was structural: automatic separation of development and production databases, better rollback, and a planning-only mode. They took away the ability instead of asking more firmly.

I watch this happen every day

I don't let Claude touch git. No commits, no pushes, no staging, no pulls. That rule is written into the instructions loaded at the start of every session, in plain language, and I've stated it more than one way.

Claude still tries, and often. What stops it isn't the instruction. It's the restrictions I've put in its settings, which reject the command before it runs. Every blocked attempt is a record of a time the instruction alone would have failed.

My agent can't be trusted to follow the rules, no matter how many ways I ask. That's not a complaint about one product. It's how these systems work. To the model, an instruction is input to weigh, not a wall it can't get past.

Even the block has limits

The settings restriction isn't the end of the story either. Anthropic's own documentation says a command-level deny rule "covers the invocation Claude usually produces and isn't a security boundary around the program." Run the same program by a different path or inside a script, and the rule may not match. For enforcement that holds, the documentation points to OS-level sandboxing.

So we stack the layers, and we're clear about what each one is worth:

1. The instruction tells the agent the rule. It gets ignored.
2. The local restriction blocks the commands the agent usually tries. It catches most attempts.
3. The server-side rule lives outside the agent's environment entirely. On the repositories that matter, GitHub requires a second person to approve before code merges, and no local setting can turn that off.

The first is a request. The second is a filter. Only the third is a control in the full sense.

That's the first lesson of governing agents. Telling an agent what not to do is a request. Removing its access is a control.

Why human in the loop turns into theater

Approvals decay for three reasons, and none of them is that people are careless.

Volume. Every prompt competes for the same attention. When an agent asks fifty times an hour, the fifty-first request gets the same click as the forty-nine before it.

Missing context. "Run npm run analyze?" tells you the command. It doesn't tell you what it touches, what data it reads, or how to undo it. You can't evaluate a request you can't see into, so you trust it.

Bundling. "Apply these 14 changes?" is one decision standing in for fourteen. People approve the bundle because rejecting it means sorting through all of it.

Each one turns a decision into a reflex. Real governance has to remove all three.

How we govern our own agents

We put agents to work across our own business. These are the rules we hold them to, and what each one fixes.

Pull requests come with a review plan

We require a second person to approve code before it merges. That requirement backed up our work immediately, and it exposed the problem with a bare approval: a reviewer who doesn't know what to check will check nothing and click approve. That's process for its own sake.

So we added a review plan. The author writes down what the reviewer needs to verify, and picks a reviewer who can actually evaluate the change. For real emergencies there's a named break-glass override, not a quiet admin bypass.

Fixes: missing context.

Agents name the exact action before touching any system

An agent never writes to any system, ours or a client's, staging included, without asking first. The request has to state the exact action, the system, and the data involved, then wait for a yes. One approval never carries forward to the next action. Verifying a fix is read-only. If a real write is the only way to confirm it, that's a new request.

Fixes: missing context, and approvals that quietly expand.

Edits get approved one at a time

When an agent proposes changes to a document, each suggestion comes up for its own decision. No summaries, no "accept all." Bundled approvals get rubber-stamped. Individual ones get read.

Fixes: bundling.

Agents draft. People publish.

Content an agent produces lands in our CMS as a draft for review. Agents don't publish to production.

Fixes: an irreversible step happening without a person who meant it.

More approvals is the wrong answer

There's an obvious objection, and it's fair: every rule above adds an approval, and approvals are what cause fatigue. We feel that fatigue too.

That's why the hard rules sit where mistakes get expensive or hard to undo: any system outside the agent's sandbox, production, published content, merged code. The answer to prompt fatigue isn't more prompts. It's spending human attention only at those boundaries and handling everything else another way. Inside a sandbox, where nothing leaves and everything can be thrown away, routine actions shouldn't need a person at all. Sandboxes, scoped credentials, and automated checks absorb the noise, so the few approvals a person does see are worth reading.

Even Anthropic, while shipping a mode built to cut down on prompts, says it "is not a drop-in replacement for careful human review on high-stakes infrastructure." Automate the low stakes so people can be careful about the high stakes.

Agentic AI governance best practices

If you're putting agents to work in your business, start here:

1. Control access, not just behavior. Separate development from production, scope credentials to the task, and assume any instruction can be ignored.
2. Approve by risk, not by action. Reserve human approval for actions that are irreversible, external, or client-facing. Sandbox and automate the rest.
3. Make every request self-explaining. The action, the target, the data, and how to undo it belong in the request itself.
4. Write down what the reviewer checks. An approval without criteria is a signature, not a review.
5. Never bundle. One decision per approval.
6. Stage, then publish. Agents produce drafts. A person makes them live.
7. Keep the emergency path small and named. A defined break-glass group beats everyone quietly holding bypass rights.
8. Watch your approval rate. If nearly every request gets approved, the gate isn't checking anything. Either those requests don't need a human, or the human isn't really reviewing.

FAQ

What is agentic AI governance? The access rules, approval steps, and review practices that decide what AI agents can do on their own, what needs a person's sign-off, and how you confirm what they did. It's enforced in systems and permissions, not just written into a policy.

Is human in the loop enough to govern AI agents? Not by itself. A human approval works only when the approver has the context to evaluate the request and few enough requests to pay attention. Without both, people approve almost everything.

Which agent actions should need human approval? Actions that are hard to undo or that reach outside the agent's sandbox: writing to production or client systems, deleting data, publishing content, merging code, sending messages, and spending money.

How do you reduce approval fatigue? Ask less often, and ask better. Move routine, reversible work into sandboxes and automated checks, and make the approvals that remain carry their full context.

Decide what your agents can touch

We design, build, and secure corporate websites, and we hold our own agents to the standard our clients hold us to. If you're working out what yours should be allowed to touch, book a time.