Claude Code Security: 10 Best Practices for Engineering Teams

Claude Code security comes down to three things your team controls: what Claude Code is allowed to run, what it can read, and how its code gets reviewed before merge. Anthropic ships strong defaults, including permission modes, an OS-level Bash sandbox and managed settings. The common failures come from how teams configure and use them: broad allow rules, secrets typed into approved commands and AI-written code merged without review.

This guide is for engineering leads rolling out Claude Code, Anthropic's AI coding assistant, across a team without a dedicated security hire. It covers the built-in controls, the real risks seen in 2026, and ten practices you can apply this week. Everything about how Claude Code behaves is drawn from Anthropic's Claude Code security documentation; where we add our own view, we say so.

Is Claude Code secure?

Claude Code is built with sensible guardrails, and its security depends heavily on configuration. Every session runs in a permission mode. In Manual mode it starts read-only and asks before editing files or running commands. In Auto mode, the default for interactive terminal and VS Code sessions, a separate classifier model reviews actions and blocks those it judges unsafe, while your explicit allow and deny rules still apply. Commands that fetch from the web, such as curl and wget, are not auto-approved by default, and Manual mode asks before running a Bash command it cannot fully analyze.

Two built-in protections deserve more attention than they get. The Bash sandbox uses the operating system (Seatbelt on macOS, bubblewrap on Linux) to limit which files and network hosts shell commands can reach, and its allowed domain list starts empty. Managed settings let an organization push policy that nothing in a developer's own settings can override. Anthropic is also clear about the limits: the working directory boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can, and no system is immune to every attack.

What are the main Claude Code security risks?

Five risks show up repeatedly in public research and incidents.

The first risk is not theoretical. In November 2026, researchers at Apiiro found 1,122 public copies of .claude/settings.local.json on GitHub holding at least one secret, 1,379 secrets in all, including 379 database passwords and 23 AWS keys, according to our report on the Claude Code secrets leak. The last risk is just as measurable: across 23 studies, about 1 in 3 AI-generated code samples had a security flaw, as we summarize in can AI coding assistants introduce vulnerabilities.

Prompt injection and tool abuse map directly onto the OWASP Top 10 for LLM applications, especially prompt injection (LLM01) and excessive agency (LLM06). An agent that can run shell commands and reach the network has real agency, so the controls below are about shrinking what one bad instruction can do.

Claude Code security best practices: the 10 that matter

1. Keep secrets out of commands. Reference credentials as environment variables such as $DATABASE_URL, loaded from a secrets manager, so any saved rule stores the name and never the value.

2. Approve patterns, not single commands. A rule like Bash(npm run test:*) is reusable and holds no secret. A one-off approved command can.

3. Gitignore agent folders in every repository. Add .claude/settings.local.json to each project's own .gitignore and your org templates. Claude Code adds it to the user's global git excludes, but that protection stays on one machine.

4. Deny reads of sensitive files. Add Read deny rules such as Read(./.env), Read(./.env.*) and Read(./secrets/**). Anthropic's docs note that a .claudeignore file has no effect; deny rules are the supported method.

5. Turn on the Bash sandbox. Run /sandbox and keep the allowed domain list short. Network isolation enforced by the OS does not depend on how a command is written, unlike deny rules that match command text.

6. Use deny rules for dangerous tools. Deny always wins: a broad deny such as Bash(aws *) blocks even calls that a narrower allow rule matches.

7. Enforce policy with managed settings. Use managed settings to set deny rules, disable bypass mode with permissions.disableBypassPermissionsMode, and, if needed, allowManagedPermissionRulesOnly so only organization rules apply.

8. Allowlist MCP servers. Only connect servers you wrote or trust. Anthropic reviews directory connectors against listing criteria but does not security-audit any MCP server. See our guide to MCP security.

9. Isolate untrusted work. For unfamiliar repositories or tasks that browse the web, run Claude Code inside a dev container or VM, as Anthropic recommends.

10. Review every AI-written change before merge. Treat Claude Code output like a new contributor's pull request: run a security scan and require human approval.

How do you keep secrets out of Claude Code?

Start with the settings file. A minimal team baseline in .claude/settings.json, which you commit on purpose, looks like this:

{
  "permissions": {
    "allow": ["Bash(npm run lint)", "Bash(npm run test:*)"],
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

{
  "permissions": {
    "allow": ["Bash(npm run lint)", "Bash(npm run test:*)"],
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

{
  "permissions": {
    "allow": ["Bash(npm run lint)", "Bash(npm run test:*)"],
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

Then check what already leaked. Search your organization's repositories, including git history, for .claude/settings.local.json and .claude/settings.json. If any file ever held a credential, rotate it before cleaning history, since deleting a commit does not revoke a key; our leaked API key runbook walks through the order. Many format-based scanners miss passwords typed inside commands, so also review these folders by hand and see how to find hardcoded secrets in code. Claude Code itself stores its own API keys in the macOS Keychain where available, or in a file with mode 0600 on Linux.

How do you enforce Claude Code security across a team?

Settings apply in a fixed order, highest first: managed settings, command line, project local, shared project, then user. That order is what makes managed settings the right home for anything you need enforced. Deliver them as a managed-settings.json file, through MDM, or as server-managed settings from the claude.ai admin console. Pair that with OpenTelemetry monitoring for usage visibility and ConfigChange hooks to audit or block settings edits during a session. Keep shared permission rules in version control so changes go through review like any other code.

How should you review code that Claude Code writes?

Use two layers. Inside the session, Claude Code offers /security-review for an on-demand pass over your branch changes. At merge time, make security a required check that does not depend on any one developer remembering to run it. This is where ARGUS fits: its PR Reviewer reviews diffs and can post a required commit status, so a pull request stays blocked until it has been reviewed. For findings, "Assign to Agent" clones the repo, generates the smallest fix, verifies it with a build and re-scan, and opens a pull request; it never merges. ARGUS also offers a pre-install package check over MCP, so Claude Code can ask whether a package is malicious or typosquatted before installing it, a real risk covered in our package hallucination report. None of this replaces Anthropic's own controls; it adds a review layer at the merge step. See how it works on ARGUS.

FAQ

Is Claude Code safe to use on proprietary code?
It can be, with configuration. Use managed settings, deny reads of secret files, enable the sandbox and review changes before merge. Anthropic publishes its SOC 2 Type 2 report and ISO 27001 certificate through its Trust Center.

Does "Yes, and don't ask again" save my password?
It can. The choice saves an allow rule to .claude/settings.local.json, and when the rule is the exact command, any secret typed into it is saved in plain text.

Should I commit .claude/settings.json?
Yes, the shared file is meant to be committed so the team shares permission rules. Do not commit settings.local.json, and never put secrets in either.

What is the safest Claude Code permission mode?
Manual mode with a short allowlist is the most conservative. Organizations can disable bypass mode and auto mode in managed settings.

For the broader picture across tools, read security risks of Claude Code, Cursor and Codex.