Claude Code security best practices for engineering teams (2026)

Executive summary

• Team rollout checklist for Claude Code, layered by control (managed settings → permissions → sandbox → hooks → MCP → transcripts → gateway → audit), each with an honest “what it misses” line.
• When the hook runs, recognized .env / *.env access is fail-closed (sanitize Read, block Bash dumps, or deny if the file cannot be inspected). Hook process crashes/timeouts and egress-backend errors can still fail open unless you set Claude’s onFailure: "block".
• Claude Code’s local transcript path is ~/.claude/projects/; provider transcripts may still hold unredacted content.
• Coverage detection tells you when hooks are missing—it is detection, not MDM.

Securing Claude Code for a team means four layers: managed settings that developers cannot override, permission deny rules and sandboxing for what the agent can touch, hooks that inspect prompts and tool calls, and an audit trail of what was actually read and sent. None of these layers alone covers every path secrets can take. This checklist walks through each control in order, cites Anthropic’s own documentation, and states plainly what each layer misses so you can assign an owner before a customer security review.

For a product-level overview of how ReclaimLLM fits Claude Code, see Claude Code security.

The Claude Code security risks that matter for a team

Claude Code is an agent: it reads files, edits code, runs shell commands, and can call MCP servers without a human approving every step. That maps cleanly to OWASP LLM risks such as sensitive information disclosure (LLM02) and excessive agency (LLM06).

Concrete risks for a 10–100 person engineering team include:

• Secrets in prompts, file reads, and tool output. A pasted log line or an accidental .env read can reach the model and land in local session history.
• MCP servers and plugins with their own credentials and network access, configured outside your repo review process.
• Local transcripts under ~/.claude/projects/ that retain what the agent saw unless you shorten retention or skip history (verify current defaults in Anthropic’s Claude directory docs before you publish internal policy).
• Per-developer drift. Individual ~/.claude/settings.json files diverge unless managed settings or MDM enforce a baseline.

Canadian teams may also align rollout with CCCS guidance on generative AI (ITSAP.00.041); the controls below are tool-specific, not a substitute for your own risk assessment.

Layer 1: Managed settings (the only layer developers cannot override)

Anthropic supports org-wide policy through managed-settings.json, MDM-delivered policy, or server-managed settings from the claude.ai admin console. Managed keys take highest precedence over user, project, local, and --settings files. See Settings and Managed settings.

Keys worth setting

| Key | Purpose | | --- | --- | | allowManagedPermissionRulesOnly | Managed scope only: ignores allow/ask/deny rules from non-managed settings files | | permissions.disableBypassPermissionsMode | Blocks bypass-permissions mode (nested under permissions, not top-level) | | availableModels | Locks which models developers can select (merge behavior varies by managed source; see settings reference) |

Confirm key names against the current settings reference before you paste them into MDM templates.

What it misses

Managed settings govern Claude Code only. Cursor, Codex, Copilot, or a browser tab on the same laptop are out of scope. You still need a delivery mechanism (MDM or the admin console) and a process to verify machines actually received the file.

Layer 2: Permission rules (deny before allow)

Permissions let you deny specific tools and paths. Deny and ask rules apply immediately; allow rules from a committed project file may wait until the folder is trusted.

Anthropic’s own example includes patterns such as Read(./.env) and Read(./.env.*). That blocks Claude’s Read tool—not every way a secret can leave disk.

What it misses

Shell commands are a different tool. cat .env, grep, or PowerShell equivalents can still print values unless you add sandbox limits, hooks, or operational habits. For a reproducible walkthrough of ignore files versus deny rules versus shell paths, see .claudeignore and .env—this post keeps that story to one paragraph so you can link there for depth.

Layer 3: Sandboxing

Per Anthropic’s sandboxing docs (verified October 2026): the sandbox wraps shell commands. Tools and processes that run outside it include:

• Built-in file and web tools (Read, Edit, Write, WebFetch, WebSearch), which follow permission rules instead—a denyRead entry does not stop the Read tool, and allowedDomains does not limit WebFetch the same way.
• Other processes Claude Code starts: command hooks, local MCP servers, plugin monitors, LSP servers, and helper commands such as the status line command and apiKeyHelper, which run with full access.

On native Windows, Claude Code runs commands unsandboxed; Anthropic recommends WSL2 for sandboxed shell execution.

What it misses

File tools, MCP, hooks, plugin monitors, LSP servers, and status-line/apiKeyHelper helpers all sit outside the shell sandbox. You need sandbox plus deny rules plus hooks, not “turn on sandbox and stop worrying.”

Layer 4: Hooks for inspection and redaction

Claude Code exposes dozens of hook events (hooks reference); three that matter most for data loss prevention are PreToolUse, UserPromptSubmit, and PostToolUse. Hooks run at the boundary between the agent and your filesystem or network.

How ReclaimLLM uses Claude Code hooks

1. Env DLP (default on). On PreToolUse, recognized .env and *.env Read calls are redirected to a sanitized temporary copy; Bash-style commands that dump env files are replaced with a block message. If a recognized env source cannot be inspected (unreadable, oversized), the handler raises DLPRedactionError and returns permissionDecision: deny—fail-closed for that class of access when the hook runs.
2. Egress guard. Before shell execution, the guard blocks common exfiltration paths (for example curl, wget, scp, rsync, nc, and several other binaries and inline fetch patterns) toward non-allowlisted destinations, plus a GeoIP country firewall. Cloud metadata endpoints are rejected server-side even if an org tries to allowlist them.

Local ambient redaction elsewhere in ReclaimLLM is string replacement plus folder exclusion, not semantic classification; direct env-file reads redact every assignment in the sanitized copy.

Honest limits (two different failure modes)

When the hook runs, recognized env-file DLP is fail-closed as described above. That is not the same as “hooks always block every leak.”

When the hook process fails, behavior differs:

• Hook crash, removal, or timeout: Claude Code’s default is fail-open unless you set onFailure: "block" (available in Claude Code v2.1.295+). ReclaimLLM’s installer does not set onFailure on injected hooks; teams can add it themselves if they want crash/timeout fail-closed.
• Egress guard backend errors: the guard logs and may fail open (allowed=1) on non-2xx responses or timeouts.

That is why coverage detection without MDM exists: ReclaimLLM coverage is detection, not MDM. Pair hooks with alerts when sensitive files are touched (AD-004) and with pre-execution egress controls (egress guard).

Layer 5: MCP servers and plugins

Claude Code stores MCP server configuration in ~/.claude.json. Review entries for hardcoded tokens, keep an approved-server list, and prefer environment variables or helper-based credentials over literals in JSON.

For a cross-tool MCP deep dive, see MCP security for coding agents when published; until then, use the MCP installation hooks announcement as product context.

What it misses

MCP servers run outside the shell sandbox and may not respect the same permission deny rules as built-in Read. Treat each server as its own mini-service with credentials and egress.

Layer 6: Transcripts and retention

Claude Code keeps local session history under ~/.claude/projects/ (also used by ReclaimLLM’s historical sync for backfill). ReclaimLLM-owned local artifacts use owner-only permissions; provider-owned transcript files may still hold unredacted content after a read. See AI coding transcripts as a secret store for retention and purge options.

What it misses

Transcript controls reduce blast radius after a mistake; they do not undo a secret already sent to inference. Combine retention policy with hook redaction and rotation playbooks.

Layer 7: A central gateway for keys and model policy

ReclaimLLM’s enterprise LLM gateway keeps team-scoped keys and provider credentials server-side. The gateway does not see local file reads—it governs API traffic you route through it, not everything Claude Code touches on disk.

What it misses

Developers can still point Claude Code directly at a provider unless you combine gateway policy with routing detection (coverage signals AD-013). Use gateway keys as one layer, not the whole story.

Layer 8: Detection and an audit trail

Even perfect prevention fails sometimes. Plan for evidence:

• Sensitive file access alerts (AD-004): P0 email with throttling; zero-exfiltration email bodies (no secret values in mail).
• External network egress detector (AD-015): flags anomalous outbound patterns after the fact.
• Admin audit log: 365-day retention and CSV export per ReclaimLLM audit log docs.

Privacy controls and US or EU data residency apply to ReclaimLLM-hosted data; ReclaimLLM’s SOC 2 Type II is targeted for early 2027—not certified today.

A 30-minute rollout checklist

Copy this table into your runbook and assign owners before you widen Claude Code to client code.

| # | Control | Where | Owner | Done? | | --- | --- | --- | --- | --- | | 1 | Managed settings deployed | MDM / claude.ai console | IT | | | 2 | .env / key deny rules | managed settings | Security | | | 3 | Sandbox on (macOS / Linux / WSL) | managed settings | Security | | | 4 | Hooks installed + coverage alerting | Developer machines | Platform | | | 5 | MCP allowlist reviewed | ~/.claude.json / plugins | Platform | | | 6 | Transcript retention policy set | Claude settings + docs | Security | | | 7 | Gateway keys per team | Gateway admin | Platform | | | 8 | Alerts routed to an owner | Email / SIEM | Security | | | 9 | Quarterly access review | Dashboard / audit export | CTO | |

Install hooks with native hooks documentation and verify the Coverage tab after the first wave of installs.

Is Claude Code safe for enterprise use?

Claude Code can be run safely for many enterprises when you treat it like any other privileged developer tool: managed baseline, deny rules for secret paths, sandbox where supported, hooks at the tool boundary, MCP hygiene, transcript policy, and detection you can show auditors. Anthropic documents the knobs; your security team owns how strictly they are set and verified.

No vendor—including Anthropic or ReclaimLLM—can guarantee zero disclosure if developers paste live secrets into prompts. The goal is defense in depth with measurable coverage, not a single checkbox.

Next step: See which Claude Code sessions touched secrets—start free. For a live walkthrough, book a 20-minute rollout review.

FAQ

Is Claude Code safe for enterprise use?

It can be, with managed settings, permission denies, sandboxing (on supported platforms), hooks, MCP review, transcript policy, and audit evidence. Safety depends on configuration and monitoring, not the product name alone.

What are the main Claude Code security risks?

Uncontrolled file and shell access, secrets in prompts and transcripts, MCP credentials, and inconsistent per-developer settings. Agent behavior aligns with OWASP LLM02 and LLM06 if left unmanaged.

Can developers override Claude Code managed settings?

No for keys delivered through managed settings, MDM, or the admin console—those take highest precedence. User and project files cannot weaken managed deny rules when allowManagedPermissionRulesOnly is enabled.

Does the Claude Code sandbox stop the agent reading .env?

The sandbox wraps shell commands, not built-in Read/Edit/Write. Use permission deny rules and hook DLP for file tools; do not rely on sandbox alone.

Do Claude Code hooks block every leak?

No. Recognized .env reads are sanitized or denied when the hook runs. Hook process crash, timeout, or egress-backend errors can still fail open unless you configure Claude’s onFailure: "block" and monitor coverage.

Where does Claude Code store conversation history?

Local project history under ~/.claude/projects/. Treat those JSONL files as sensitive; align retention with your data classification policy and verify current Anthropic defaults in official docs before audit season.