Only for a short, read-only list inside a sandbox. Commands that install packages, delete files, change permissions, reach new network hosts, or touch credentials should wait for a person. Auto approving everything trades a few seconds per task for an unbounded blast radius.
The tension
Approval prompts slow people down, and people respond by turning them off. A good policy accepts that and sorts commands into tiers so prompts appear rarely and mean something when they do.
A three tier model
| Tier | Examples | Default |
|---|---|---|
| Observe | list files, print a file, show git status, run a linter in check mode | Auto allow |
| Change locally | edit files in the project, run unit tests, format code | Auto allow in a sandbox, prompt outside |
| Act outward | install packages, call a new host, change git remotes, edit pipeline files, delete directories, read credential files | Always prompt |
Keep the tiers short enough to fit on one page. If your policy needs a manual, nobody will follow it.
Allowlists beat denylists
A denylist tries to name dangerous commands. Attackers and honest accidents both find the one you missed, since shells offer many ways to say the same thing. An allowlist names what is permitted and refuses the rest. Our post on allowlist or denylist for agent shell commands goes deeper on this. Enforce the list in the tool or the operating system, because a rule written only in a prompt is advice the model may ignore.
Watch for command chaining
An allowed command can hide a disallowed one. A harmless looking line that joins two commands, pipes into an interpreter, or passes user text to a shell can slip past a check that matches only the first word. When you evaluate a tool, test this directly: allow one safe command, then ask the agent to run it combined with something not allowed. See whether the tool evaluates the whole line.
When broader autonomy is reasonable
Some settings justify fewer prompts:
- A throwaway virtual machine with no credentials, no internal network access, and nothing worth stealing.
- A continuous integration job with a read-only token, running a fixed task.
- A time boxed experiment on a public toy project.
Even then, log what ran. The OWASP Top 10 for LLM Applications names Excessive Agency (LLM06) for exactly this reason: autonomy is a dial, and the safe setting depends on what damage is possible.
How to write the rule down
- Name the environments: laptop, shared dev box, CI, production-adjacent.
- For each, list the auto allowed commands by tier.
- State who can change the list and how a change is recorded.
- Set a review date, because tools add features and defaults shift.
- Test the rule on a sample repository after every upgrade.
Audit what actually happened
Approval settings drift. A developer flips a flag once for a long task and forgets. Ask your tool vendor whether settings can be set centrally and whether command history is exportable. If the answer to both is no, assume local settings differ from policy and sample a few machines.
Pair it with a gate
Whatever the agent ran locally, the resulting change still goes through review and checks. Policies on pull requests catch what a command prompt cannot, such as a new dependency with a known problem. Safeguard can help at the dependency and pipeline end of this: SBOM and dependency scanning, reachability analysis, policies and gates on pull requests, and agent identity. You can try a free scan at gold.safeguard.sh/scan.
A worked example: classifying real commands
Take a typical afternoon of agent activity on a web service repository. Sorting ten commands into tiers shows how few prompts are really needed.
| Command purpose | Tier | Default | Notes |
|---|---|---|---|
| List files in a directory | Observe | Auto allow | No state change |
| Show git status and diff | Observe | Auto allow | Read only |
| Run the linter in check mode | Observe | Auto allow | Read only |
| Run unit tests | Change locally | Auto allow in sandbox | May write temp files |
| Format source files | Change locally | Auto allow in sandbox | Shows in diff |
| Install a new package | Act outward | Prompt | Runs third party code |
| Fetch a URL not on the list | Act outward | Prompt | Possible exfiltration |
| Edit a pipeline file | Act outward | Prompt | Changes what runs in CI |
| Delete a directory | Act outward | Prompt | Hard to undo |
| Read a credentials file | Act outward | Block | Not needed for the task |
Out of ten commands, six run silently and four stop for a person. The person sees prompts only when they matter, so each prompt gets real attention. Compare that with prompting on every command, which trains people to click yes without reading, or with allowing everything, which makes the first hostile instruction expensive.
Testing the policy
Write test cases, not just a policy page.
- Allow a safe command, then ask the agent to chain it with one that is not allowed. The whole line should be evaluated, not just its first word.
- Ask the agent to run a command through a script it wrote itself. See whether the tool notices.
- Ask for an install of a package with a name that does not exist. See whether the request is stopped or whether the tool pulls whatever a registry returns.
- Flip the approval flag on one machine and check that central reporting notices the change.
What goes in the exception process
Some work legitimately needs wider autonomy: a one time migration, a large mechanical refactor. Make the exception cheap but visible. Record who, which environment, which commands, for how long, and who approved. Expire it automatically. Our post on an exceptions process for an AI coding assistant policy shows a lightweight form.
A short rule you can publish
"Reading is automatic. Changing the project happens in a sandbox. Anything that installs, deletes, reaches a new host, or touches credentials needs a person." It fits on one slide and gives developers a rule they can predict.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice the checks that still apply after local commands ran.
Quick check
Is "auto approve in a container" safe?
Safer, not safe. It depends on what the container can reach. With no credentials and a locked network, the risk is small. With mounted tokens, it is not.
How many prompts are too many?
When people click through without reading. Cut the prompts to the risky tier so each one gets attention.
Do approval prompts replace code review?
No. Prompts guard actions on a machine. Review guards the resulting change. You need both.
Sources
Last reviewed: 19 October 2026.
