What an agent should never be allowed to do

Most permission setups get built around convenience: what's annoying to approve every time gets auto-allowed, and everything else prompts. That's backwards. The question that should sort an action into a ring isn't "how often does this happen" — it's "what happens if the agent is confidently wrong."

Sort by damage, not by frequency

Reading a file, running the test suite, searching the codebase: low blast radius even when wrong, because the failure mode is "wasted a few seconds." Installing a dependency or deleting a file: real damage, but recoverable, and worth a pause. Force-pushing over shared history, reading production credentials, running a destructive migration: the failure mode is unrecoverable or silent, and no amount of "the agent was probably right" makes that an acceptable bet. Those three tiers are the always / ask / never rings in the figure — the innermost ring holds the smallest number of actions and the largest possible damage.

What this looks like as actual rules

Claude Code's permission system implements roughly this shape directly: deny rules, ask rules, and allow rules, evaluated in that order — deny first, then ask, then allow — so a broad deny always wins over a narrower allow, regardless of which rule is more specific (Claude Code permissions docs). That ordering is the point: you don't get to allowlist an exception to a deny rule, which is exactly what you want for the never ring. A minimal deny list for a coding agent:

{
  "permissions": {
    "deny": ["Bash(git push --force*)", "Read(**/.env)", "Read(~/.aws/**)"]
  }
}

The "ask" ring is doing the least glamorous but most load-bearing work here: it's where a human actually reads what's about to happen, which only works if ask stays reserved for actions worth reading about. Move too much into always for convenience, and the one prompt you do get stops being informative because you've trained yourself to click through it.

The sandbox ring is different from the other three

The outer dashed ring in the figure isn't a permission level — it's a container. Claude Code's bypassPermissions mode, which skips prompts entirely, is documented as safe only "in isolated environments like containers or VMs where Claude Code can't cause damage" (same docs). That's the right way to read the whole diagram: the never ring is about what you refuse to auto-approve on a machine that matters; a sandbox is what you use when you want to skip asking altogether, by making the blast radius of "never" harmless.

Try it today

1. List the five most damaging things your agent's current toolset could do — not the most common, the most damaging.
2. Write a deny rule for each one, scoped as narrowly as the tool allows (a path pattern, not a bare tool name, unless you want it gone entirely).
3. Check your permission config for any allow rule that could match one of those five — if deny wins by ordering in your tool, this is now dead code, but it's worth removing anyway to avoid confusion later.
4. Pick the one recurring task that's annoying to keep approving and move it to always, only after confirming its damage is genuinely low.
5. If you run anything in bypass or auto-approve mode, confirm it's inside a container or VM, not your main machine.

Where this breaks

• A deny rule scoped too narrowly (an exact path instead of a pattern) is trivial to route around by mistake, not even maliciously.
• "Ask" rings still depend on a human reading the prompt carefully; a habit of reflexively approving degrades the whole tier back to "always."
• Sandboxing contains file and process damage, not necessarily network egress — a contained agent with an API key can still cause external damage.

Next: keep a mistake log.