Permissions: allow, gate, deny

Permission prompts are the main safety mechanism, and they degrade in a predictable way: the twentieth prompt in an hour gets approved without being read. That is not a discipline failure. It is what happens to any control that fires constantly.

The fix is to move decisions out of the moment. Sort operations into three buckets in advance, so the prompts that remain are rare enough to be read.

The three buckets

Allow. Frequent, reversible, and cheap to get wrong. Reading files, searching, running the test suite, building, listing directories, checking git status. Approving these individually costs attention and buys nothing.

Gate. Consequential but ordinary. Writing files, committing, installing dependencies, running arbitrary shell commands. These are the prompts worth actually reading, and there should be few enough that you do.

Deny. Anything whose worst case you would refuse, however unlikely it is. Pushing, force-pushing, history rewriting, reset --hard, deleting branches, production deploys, migrations against a real database, anything touching secrets. Denied at the configuration level, so the answer does not depend on your attention at the time.

The point of the deny list is that it holds when you are tired.

Deny is not distrust

The reasoning has nothing to do with the model being malicious. A wrong action in these categories is expensive to reverse, and the cost of being asked is trivial by comparison.

A denied operation still leaves the task open. It becomes a proposal: the agent says what it would run, and you run it. For anything irreversible that is the better division regardless of who is proposing.

Narrow beats broad

Where a tool supports scoping, scope it. Allowing a specific command with specific arguments is a different grant from allowing arbitrary shell access, and the second is what people mean when they later say they did not realise what they had approved.

Prefer several narrow allowances to one broad one, even though it takes longer to set up. The setup happens once; the exposure lasts.

Where the buckets live

The three buckets are a way of thinking. Each tool spells them differently, and the spelling decides whether a posture you set in one carries to another.

Claude Code keeps allow, ask and deny rules in its settings, and deny wins. The rules govern Claude's own tools; a deny on a file does not reach a script Claude runs that opens the file itself, and the documented answer for that case is the sandbox. Details in the permissions reference and on secrets and context.

Codex splits the job into two controls: a sandbox that defines which files and network the agent can reach, and an approvals policy that decides when it pauses. Three named modes combine them. Ask for approval works inside the workspace and asks to go beyond it. Approve for me keeps the same boundary and sends boundary-crossing requests to automatic review, which the documentation says "can make mistakes". Full access removes both, with the vendor's own warning attached. The sentence to keep is theirs: "Changing who reviews a request doesn't expand the sandbox". So the sandbox is your deny bucket, approvals are your gate, and the mode picker chooses the reviewer while the boundary stays put.

Gemini CLI puts the buckets in a policy engine: TOML rules that name a tool or a command prefix and carry allow, deny or ask_user, highest priority winning. A deny there removes the tool from what the model can see at all. An ask_user becomes a deny when the CLI runs without a person, which is the right default for a pipeline and a surprise the first time. Rules live at the user or administrator tier; the project tier is documented as non-functional, so a policy file committed to a repository does nothing. The sandbox is a separate switch, and Trusted Folders — off by default — is what stops a cloned repository's configuration loading before you have read it.

Whatever the tool, the review-after-a-week rule above applies unchanged. The buckets are yours; only the syntax belongs to the vendor.

Permissions and prompt injection

The connection people miss. An injection can only do what the session is already permitted to do — see Prompt injection, explained. Content that tricks the model into attempting something denied at the configuration level achieves nothing.

That makes your permission posture a security control, well beyond a convenience setting, and it is the control that keeps working when the classifiers do not.

Review after a week, not before

The right posture is discovered rather than designed. After a week, look at what you approved repeatedly and move it to allow, and look at what made you hesitate and move it to gate or deny.

Anything you approved without reading is the finding. It means either the prompt is firing too often to be meaningful, or the operation belongs on the allow list and the prompt is noise.

What goes wrong

Approving everything for a week to get going. The habit forms, and the prompt stops being a control.

Broad grants for one task. They persist long after the task.

No deny list. Every irreversible operation then depends on reading a prompt carefully at the exact moment you are least likely to.

Treating a prompt as a review. It tells you what is about to happen, not whether it is correct.

Setting the posture once and never revisiting it. Your repositories and your habits both change.

How to check it worked

Count the prompts in a typical session. If there are more than a handful, the allow list is too narrow and you are training yourself to click through. If there are none at all, check what you granted — a session with no prompts is usually a session with a broad grant behind it.