Writing ·
Human approval gates for AI agents: what reviewers need before a risky action in 2026
Human approval gates work when the harness freezes the exact action surface, preserves the reviewer decision, and invalidates stale approvals before resume.
By Youssef Hemimy · agent reliability · governance · approvals
Human approval gates work when the harness freezes the exact action surface, records the reviewer decision, and blocks stale approvals from carrying forward. Approval is not a rubber stamp. It is a control surface that should stay as narrow as the action the reviewer actually saw.
- 4
- fields that must stay frozen
- 4
- resume rules after review
- 2
- controls to pair with approvals
- 1
- exact action surface
Propose
action, target, reason
Freeze
arguments, scope, policy
Decide
approve, reject, or narrow
Resume
only the approved surface
Approval invariant
Approval covers the exact action surface that was reviewed. If the tool, target, argument, or policy changes, the old approval is stale.
Approval is a boundary, not a note
A useful gate blocks the next action until the reviewer has decided what should happen. That is different from leaving a note in the trace. The gate has to control execution the way production agent tool contracts control writes: the action must match what was reviewed.
What the reviewer actually needs
| Reviewed field | Why it must freeze |
|---|---|
| Target | The action can be safe for one target and unsafe for another. |
| Arguments | Small argument changes can change side effects and risk. |
| Scope | The permission surface is part of the approval, not a background detail. |
| Policy version | A later policy may invalidate the earlier decision. |
Where stale approvals cause damage
The risk is not theoretical. A run can be approved for one action and then quietly resume into a broader action if the harness does not re-check the surface. That is exactly why the approval gate belongs next to idempotent agent tool calls and the recovery logic in workflow recovery plans.
- Freeze the target, arguments, scope, and policy version.
- Require a fresh review if any of those fields changes.
- Resume only the exact action that was approved.
- Keep the approval record attached to the resumed run.
How this fits the operating model
Approval gates are the governance layer of the harness. They work best when the rest of the system already knows how to retry safely, resume safely, and stop when the evidence is incomplete. In Bonfire's AgentOps Hardening work, that means approval records are treated as runtime control data, not compliance theater after the run is over. That is the operating model described in What is AgentOps? and agent reliability SLOs.
FAQ
What should an approval gate freeze?
It should freeze the exact action surface: the target, the arguments, the scope, and the policy version that was reviewed.
When does an approval become stale?
When the tool, target, argument, or policy changes. At that point the old decision no longer covers the new surface.
Why not ask for approval after the action runs?
Because approval is supposed to prevent unsafe actions, not explain them after the side effect already happened.
How does this relate to retries?
Retries are only safe if the approval state still matches the exact call that will be retried. If the call surface changed, the retry needs a new decision.
Building something that has to hold up?
We do this work for teams — agent reliability hardening, custom MCP servers, and full-stack AI systems built to survive production.