Approval systems for coding agents
Quick answer
Section titled “Quick answer”Coding agents need approval systems because “can edit code” is not one risk class. Reading a repo, proposing a diff, updating tests, changing CI config, and touching production infrastructure are different actions and should not share the same approval path.
The right approval system is risk-based, not tool-based.
The simplest healthy model
Section titled “The simplest healthy model”Split actions into at least four classes:
- read-only exploration,
- bounded code changes,
- workflow or infrastructure changes,
- production-impacting or security-sensitive changes.
Each class should have a different approval expectation.
What should usually be auto-allowed
Section titled “What should usually be auto-allowed”Low-risk actions can often proceed without per-step human approval:
- repo search,
- file reading,
- test discovery,
- diff analysis,
- and local reasoning over code.
These actions create context, not change.
What should usually require review before merge
Section titled “What should usually require review before merge”Most code-writing activity belongs here:
- bounded implementation,
- test updates,
- documentation edits,
- refactors in a known scope.
The agent can draft the work, but a human should still own the merge decision.
What should require stronger approval
Section titled “What should require stronger approval”These usually need stricter gates:
- dependency changes,
- CI/CD modifications,
- secrets or credentials handling,
- infra or deployment changes,
- or edits to security-sensitive code paths.
This is where coding-agent leverage can quickly turn into operational risk.
The wrong approval model
Section titled “The wrong approval model”The wrong model is one binary rule:
- either “the agent is trusted” or
- “the agent is never trusted.”
Both are weak. One removes discipline; the other removes leverage. A graded approval model is the healthier operating system.
Implementation checklist
Section titled “Implementation checklist”Your coding-agent approval system is probably healthy when:
- action classes are defined by risk;
- read, write, merge, and deploy boundaries are separated;
- the human reviewer remains accountable for consequential changes;
- verification requirements scale with risk class;
- and the team can explain why a given agent action did or did not need approval.