Approval Gates in Agents: Where to Put the Human

An approval gate is a point where the agent stops and waits for a person. It is the most common safety mechanism in agent systems and the one most often installed in the wrong place.

The wrong place is everywhere. A gate on every mutating action produces a stream of prompts that the reviewer stops evaluating within an hour, at which point you have the latency cost of a gate with none of the protection.

Gate on consequences, not on actions

The useful sorting question is not how dangerous the action sounds, but what happens if it was wrong.

Writing a file inside a git working tree sounds destructive and is trivially reversible: the diff is visible, the change is revertable, nothing outside the sandbox saw it. It does not need a gate. Sending an email sounds harmless and cannot be undone at all. It does.

Sort every tool by reversibility and blast radius. Reversible and local gets no gate. Irreversible or externally visible gets one. That single pass usually reduces a gate list of thirty actions to four or five, and those five keep their meaning because they arrive rarely.

Batch at the boundary instead

The other reason gates proliferate is that people gate mid-task steps because they want visibility into what the agent is doing.

Visibility and consent are different needs and want different mechanisms. Stream the actions to a log the reviewer can watch, and put the gate at the point where work leaves the sandbox — the pull request, the deploy, the outbound message.

A reviewer looking at a complete diff makes a better decision than the same reviewer approving forty individual writes, because the diff shows the shape of the change and the individual writes do not. Reviewing the whole is both cheaper and more accurate. Human in the loop design covers structuring that review.

What a gate must show

A prompt that says Run command? [y/n] is a gate in name only, because it withholds the information required to answer.

Show the exact action in full — the complete command, the complete diff, the complete recipient list. Truncation at the review point is where mistakes get through, since the elided part is exactly the part nobody checked.

Show why the agent wants it. One sentence of stated intent lets the reviewer catch the case where the action is fine but the reasoning is wrong, which is a common and otherwise invisible failure.

Show what it will affect: which files, which environment, which records. Reviewers approve on scope more reliably than on syntax, and scope is what most tool prompts omit.

Timeouts and defaults

Every gate needs a rule for what happens when nobody answers, and the default must be denial.

Timing out into approval turns any period of inattention into unsupervised execution, which is precisely the state the gate existed to prevent. Timing out into denial fails safe, and the failure is legible: the task halted waiting for approval.

Set the timeout from how the agent is actually run. An interactive session can wait minutes. An overnight batch either needs a queue of pending approvals that persists until morning, or it needs to be scoped so it contains no gated actions at all.

The second option is usually better. If a workflow cannot run unattended without a human decision, either it is not ready to run unattended or the gated step belongs outside it. Long running agents covers scoping unattended work.

The model should not be the gatekeeper

A tempting shortcut is to have the agent decide when to ask: instruct it to request approval before anything risky.

This fails in both directions. The model asks about harmless actions because it has learned to be cautious, and proceeds with genuinely consequential ones because they did not read as risky in context. It is the same judgement problem as premature completion, applied to safety.

Gates belong in the harness, evaluated on the tool call before it executes, based on rules the model cannot influence. The model may add a request for confirmation on top; it may never remove one. Agent permission models covers where that evaluation lives.

Measure the gates you have

Log every gate: which one fired, what was proposed, the decision, and how long it took to arrive.

A gate approved every time without exception is not protecting anything. Either the action is safer than you assumed and the gate should be removed, or reviewers have stopped reading and the gate is already gone in practice. Both conclusions point the same way.

A gate denied often is telling you the agent repeatedly proposes something inappropriate, which is a prompt or tooling defect rather than a safety success. Fix the cause and the gate goes quiet.

The gates worth keeping are the ones with a mixed record. Those are the decisions genuinely worth a human, and they are usually few. Agent audit logging covers recording them alongside everything else.

A starting policy

No gate on anything reversible inside the sandbox. One gate at the sandbox boundary, showing the complete diff. Individual gates only on irreversible external effects: production writes, outbound messages, spending, deletion of anything shared.

Deny on timeout, log every decision, and review the log monthly to remove the gates that always pass. A small number of gates that reviewers still read carefully protects more than a long list they have learned to click through. Agent shell access safety covers making the sandbox side safe enough to leave ungated.