Security

How Claude Code keeps you in control: permission modes, built-in protections, prompt injection defences, MCP and cloud security, and team best practice.

Claude Code runs commands and edits files on your behalf, so the security question is really "what can it do without me noticing?" This page walks through the layers that answer that: permission modes, built-in guard rails, prompt injection defences, and what changes when sessions run in the cloud. It finishes with the habits I use on client repositories.

Anthropic publishes its certifications (SOC 2 Type 2, ISO 27001 and others) on the Anthropic Trust Center.

Permission modes decide what runs unasked

Every session has a permission mode. For interactive terminal and VS Code sessions the built-in starting mode is auto mode; Permission modes explains how earlier versions, other surfaces and your settings change that.

Mode	What happens before an action runs
Auto	A separate classifier model reviews actions in your place and blocks those it judges unsafe. Your explicit ask and deny rules still apply, and an organisation can switch auto mode off
Manual	Claude starts read-only. Edits, tests and commands prompt you, and you approve once or allow from then on. A built-in set of read-only commands such as `ls`, `cat` and `git status` runs without asking
Accept Edits	File edits plus a fixed set of filesystem commands (`mkdir`, `touch`, `rm`, `mv`, `cp`, `sed`) are approved for paths inside the working directory. Everything else still prompts

You and your organisation write the rules that feed these modes; Permissions covers the syntax. Whatever the mode, you remain responsible for reviewing code and commands before you approve them.

Built-in protections

Sandboxed Bash. Sandboxing wraps commands in filesystem and network isolation, so Claude can work freely inside a boundary you define with /sandbox, with fewer prompts.
Working directory boundary. In manual mode, file tools ask before reading or writing outside the folder Claude started in. This is a prompt, not an OS control: a Bash command you approve can still write anywhere your account can. Add folders as additional directories (see Permissions) to read them without prompting, or turn on sandboxing for real enforcement.
Allowlists against prompt fatigue. Frequently used safe commands can be allowed per user, per project or across the organisation, so the prompts you do see are worth reading.

Prompt injection

Prompt injection is someone planting instructions in content Claude reads, such as a README, an issue comment or a web page, hoping Claude will follow them. Claude Code layers several defences.

Core controls

In manual mode, sensitive operations need your explicit approval.
Commands that fetch from the web, such as curl and wget, are never auto-approved by default. You can approve them once or allow them with a rule like Bash(curl *). To stop them entirely, add them to permissions.deny. A deny rule matches the command text as written, so for enforcement that does not depend on wording, use the sandbox's network isolation.

Further safeguards

Network approval. In manual mode most tools that hit the network need approval.
Summarised web pages. For most fetches, WebFetch runs a separate model call over the page and Claude only sees that call's answer, not the raw HTML. See Tools reference.
Trust prompts. Starting an interactive session in an untrusted folder shows the workspace trust dialog, and servers in a project's .mcp.json get their own approval. A -p session shows neither, so check what a repository's files can run before automating against it. If you start Claude Code in your home directory, trust is held for that session only and the prompt returns every launch; start from a project folder instead.
Command injection detection. In manual mode Claude Code asks before running a Bash command it cannot fully analyse. A partial allow rule such as Bash(git *) does not bypass that; sandboxed commands can.
Fail-closed matching. In manual mode anything not matched by a rule needs approval.
Credential storage. Keys and tokens go in the macOS Keychain where available, a mode 0600 file on Linux, and a file inheriting your profile directory's access controls on Windows. See Authentication.

Warning: On Windows, avoid enabling WebDAV or letting Claude Code touch paths such as \\* that might contain WebDAV locations. Microsoft has deprecated WebDAV, and it can let Claude Code trigger requests to remote hosts that bypass the permission system.

Working with untrusted content, I follow five rules:

Read every proposed command before approving it.
Do not pipe untrusted content straight into Claude.
Check changes to critical files (CI config, auth code, lockfiles) line by line.
Run scripts and tool calls in a VM or container when they talk to external services. Sandbox environments and dev containers make this easy.
Report anything odd with /feedback.

None of this makes any AI tool immune; it lowers the odds and the blast radius.

MCP servers

Project-scoped MCP servers live in .mcp.json, which you can commit. But servers can also come from user or local scopes, claude.ai connectors and plugins, so reading .mcp.json does not show everything a session might load. Use managed MCP to restrict which servers your organisation allows.

Write your own servers or use ones from providers you trust, and set permissions for their tools. Anthropic reviews connectors against listing criteria before adding them to its directory, but it does not security-audit or manage any MCP server. See MCP.

IDE use

The VS Code extension has its own security and privacy notes; see VS Code.

Cloud sessions

Cloud sessions add controls of their own. If your organisation routes them to a self-hosted environment, isolation, egress and git credentials become your deployment's responsibility. In Anthropic-hosted environments:

Isolation. Each session gets its own Anthropic-managed VM.
Network. Access is limited by default and can be disabled or restricted to listed domains (see Cloud environments).
GitHub credentials are stored encrypted on Anthropic's servers and never enter the VM. The VM holds a short-lived, session-scoped credential, and GitHub traffic passes through an Anthropic proxy that attaches the real credential server-side.
Push limits. The proxy refuses branch deletions and pushes of anything that is not a branch, such as tags. Which branches a session can update is decided by your branch protection rules and rulesets as applied to the GitHub access you connected; a rule that access can bypass will not block a push.
Audit logging of all operations.
Cleanup. Idle VMs are reclaimed, and you can delete a session whenever you like. Data usage covers what is stored.

Remote Control is different: the browser drives a Claude Code process on your own machine. Execution and file access stay local, traffic goes over TLS through the Anthropic API, and while connected the transcript is held on Anthropic servers to sync between devices. It uses several short-lived, narrowly scoped credentials that expire independently, limiting the damage from any one being compromised.

Best practice

Sensitive repositories

Review every change before approving.
Give sensitive repos their own project permission settings.
For stronger isolation, run the whole Claude Code process inside the sandbox runtime or a dev container.
Audit your rules periodically with /permissions.

Across a team

Enforce standards with managed settings.
Share approved permission configurations through version control.
Train people on the risks, not just the commands.
Watch usage with OpenTelemetry metrics.
Audit or block mid-session settings changes with a ConfigChange hook (see Hooks).

For code-level checks, the security guidance plugin reviews Claude's own changes during a session, and /security-review runs an on-demand pass over your branch.

Reporting a vulnerability

Do not disclose it publicly. Report it through Anthropic's HackerOne programme with clear reproduction steps, and give them time to fix it before going public.