Require a human yes for coding agent actions that are hard to undo, that touch secrets or production, that change permissions or pipelines, that install new software, or that reach a new network destination. Let routine reads and edits on a working branch run without prompts, so approvals stay meaningful.
The principle
OWASP's guidance on excessive agency says to require human approval for high-impact actions and to enforce authorization in downstream systems instead of trusting the model's judgment. Both halves matter: a person decides, and the system backs that decision with real limits.
Sort actions by reversibility and reach
Ask two questions of each action. Can it be undone easily? How far does it reach beyond the working branch? Easy to undo and local means no prompt. Hard to undo or wide reach means approval.
| Action | Approval | Reason |
|---|---|---|
| Read project files | No | Local, harmless on its own |
| Edit files on a working branch | No | Git history can reverse it |
| Run tests and linters on the allow list | No | Known, bounded commands |
| Delete files or directories | Yes | Can be hard to recover if uncommitted |
| Install or update a package | Yes | Supply chain exposure |
| Run a command outside the allow list | Yes | Unknown effect |
| Edit CI workflow or permission files | Yes, plus code owner review | Changes what automation may do |
| Read or write credentials | Yes, or deny outright | Highest sensitivity |
| Contact a new network host | Yes | Possible data path out |
| Push, merge, or release | Not by the agent | Branch protection and a human reviewer |
| Call a tool server with write effect | Yes | Effects leave your repository |
Prevent approval fatigue
Too many prompts train people to click yes without reading. To avoid that:
- Pre approve the safe, repeated actions through an allow list.
- Group related prompts where the tool allows.
- Show the real command and target in the prompt, not a summary.
- Track how often prompts are approved within seconds. A very high rate is a warning sign, either the prompts are noise or nobody is reading them.
Do not rely on prompts alone
A prompt asks a person. A control stops an action. For the highest risk items, add an environment limit that holds even if someone approves in a hurry: no production credentials on the machine, protected branches, network allow lists. See does an approval prompt keep a coding agent in the project for why.
Review the list
Revisit the table after each incident and each tool change. Agents gain new capabilities with updates, and a safe action last quarter may not be safe now. Pair it with an autonomy ladder so approvals loosen only when evidence supports it.
Record every approval
Keep the prompt shown, the answer, who gave it, and when. It speeds investigations and shows an auditor that a human decision existed. See agent audit log fields.
Safeguard offers an MCP Guardrail, agent identity, policies, and pull request gates that back up the actions on this list.
Quick check
Should approval be per action or per session?
Per action for high impact items. Per session approvals for broad classes tend to be granted once and forgotten.
Who should be able to approve?
The developer running the session, for local actions. For pipeline or permission changes, a code owner or security reviewer.
Sources
Last reviewed: 19 October 2026.
