Claude Code permission rules vs hooks vs sandboxing: which actually stops dangerous commands?

Three layers, three different questions#

Permission rules ask whether the command text matches something you listed. The sandbox asks what the process can touch. A hook asks what your script thinks of the call.

None of them asks the question you care about: should this action run, given what the developer actually asked for?

Permission rules match the text#

You can write allow and deny rules for Claude Code and check them into version control to share across the org. A deny rule on a known-bad command stops that command as typed.

The catch is that a rule matches the command as written. A deny aimed at one way of typing a delete doesn't cover the same delete done with find -delete, a Python one-liner or a wrapper script. Allow rules break the other way: one write-up shows git -C /path status failing to match an allow rule for git status. So you get gaps and friction at the same time.

Then there's the human answering the prompt. In Anthropic's study of 1,053 paid testers, people caught the dangerous command 13.6% of the time. Anthropic also reports users accept 93% of permission prompts anyway.

The sandbox limits reach, not intent#

The sandbox bounds what a command's process can get to, including which hosts it can call through a proxy with an allowed-domains list. That's a real control. Per Anthropic's sandboxing docs, it's off by default, so check that it's actually on across your fleet before you count on it.

The network allowlist deserves a second read. The docs warn that allowing a broad domain like github.com can create paths for data exfiltration. They also note the proxy decides from the client-supplied hostname without inspecting TLS, so code inside the sandbox could use domain fronting to reach hosts outside the list.

The sandbox doesn't judge the command either. A command allowed to reach an approved host can still send a secret there, and a destructive command inside the allowed area is still allowed. Read the vendor docs for the current defaults; they change.

Hooks are a gate you have to build#

A PreToolUse hook runs before a tool call, and exit code 2 blocks the action. That's the right place to put a check.

But the hook is a script you own, and the docs spell out the edges:

• Exit 0 with no output means no decision, so the call continues through the normal permission flow.
• Administrators can set allowManagedHooksOnly in managed settings to restrict which hooks run.

A hook that greps for rm -rf has the same blind spot as the deny rule. The mechanism is sound. The quality of the check is on you, and so is what happens when the check errors out.

The decision rule#

Ask two things about every layer: what does it read, and what happens when it can't decide?

A layered setup#

• Turn the sandbox on and confirm it's on for every developer, not only the ones who read the docs.
• Keep allowed domains narrow. Treat any broad host as an exfiltration path.
• Keep hard denies for the commands you never want, knowing they only catch the written form.
• Restrict hooks to managed ones with allowManagedHooksOnly, and make the hook the single place every action gets checked.
• Make that check read the action, not a keyword, and make it return an explicit decision every time.
• Keep least privilege and scoped credentials underneath all of it. No check replaces them.

Where Harden fits#

Harden Agentic Integrity Foundation (AIF) is a check built for that hook. It runs on the developer laptop, outside the agent, at the agent's pre-execution hook, and checks every command, file edit and push against the session's intent before it runs. Decisions are made locally, in milliseconds, and nothing leaves the machine.

One policy covers every agent, and it starts watch-only, so you can see what agents do before you enforce anything.

It's a layer, not a perimeter. It doesn't replace the sandbox, least privilege or egress policy, and exfiltration split across several separate calls is the hard case. See how to stop coding agents running destructive commands and the security review checklist.