AI agent change approval · reviewed 2026-10-03
Execution permission and change acceptance are different controls.
Direct answer: Let execution policy decide what the agent may do inside a bounded environment. Let acceptance policy decide whether the exact verified candidate may become accepted project state. Human attention is most valuable at consequential boundaries, not on every low-level command.
Execution permission
This is the sandbox/policy question: may the agent run this command, write this path, or reach this network destination? Codex, Claude Code and OpenShell all implement meaningful controls at this layer.
Change acceptance
This is the source-state question: after a concrete candidate exists and declared checks have run, may this exact candidate become accepted code? The approval should identify the reviewed candidate and become invalid if the candidate changes.
Why not approve every command?
OpenAI and Anthropic both publicly discuss approval friction. Repeated prompts can reduce attention and throughput. A better design keeps routine actions inside enforceable policy and reserves humans for the boundary that carries real consequences.
Minimum useful acceptance packet
- candidate identity/diff;
- declared validator results;
- changed paths;
- known limitations;
- approval identity/time;
- what state transition approval authorizes.
StateHinge hypothesis
The protected-run core has a local exact approval-bound commit path. BUSINESS is testing whether this, combined with resume and rollback evidence, removes enough agency review/recovery cost to justify another layer. That value is not yet customer-proven.
Primary sources
What approval does not prove
Human acceptance proves a decision was made about a candidate. It does not prove the candidate is correct beyond the evidence that was reviewed.