Claude Code security means deliberately setting several layers instead of relying on one. The permission mode decides what Claude may do without asking; according to Anthropic, since version 2.1.283 Claude Code starts in the terminal in auto mode, where a separate classifier model blocks risky actions; if you want to approve every action yourself, use Manual. Allow, ask and deny rules in your settings are enforced by Claude Code itself, not by the model, and a deny rule always wins. The sandbox limits shell commands at operating system level, but it is off by default. Hooks block what must never happen. Secrets belong in environment variables or encrypted files, never in prompts, and you lock .env files with a deny rule. Outside content, MCP servers and plugins are risks of their own. For reviews, Anthropic offers /security-review, two plugins and, on Enterprise, Claude Security.
I run a workforce of AI employees on Claude Code, partly on my own server, with real access to accounts and data. Everything technical here comes from Anthropic's documentation, retrieved on October 26, 2026; the other building blocks of my setup are collected on the Claude page.
The core principle: Claude Code enforces the rules, not the model
The most important sentence in the whole permissions documentation sits in a note box: "Permission rules are enforced by Claude Code, not by the model." An instruction in your CLAUDE.md or prompt shapes what Claude tries to do. What Claude Code actually allows is decided by settings, mode, sandbox and hooks.
"Please don't delete anything" in a work instruction is a request; "deny": ["Bash(rm *)"] in settings.json is a boundary. That is why the rule in my workforce is: whatever an employee must not do, I block technically.
Permission modes: how much Claude may do without asking
According to Anthropic, Claude Code has six modes:
Since version 2.1.283, auto is the built-in starting mode for terminal and VS Code sessions; for claude -p and the Agent SDK it stays default. Per the docs, the classifier blocks by default, among other things, curl | bash, sending sensitive data to external endpoints, production deploys, force pushes and irreversibly destroying files that existed before the session. But Anthropic itself writes: "Auto mode reduces permission prompts but does not guarantee safety." For sensitive work, Manual is the right mode.
bypassPermissions, meaning a start with --dangerously-skip-permissions, belongs, per the docs, only in environments "like containers or VMs where Claude Code can't cause damage". Some things Claude Code never auto-approves in any mode, such as removals of critical paths like rm -rf ~, though per the docs the check can miss some commands. And writes to protected paths such as .git and .claude are never auto-approved except in bypassPermissions.
On my server I explicitly start my employees' sessions with --permission-mode acceptEdits, and unattended runs also get a fixed mode and a budget cap, for example claude -p --permission-mode acceptEdits --max-turns 60 --max-budget-usd 5. I set the mode myself instead of relying on the built-in starting mode. The full picture is in Claude Code on a Server: tmux, Remote Control. I steer these sessions via Remote Control. According to Anthropic, execution and file access stay on the machine itself, but while connected the transcript is stored on Anthropic's servers. I accepted that deliberately, with a Team account under commercial terms; more in Claude Code Remote Control from Your Phone.
Allow, ask, deny: rules that actually hold
Rules refine the mode. In the settings documentation, Anthropic shows this example for ~/.claude/settings.json:
{
"permissions": {
"allow": [
"Bash(npm run lint)",
"Bash(npm run test *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)"
]
}
}
Three rules from the docs are worth knowing:
- The order is fixed: deny first, then ask, then allow. "An allow rule can't carve an exception out of a deny rule." A deny rule from any level beats an allow rule from any other.
- Deny works in every mode, including
bypassPermissions. Allow rules, by contrast, have no effect in bypassPermissions.
- A bare tool name removes the tool. A deny rule like
Bash takes the tool out of Claude's context; a scoped one like Bash(rm *) only blocks matching calls. Note that a Bash rule matches the command as written; for reliable network limits, Anthropic points to the sandbox.
A case from my own setup: for SE Ranking, according to the vendor, our key has the same rights as the whole account. So among the MCP server's 236 tools there are ones that delete things. I blocked 28 of them with deny rules by full name, for example mcp__se-ranking__PROJECT_deleteProject. Why individually and not by pattern is in Claude SEO: SEO With Claude Code, Skills, MCP.
One trap concerns projects you did not write yourself. Claude Code only applies allow rules from a foreign repository's .claude/settings.json once you trust the folder in the trust dialog; deny and ask rules apply immediately, because they only restrict. Hooks from a repository's settings, however, run per the docs even if you only trusted a parent folder, and in claude -p without any dialog. Before running claude -p in a repository you did not write, Anthropic therefore recommends, among other things, --settings '{"disableAllHooks": true}' or --setting-sources user.
Sandbox: limits at operating system level
According to Anthropic, the sandbox is "a boundary that the operating system enforces around the shell commands Claude runs on your machine". It runs on macOS, Linux and WSL2, not on native Windows, and it is off by default. You turn it on with /sandbox, or permanently with "sandbox": {"enabled": true} in your settings.
What it does and does not do by default matters:
- Writes only in the working folder, a temp folder and folders you added.
- Network only through a local proxy that checks every host against your list of allowed domains; the list starts empty.
- Reads, on the other hand, almost everywhere, explicitly including
~/.ssh and ~/.aws/credentials, unless you block them.
- Environment variables are inherited, "including any secrets in its environment".
For the last two points there is the sandbox.credentials block: files and variables with "mode": "deny" are blocked for sandboxed commands, and variables are removed before each command. According to the docs there is no built-in deny list; only what you list is protected.
One thing matters here: if a command fails inside the sandbox, Claude may, per the docs, retry it outside the sandbox. In Manual mode Claude Code then asks you, in auto mode the classifier decides, and a matching allow rule lets it through without a prompt. If the sandbox is meant to be a hard boundary, set "allowUnsandboxedCommands": false.
And the sandbox only wraps shell commands. Claude's file tools follow the permission rules, while hooks, local MCP servers and helper commands run, per the docs, "with your full access". To put everything behind one boundary, run Claude Code as a whole inside a container or VM.
Hooks as guardrails
A hook is a command Claude Code always runs at fixed points. For security, PreToolUse matters most: it runs before every tool call and can deny it. Per the docs: "A blocking hook also takes precedence over allow rules." A hook that exits with code 2 stops the call before permission rules are evaluated. Conversely, an allow from a hook does not override a deny or ask rule.
Anthropic's guide shows an example hook that blocks edits to .env, package-lock.json and anything under .git/. How to set one up is in Claude Code Hooks: Rules That Always Apply. A hook is itself code running with your privileges, though; read hooks from foreign projects and plugins before you let them run.
Secrets: never in plain text
Keys, tokens and passwords do not belong in prompts, in CLAUDE.md, or in files Claude may read. Three reasons from the docs:
- Sessions are stored locally in plain text. According to Anthropic, Claude Code stores sessions for 30 days "locally in plaintext under
~/.claude/projects/". A key you paste into the chat ends up there too.
- The sandbox inherits your environment. Without
sandbox.credentials, commands see every variable you exported.
- There is no
.claudeignore. Per the docs, such a file has "no effect"; you block files with a Read deny rule such as Read(./.env) or Read(./secrets/**).
Per the docs, Claude Code stores its own credentials in the macOS Keychain, and on Linux in a file with mode 0600. For your own keys the familiar rule applies: environment variable instead of code, .env in Git's ignore list. What that looks like for an API key is in Claude API Key: Setup, Pricing, First Call.
In my setup, all credentials sit in the repository, encrypted with SOPS. The server has its own age key as a second recipient; my private key is never on it. At install time a script decrypts only the respective employee's credentials into a .env file that Git ignores and only the work user can read; configuration files such as .mcp.json contain only placeholders like ${API_KEY} in the repository. To be honest about it: a secret scan with gitleaks before every push is a rule in our rulebook, not an automatic check.
Prompt injection from outside content
According to Anthropic, prompt injection is "a technique where an attacker attempts to override or manipulate an AI assistant's instructions by inserting malicious text". It can hide in a web page, an issue, a PDF or an email that Claude reads. Per the security docs, Claude Code has several layers of protection: network commands like curl and wget are not auto-approved, WebFetch usually gives Claude a summary instead of the raw page, commands Claude Code cannot fully analyze trigger a prompt in Manual mode, and the classifier in auto mode blocks actions that appear driven by hostile content.
Anthropic's own advice for outside content is short: review commands before approval, avoid piping untrusted content directly to Claude, verify changes to critical files, and use VMs for scripts and tool calls that touch external services. And: "no system is completely immune to all attacks."
For my workforce this means: whatever an employee must not do, I block technically, for example an MCP server's deleting tools with deny rules. And anything that leaves the house or changes something, an email send, a deploy, an ad, only goes out with my explicit word, which the employee records with a timestamp in the log.
MCP servers and plugins: outside code with your privileges
On MCP servers, Anthropic writes: "We encourage either writing your own MCP servers or using MCP servers from providers that you trust." Anthropic reviews connectors before adding them to its directory, "but does not security-audit or manage any MCP server". Claude Code asks before connecting servers from a project's .mcp.json; per the docs, with claude -p in a never-trusted folder it connects them without asking. How to set up servers and which rights to give them is in Set Up a Claude MCP Server.
Plugins reach even further. The plugin docs open with: "A Claude Code plugin you install can execute arbitrary code on your machine with your user privileges." A plugin can bring hooks, background processes, MCP servers and executables, and with auto-update on, the files you reviewed can change in the background. Per the docs, permission rules and sandbox cover the tool calls Claude makes, not the code a plugin runs by itself. What to check before installing is in Claude Code Plugins: Install, Build, Trust.
Security reviews: four tools from Anthropic
Anthropic's docs present the review tools as layers:
The honest limits Anthropic names itself matter. The security-guidance plugin has Claude's code reviewed by a separate call "with a fresh context", but it blocks nothing: "None of the layers block writes or commits." /security-review needs a remote named origin. And of Code Review: "A review with no findings doesn't mean your code is error-free or secure." I describe the Code Review flow in Claude Code Review: Cost, Setup, Limits.
That fits a house rule I apply to everything: whoever creates something does not check it themselves. With Sebastian, my SEO employee, a separate reviewer role checks the report against the raw data before I see it. A security review is the same idea, applied to code.
For teams and companies
For organizations, Anthropic recommends managed settings that users and projects cannot override. With them you can, for example, switch off bypassPermissions and auto (permissions.disableBypassPermissionsMode and permissions.disableAutoMode set to "disable"), enforce permission rules centrally, restrict which MCP servers may run, and enable plugins for everyone. For monitoring, the docs name OpenTelemetry metrics and ConfigChange hooks.
On Enterprise there is also Claude Security. On claude.com it says: "Claude scans your codebase with Claude Mythos, validates findings, and suggests patches you can review and approve. Available in public beta for Claude Enterprise." The plugin of the same name for Claude Code, by contrast, uses the models in your account, not Mythos. What else sets Enterprise apart is in Claude Enterprise or Team: Cost and GDPR.
Frequently asked questions
Is Claude Code secure?
As secure as you configure it. Anthropic builds in several layers of protection, but says itself that no system is immune to all attacks and that you are responsible for reviewing proposed commands. With deny rules for anything critical, the sandbox switched on and secrets out of Claude's reach, you lower the risk.
What is the safest permission mode?
For work where you are present, Manual (default): Claude may only read and asks before anything else. For scripts and CI, dontAsk with an exact allowlist is the intended mode. According to Anthropic, bypassPermissions belongs only in containers or VMs.
How do I stop Claude Code from reading my .env?
With deny rules such as Read(./.env) and Read(./.env.*) in settings.json. For sandboxed commands, also block files and variables via sandbox.credentials. A .claudeignore has no effect, per the docs.
What is Claude Security?
A product from Anthropic that scans repositories for vulnerabilities with Claude Mythos, validates findings and suggests patches; per claude.com it is "available in public beta for Claude Enterprise". The claude-security plugin for Claude Code, by contrast, is in beta for all Claude Code users.
What does /security-review do?
According to Anthropic, it checks the changes on your current branch against the default branch on origin, for example for injection, authentication flaws and data exposure. It is a single on-demand pass, not ongoing protection.
Where to go from here
Start with three steps: deny rules for .env and anything that must never happen, the sandbox switched on with /sandbox and sealed with "allowUnsandboxedCommands": false, and your secrets moved out of prompts and readable files. After that, look at Claude Code Hooks: Rules That Always Apply and the privacy side in Claude Privacy and GDPR: What Applies. If you are comparing Claude Code with other tools, Claude Code vs Cursor: Which Fits You? and Claude vs Copilot for Coding: Which One? help. And how I organize approvals, credentials and reviewer roles in my workforce is what I show in my German-speaking community Claude Practitioners.
