Claude Code Security and Compliance: Data, Controls, Risks

Anthropic's data usage page draws the line between consumer and commercial terms:

• Consumer (Free, Pro, Max): you choose whether your data may be used to improve future models, and that includes Claude Code usage from those accounts. If you allow it, data is retained for five years; if you do not, 30 days. You can change the setting at any time in claude.ai's privacy controls.
• Commercial (Team, Enterprise, API, third-party platforms): Anthropic does not train generative models on code or prompts sent to Claude Code under commercial terms, unless the customer opts in, for example through the Development Partner Program. Standard retention is 30 days.
• Zero Data Retention is available to qualified accounts for Claude Code on Claude for Enterprise. It is not part of the standard Enterprise plan; your account team enables it per organisation after confirming eligibility.

Two exceptions are easy to miss. Transcripts you send with /feedback, /bug, or /share are retained for five years. And if you answer Yes to the optional "Can Anthropic look at your session transcript?" follow-up after a session survey, the transcript, subagent transcripts, and raw session log are uploaded (with known key patterns redacted) and kept for up to six months.

Data in transit is encrypted with TLS 1.2 or later. At rest, the Anthropic API uses AES-256 infrastructure-level disk encryption; Bedrock uses AES-256 with AWS-managed keys or your own KMS keys; Google Cloud uses Google-managed keys with CMEK available; Microsoft Foundry depends on the deployment's hosting option.

Claude Code runs locally and keeps plaintext session transcripts under ~/.claude/projects/ for 30 days by default so sessions can be resumed. Anything a tool touched is in them: file contents, command output, pasted text. If Claude reads .env or a command prints a token, that value is now on disk in plain text, protected only by file permissions. Prompt history in ~/.claude/history.jsonl is kept until deleted.

For regulated environments:

• Lower cleanupPeriodDays (minimum 1). Set it in managed settings to apply it fleet-wide.
• Deny reads of secret files with permission rules, for example Read(./.env), Read(./.env.*), Read(~/.aws/**).
• Set CLAUDE_CODE_SKIP_PROMPT_HISTORY to skip writing transcripts and prompt history, or pass --no-session-persistence with -p in automation.
• Use claude purge to delete one project's local state.

Credentials are stored in the macOS Keychain when available, in a 0600 file on Linux, and in a file inheriting your profile directory's permissions on Windows.

Claude Code sends two kinds of operational telemetry. Metrics cover latency, reliability, and usage patterns and, per the docs, never include code, prompts, or file paths. Error reports contain Claude Code's own error messages and stack traces, with known secret, path, email, and personal-information patterns redacted before sending.

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 turns off all non-essential traffic at once, including surveys. It does not affect the WebFetch domain safety check, which sends only the hostname (not the URL or content) to api.anthropic.com to check a blocklist, or the official plugin marketplace auto-install; each has its own switch. Disabling telemetry also disables feature-flag evaluation, which can make features such as Remote Control unavailable.

All of these variables can be set in the env block of managed settings, so they apply to every machine.

The client's protections, as the security page describes them:

• Permission modes. Auto mode (the starting mode in interactive terminal and VS Code sessions on recent versions) has a classifier review actions and block those it judges unsafe; your ask and deny rules still apply, and organisations can disable it. Manual mode starts read-only and asks before edits and commands, except a built-in set of read-only commands such as ls, cat, and git status.
• Working directory boundary. In Manual mode, file tools ask before reading or writing outside the starting folder. The docs are explicit that this is a permission prompt, not a sandbox: a Bash command you approve can still write anywhere your user account can.
• Sandboxed Bash with filesystem and network isolation, configured with /sandbox, is the operating-system-level control.
• Command injection detection and fail-closed matching. Commands Claude Code cannot fully analyse prompt even if part of them matches an allow rule, and unmatched commands require approval.
• Network commands such as curl and wget are not auto-approved by default.
• Trust verification. Interactive sessions show a workspace trust dialog in an untrusted folder, and project MCP servers have their own approval. A claude -p session shows neither prompt, so repository hooks and MCP servers can run in a folder no one reviewed.

The docs close with a plain warning: these protections significantly reduce risk, but no system is completely immune, and the user remains responsible for reviewing proposed code and commands.

Prompt injection is text in a file, web page, issue, or tool result that tries to redirect the agent. Claude Code's defences include the permission system, network-command approval, and WebFetch's design: for most fetches a separate model call reads the page and Claude receives that call's answer, not the raw page. Anthropic's recommendations for untrusted content are to review commands before approving them, avoid piping untrusted content straight into Claude, verify changes to critical files, use virtual machines for scripts and tool calls that touch external services, and report suspicious behaviour with /feedback.

MCP servers are a supply-chain question. Anthropic reviews connectors against listing criteria for its directory, but does not security-audit or manage any MCP server. Servers can come from .mcp.json, user and local scopes, claude.ai connectors, and plugins, so reviewing .mcp.json alone does not show everything a session can load. Organisations restrict servers with managed MCP configuration (allowManagedMcpServersOnly with allowedMcpServers).

Cloud sessions run in isolated Anthropic-managed VMs with limited network access by default. GitHub credentials stay encrypted on Anthropic's servers and never enter the VM; a proxy attaches them and rejects branch deletions and tag pushes. All operations are logged for audit, and VMs are reclaimed after inactivity.

These are the decisions a security team usually makes before broad rollout. Most are managed-settings keys, which means they are enforced on the client and depend on the policy reaching each machine; verify delivery with claude doctor and a deliberately blocked action, as described in the enterprise setup guide.

Remember the documented boundary of client-side policy: a user with a modified client can bypass any client-side control, and some configurations (custom base URLs, provider variables) skip server-managed settings entirely. For controls that must hold against a determined user, combine managed settings with credentials scoped to what developers may touch, network egress rules, and MDM-protected settings files.

Work through this with one developer machine and your security team.

1. Confirm the account type with /status: commercial organisation login, not a personal Pro or Max account. 2. Search existing transcripts for secrets: grep -l "BEGIN RSA\|AWS_SECRET\|API_KEY" ~/.claude/projects/*/*.jsonl. Rotate anything found. 3. Write a draft managed policy with the checklist keys above and install it on a test machine. 4. Verify: .env cannot be read, --dangerously-skip-permissions is refused, an unlisted MCP server does not load, and curl example.com inside the sandbox is blocked unless the domain is allowed. 5. Set CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 and confirm with your network monitoring which hosts the client still contacts. 6. Record which controls are client-side only and which have a server or OS-level backstop.

Pass criterion: every checklist control was tested with an action that should fail, and the review notes state the residual risks honestly.