Don't let an LLM gate its own dangerous actions

Scope the model's credential so the dangerous action physically fails. A read-only API token returns an error on any write. The model can't send at all, so there's nothing for it to decide. This is the difference between "is told not to" and "is unable to."

The action that actually sends or writes runs in a separate, non-LLM process that holds the write credential. It can't be prompt-injected because it doesn't reason. It just executes. It re-derives authorization from authoritative sources (a state file, the live approval channel), never from anything the model hands it, checks idempotency, then acts.

The "require human approval" rule lives in the workflow, not the system prompt. It fires on what the action is, such as a customer-facing send, never on what the model inferred about whether approval is needed. The model can propose; only the deterministic layer disposes.

When the gate reads a field the model filled in, an exact match fails open. A check for "hold" lets "Hold", "HOLD", and "hold, because the customer sounds upset" straight through, and the blocked action goes ahead. Lowercase the value, trim it, match the prefix, and treat anything you don't recognize as a stop.

A gate that blocks correctly but leaves no way to resolve the item fires again on every run. People learn to ignore it, which is the exact failure the gate was built to prevent. Each refusal needs a clear path to resolution and an alert that goes out one time. Check that the fix the alert names can actually be reached.

In Claude Code, the --allowedTools flag pre-approves tools so they run without a prompt. It never takes a tool away. Hand it a short list of read-only tools on a machine whose settings already allow writes, and the job can still write. It reads like a sandbox and often isn't one.

To actually restrict, use --tools to limit which built-in tools exist, --disallowedTools to remove or deny specific ones (MCP tools included), or ask and deny rules in your settings, which beat allow rules.

For file writes there is now a setting that does exactly this. Since v2.1.314 (October 2026), permissions.blockWritesOutsideWorkingDirectories makes Write and Edit refuse any path outside the folders you're working in, in every permission mode.

One caveat changes the picture. A settings hook in Claude Code can block a call or force a prompt, but its "allow" can't override an ask or deny rule. Since v2.1.287 (October 2026), plugin "mods" can. A mod that handles tool checks answers after your rules and hooks, and it can approve a call an ask rule would have prompted for.

Whether it can also overrule your hooks and deny rules depends on how the session is signed in, not on which file a rule lives in. On a machine with managed settings, or in a session signed in to a Team or Enterprise plan, a call your hook blocked stays blocked, and deny rules hold unless your organization changes that default. A session running on an API key doesn't count. With neither, a mod can approve past both. Mods are on by default. Check the current permissions docs before you rely on any of this.

The exit code is not evidence. A job I had scoped to read-only tools with that allow-list flag wrote a file to disk and reported success. Only checking whether the file existed caught it. After any test of a boundary, look at what actually changed in the world.

A guard that ships with its own self-test proves very little. A truncated or swapped-out copy that exits cleanly on every input passes its own self-test and then permits everything. The caller should test the guard with one input it must allow and one it must refuse. Test only the bad case, and a guard that refuses everything scores perfectly.