Mumega
Start

Approval Gate (Agent Governance)

An approval gate for AI agents: propose, review, apply. The checkpoint that stops an agent action from executing until a separate identity approves it.

An approval gate is a checkpoint between an agent deciding to take an action and that action actually executing. It has three parts: a proposal (a stored record of the intended action, including a diff of what will change), a gate (a distinct actor — a human, or a different service identity — that approves or rejects it), and an apply step (a separate execution, gated on approval, that re-verifies its own preconditions before running).

Most agent frameworks don’t ship one. OpenClaw is a specific, well-documented example — it has no built-in permissions manifest, approval flow, or audit trail, which is exactly why “openclaw sandboxing approvals” is a live search query. An approval gate is the buildable answer to that gap.

The state machine

A working gate models every gated action as a record moving through explicit states, not a direct function call:

pending → approved → applied, with rejected and rolled_back as exits.

The record carries the diff (computed and stored once, at proposal time — not re-derived at review time), the identity that proposed it, and a timestamp for every transition. Only the applied state is allowed to perform the real side effect; nothing else in the pipeline writes, deletes, or publishes directly.

The failure mode that makes a gate cosmetic: self-approval

A gate that lets the same identity propose, approve, and apply an action isn’t a review — it’s a delay. The fix is to store the proposer’s identity on the record itself and check it on every approve/apply transition, refusing the transition when the acting identity matches the one that created the proposal. Destructive actions (irreversible pushes, production deploys, deletes) also need a stronger permission scope than routine writes, enforced at every entry point that can reach the action — a tool-call interface and a REST endpoint are two separate doors into the same room, and both need the lock.

A second, related failure: approving at time T and applying at time T+n without re-checking that the target hasn’t changed in between. A robust gate re-verifies its preconditions at apply time, not only at proposal time.

See How to Add an Approval Gate to an Agent Stack That Doesn’t Have One for the full pattern, including the exact self-approval fix we shipped in production after finding the hole in our own first attempt.

Beyond the minimum gate

Two hardenings matter once the minimum pattern works:

  • Content-bound execution — the apply step re-loads the stored proposal by id rather than trusting whatever payload the caller sends at execute time, closing the approve-A/execute-B substitution hole. See From Approval to Action.
  • Adversarial review of the gate’s own code — a second reviewer whose job is to defeat the gate, not confirm it. This is how a self-approval hole gets found before it ships, rather than after. See Adversarial Agent Review.

Sources

Last updated: Jul 8, 2026