Secure Claude Code for Teams (2026)

When one developer uses Claude Code on their personal machine, security is a personal choice. When a team of ten uses it on shared codebases with production secrets in the environment, security is a requirement. One misconfigured permission, one leaked API key, one unreviewed file write can create real damage.

This guide covers how to secure Claude Code for team environments, from permission policies to audit trails. Use the Permissions Configurator to generate your team’s baseline configuration.

The Threat Model

Before configuring security, understand what you are protecting against:

  1. Accidental file modification — Claude writes to the wrong file or overwrites uncommitted changes
  2. Secret exposure — Claude reads .env files or credential stores and includes contents in responses
  3. Destructive commands — Claude runs rm -rf, git push --force, or DROP TABLE commands
  4. Supply chain risk — Claude installs unvetted packages via npm install or pip install
  5. Data exfiltration — Claude sends code or data to external URLs via WebSearch or WebFetch

Each threat has a specific mitigation in Claude Code’s permission system.

Step 1: Create a Team Permission Baseline

Commit a .claude/settings.json to your repository with restrictive defaults:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "Bash(git branch*)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(curl * | *sh)",
      "Bash(wget *)",
      "Read(~/.ssh/*)",
      "Read(~/.aws/*)",
      "Read(.env*)"
    ]
  }
}

This baseline allows read-only operations and blocks dangerous patterns. Developers can add personal permissions in .claude/settings.local.json (which should be in .gitignore).

See the settings.json guide for all available options.

Step 2: Protect Secrets

Block access to credential files

The deny rules above block .env, SSH keys, and AWS credentials. Extend this for your specific environment:

{
  "permissions": {
    "deny": [
      "Read(.env*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(*credentials*)",
      "Read(*secret*)",
      "Read(~/.ssh/*)",
      "Read(~/.aws/*)",
      "Read(~/.config/gcloud/*)"
    ]
  }
}

Use environment variables, not files

Claude Code can access environment variables through Bash commands. Ensure secrets are loaded into the environment rather than stored in files that Claude might read. Environment variables are ephemeral and do not persist in conversation history.

Review before committing

Configure a pre-commit hook that scans for secrets in Claude-generated code:

#!/bin/bash
# .claude/hooks/pre-commit-scan.sh
if git diff --cached | grep -iE "(api_key|secret|password|token)\s*=\s*['\"]" ; then
  echo "BLOCKED: Possible secret detected in staged changes"
  exit 1
fi

Step 3: Enable Audit Logging

Every tool invocation should be logged for team environments:

{
  "auditLog": true,
  "hooks": {
    "preToolCall": "bash .claude/hooks/audit-log.sh"
  }
}

The audit log captures:

  • Timestamp of every tool call
  • Tool name and parameters
  • User who initiated the session
  • Result status

This creates an accountability trail. If something goes wrong, you can trace exactly what Claude did and when.

For compliance-heavy environments, forward audit logs to your SIEM or log aggregation system. See the AI coding tools governance guide for enterprise compliance frameworks.

Step 4: Control Network Access

Prevent Claude from sending data to external services:

{
  "permissions": {
    "deny": [
      "WebSearch",
      "WebFetch",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)",
      "Bash(ssh *)"
    ]
  }
}

This blocks all network access from Claude Code. If your team needs web search, allow WebSearch but keep WebFetch blocked (search results are anonymized; fetch is not).

Step 5: Standardize Across the Team

Onboarding checklist

When a new developer joins the team:

  1. Clone the repository (gets .claude/settings.json automatically)
  2. Run /doctor to verify configuration
  3. Create .claude/settings.local.json for personal preferences (optional)
  4. Verify deny rules are active: ask Claude to read .env (should be blocked)

Regular audits

Monthly, review:

  • Audit logs for unusual tool invocations
  • .claude/settings.local.json overrides (developers may weaken security)
  • New MCP server connections (each adds attack surface)

Training

Train developers on:

  • Why permission prompts exist (not just annoyances)
  • How to use the allowlist effectively (press a for bulk approval of safe actions)
  • What the deny rules protect against
  • How to report security concerns

For comprehensive onboarding with Claude Code, see onboarding developers with Claude Code.

Try It Yourself

Use the Permissions Configurator to generate a team security configuration. The tool asks about your team size, tech stack, and compliance requirements, then produces a settings.json with appropriate protections.

Start with the restrictive baseline from Step 1, deploy it for one week, and collect feedback from the team about which operations need to be added to the allowlist. This bottom-up approach ensures you do not block legitimate workflows while maintaining security.

Permission Escalation Process

For operations that require higher permissions (like database migrations or production deployments):

  1. Developer requests permission escalation in the team channel
  2. Senior engineer reviews the specific operation
  3. Developer uses a temporary .claude/settings.local.json override
  4. After the operation, developer removes the override
  5. Audit log captures the elevated-permission session

This process balances security with operational flexibility.

Common Team Security Mistakes

Mistake Risk Fix
No deny rules for rm -rf Accidental data loss Add explicit deny rule
.env readable by Claude Secret exposure in conversation Deny Read(.env*)
YOLO mode on dev machines All protections bypassed Reserve for CI only
No audit logging Cannot investigate incidents Enable auditLog: true
MCP servers with broad access Expanded attack surface Audit MCP tool count monthly

Frequently Asked Questions

Should we use YOLO mode in CI/CD?

Yes, but only in isolated environments (containers, VMs) that are destroyed after each run. Never use YOLO mode on persistent infrastructure. See the permission modes guide for details.

How do we handle developers who need different permissions?

Use the three-tier settings hierarchy. Commit baseline rules to .claude/settings.json. Developers customize in .claude/settings.local.json. This keeps the shared baseline consistent while allowing individual flexibility.

Can Claude Code access files outside the project directory?

Yes, by default. Claude can read any file the user has access to. Use deny rules to restrict access to sensitive directories like ~/.ssh and ~/.aws. The principle of least privilege applies.

What about MCP server security?

Each MCP server is a separate process with its own permissions. Audit which MCP servers are configured, what tools they provide, and what environment variables they receive. Remove unused servers to reduce attack surface.

Configure it → Build your MCP config with our MCP Config Generator.