Why the gate sits on writes
A gate on every action trains reviewers to click through without reading, which destroys the control it was meant to create. The asymmetry is deliberate: reads are reversible and cheap, so they run freely; writes are neither, so they stop.
That placement is also what makes the system approvable. A security reviewer can accept broad read access far more easily than a single unattended write to a system of record.
Three properties that separate a real gate from a dialog
The change is shown, not described. "The agent would like to update your records — proceed?" asks the reviewer to approve a category, not an action. What is needed is the diff: which fields change, from what to what, across how many records, and which ones. That count is the blast radius.
The approval cannot be replayed. If approval is a boolean, it can be applied to whatever the plan happens to be at execution time — which need not be the plan the reviewer saw. Binding it to a concurrency token and the approved schema means a mismatch refuses the write instead of proceeding.
Escalation is a real outcome. Given only approve and reject, a reviewer who is not the right person to decide will approve, because rejecting discards work someone else requested. A third option routes the decision instead of manufacturing consent.
The diagnostic
Check the rejection rate. If it is zero across thousands of approvals, the gate is not working — either reviewers cannot see enough to object, or approval has become reflex. A functioning gate produces rejections, and the rejections are where you learn what the agent gets wrong.
Where it has to live
In the execution path, not the interface. A gate implemented in the UI is advisory — anything calling the underlying tool directly, such as a retry or a scheduled run, bypasses it. The check belongs at the point of dispatch, where every caller passes through regardless of origin.