Security Without Paranoia — What Actually Belongs in Deny Rules
Over-restricting Claude Code is a real cost, not a free safety net. This article draws the line between rules that pay for themselves and rules that create friction without meaningful protection.
Quick Reference
- →Claude Code is not adversarial — the threat model is accidents, not malice
- →The real external risk: prompt injection via file content or MCP tool results
- →What already needs no deny rule: system files, files outside project, most network requests
- →What genuinely needs deny rules: .env files, force-push to main, database drop commands
- →Over-restriction tax: slow sessions, constant interruptions, developers bypassing tools entirely
- →Per-environment profiles: local (permissive), CI (locked down), production (never run Claude there)
- →CLAUDE.md is advice; deny rules are enforcement — know which one the situation needs
- →Deny rule principle: high cost-of-mistake + low legitimate use = deny rule
The Trust Model: Claude Code Is Not Adversarial
The first thing to understand about Claude Code's security model is that Claude itself is not the threat. Claude Code is not trying to escape its sandbox, exfiltrate your data, or execute malicious code. It does what it's asked, using tools you've authorized.
The realistic risks are two things: (1) accidental damage from legitimate tasks gone wrong — Claude misunderstands scope and deletes more than intended, or runs a command against the wrong environment. (2) Prompt injection — malicious instructions embedded in files Claude reads, MCP tool results, or web pages Claude fetches, steering it toward actions it wouldn't otherwise take.
Claude Code runs as your user process — it has exactly your filesystem permissions, nothing more. It cannot escalate privileges, access files your user can't access, or escape to the network in ways your terminal can't. This is already a substantial boundary.