What permissions should an AI agent have? A starter least-privilege policy
A least-privilege default for AI agents: an allow, ask, and deny table for common tools, not vague principles.
An AI agent should auto-run anything read-only, pause for a human on anything that writes, deletes, pushes, or spends, and refuse a small set of actions outright. That is least privilege applied to tools: the default is no, reading is the cheap exception, and everything with a real-world side effect goes through a person before it runs.
The hard part is not the principle. It is drawing the line tool by tool so the agent stops interrupting you about ls and still pauses on git push --force. Below is a starter policy you can copy, with an explicit allow, ask, and deny column.
Key takeaways
- Default to deny, then allow only proven read-only actions. Reads are safe and frequent, so auto-approving them is what keeps the rest of your attention sharp.
- Send writes, deletes, network pushes, and anything that spends money to a human. These are the actions worth a 10-second look.
- Hard-deny a short list: secret reads, force pushes to main, destructive disk commands. A gate you can rubber-stamp is not a gate.
The default is deny
Least privilege means an agent starts with no permissions and earns them. Most permission setups invert this: they allow a whole tool like Bash or Shell, then hope nothing bad runs through it. But Bash is not a unit of risk. cat README.md and rm -rf node_modules are the same tool with opposite consequences. A policy that only sees the tool name has to either ask about everything, which trains you to tap approve without reading, or trust everything, which removes the human entirely.
So the line has to live inside the tool, at the level of the actual command and its arguments. That is what makes a real allow, ask, deny split possible.
The starter table
| Action | Default | Why |
|---|---|---|
ls, cat, grep, cd, git status, git log, git diff, reading files | Allow | No side effect. Reading cannot corrupt state or spend money. |
Editing a file, writing a file, git add, git commit | Ask | Reversible but real. A glance is cheap insurance. |
git push, deploys, npm publish, DB migrations | Ask | Changes shared state other people depend on. |
Sending email, posting to Slack, calling a paid API, stripe commands | Ask | Spends money or reaches the outside world. Hard to take back. |
rm -rf on anything outside the working tree, git push --force to main, reading .env or secrets | Deny | Catastrophic or sensitive. These should not be one tap away. |
Treat the allow row as the floor and the deny row as the ceiling. Everything in between is an ask, and the ask is the whole product: a notification on your phone, a yes or no, and the agent waits.
Why reads get auto-approved
Asking a human to approve ls is noise, and noise is what erodes attention for the prompts that matter. If the agent stops on every read, you learn to approve on reflex, and then you approve the one git push --force that mattered the same way.
Pushary auto-approves a proven read-only floor by default. We did not guess at the list. It was decided from 1,721 real production questions, with the commands that were read-only every single time pulled out. The agent runs ls, nothing interrupts you, and the action still lands in your audit trail.
Why some actions get a hard deny
An ask is only meaningful if you might say no. A few actions are bad enough that they should not reach a phone prompt at all, because a tired human at 11pm will tap approve. Force-pushing over main, wiping a directory outside the repo, and reading raw secrets belong in the deny column, not the ask column. If you genuinely need one of these, you lift the gate deliberately, not in the middle of a flow.
Make it match your own work
The table is a starting point, not a finished config. Your workflow has its own defaults: maybe you always allow bun run typecheck, maybe you always deny anything touching .env. Pushary permission policies match on the command and arguments with exact, prefix, and tool precedence, so a narrow gate is never silently overridden by a broad allow. The policies docs cover the matching rules, and Permission Autopilot will mine your real approve and deny history into one-tap rule suggestions so you confirm the defaults you have already shown.
Common questions
What is the safest default permission for an AI agent?
Deny by default, then allow only read-only commands. Reads cannot change state or spend money, so they are the one category safe to auto-run. Everything that writes, pushes, or pays goes to a human first.
Should an AI agent be allowed to run shell commands at all?
Yes, but scoped. Allowing the shell as one blanket permission is the mistake. Allow the read-only subset, ask on writes and deploys, and deny destructive commands. The unit of permission is the command, not the tool.
Where do these gates actually run?
On the CLI agents (Claude Code, Codex, Gemini CLI, Cursor, Hermes) a hook enforces the gate before the tool runs. The Claude Desktop connector can notify and ask but cannot block a tool, because Desktop has no hook to gate at. That is a real limit, not a setting you flip.
A starter policy is worth copying, but the value is in the gate that enforces it and the trail that records every decision. See permission control for how the policy engine works, or pricing to put it on your agents.