Claude Code Security Checklist for Teams

A secure Claude Code setup for a team comes down to five layers: a sensible permission mode, deny rules for secrets, the Bash sandbox, guard hooks for risky commands, and managed settings so none of it can be quietly switched off. Add review rules for MCP servers and plugins, a locked-down CI configuration, and isolation for anything unattended. The checklist below covers each layer with the exact setting names.

Every item was checked against Anthropic’s Claude Code security, permissions and settings docs on 24 Oct 2026. Copy it into your team wiki and tick it off. If you are still deciding whether to allow Claude Code at all, read is Claude Code safe? first.

1. Permission modes

1. Pick a default mode on purpose. Interactive sessions on v2.1.283 or later start in auto mode when it is available; claude -p starts in Manual mode. Both are reasonable. See permission modes.
2. Keep bypassPermissions off laptops. --dangerously-skip-permissions belongs in containers and VMs only, as a non-root user. Read when it’s safe.
3. Disable bypass where you don’t need it. Set permissions.disableBypassPermissionsMode to "disable" in managed settings.
4. Decide on auto mode. If your organisation doesn’t want classifier-approved actions, set disableAutoMode in managed settings.

2. Permission rules for secrets and risky commands

5. Deny reads of secret files. Claude Code excludes matching files from search results and blocks reads and edits of them:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)"
    ]
  }
}

6. Ask before pushes and deploys. Add ask rules such as Bash(git push *) and your deploy command. Ask rules still prompt in auto mode and even in bypass mode.
7. Know the limit of Bash rules. They match the command text, so Bash(curl *) does not stop /usr/bin/curl or sh -c 'curl ...'. Treat them as guidance plus a first filter, not a boundary.
8. Don’t rely on .claudeignore. The docs say it has no effect; move entries into Read deny rules.
9. Audit rules regularly with /permissions, which shows every rule and the file it comes from.

3. The Bash sandbox

10. Turn the sandbox on with /sandbox or sandbox.enabled: true. It is off by default. Full walkthrough: Claude Code sandboxing.
11. Block credential reads. Sandboxed commands can read ~/.ssh and ~/.aws/credentials by default. Add sandbox.credentials entries with "mode": "deny" for those files and for tokens such as GITHUB_TOKEN.
12. Fail closed. Set sandbox.failIfUnavailable: true so a missing dependency stops Claude Code instead of running commands unsandboxed, and sandbox.allowUnsandboxedCommands: false to remove the unsandboxed retry.
13. Keep the network allowlist narrow. Broad domains such as github.com can be used for exfiltration, because the proxy filters by hostname without inspecting TLS by default.
14. Remember the gaps. File tools, MCP servers, hooks and your status line run outside the Bash sandbox. On native Windows there is no sandbox; use WSL2.

4. Hooks

15. Add a PreToolUse guard that denies commands you cannot undo and asks before history rewrites. A tested script is in block dangerous commands with hooks.
16. Set onFailure: "block" on policy hooks (Claude Code 2.1.295 or later) so a missing or crashing script does not silently let everything through.
17. Use exit code 2 or a JSON deny, never exit code 1, for blocking. Exit 1 is a non-blocking error.
18. Watch settings changes. A ConfigChange hook can audit or block settings changes during a session.

If you would rather adopt a packaged set than maintain scripts, Kiln Guard is our Claude Code plugin with a command guard, a secrets and lockfile guard, and a test gate. It complements the sandbox rather than replacing it.

5. Repositories you didn’t write

19. Read the trust dialog. It lists the allow rules and extra directories a repo’s .claude/settings.json would grant. Hooks, the env block and MCP servers are the parts to read most carefully.
20. Be careful with headless runs in unknown repos. claude -p shows no trust dialog and connects the repo’s .mcp.json servers without asking. The docs suggest --setting-sources user, --bare, or --settings '{"disableAllHooks": true}' for that case.
21. Use real isolation for untrusted code. The docs recommend a dedicated VM, or a cloud session, for untrusted repositories.
22. Start Claude from the project folder, not your home directory. Trust given in the home directory is not saved, so the prompt reappears every launch and it is easy to click through.

6. MCP servers and plugins

23. Install MCP servers only from providers you trust. Anthropic does not security-audit or manage any MCP server. Project servers live in .mcp.json, but user-scope servers, claude.ai connectors and plugins can add more, so reviewing .mcp.json alone does not show everything.
24. Restrict servers centrally with managed MCP configuration if you are an admin. Our MCP servers guide covers scopes.
25. Review plugins like dependencies. A plugin can bundle hooks, MCP servers and agents that run with your permissions. See the plugins guide for scopes and how to disable one.

7. CI and automation

26. Use dontAsk with an explicit allowlist in pipelines, for example claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read". Anything not pre-approved is denied. More in headless mode and GitHub Actions.
27. Give CI the narrowest token. Store it in your CI secret store, never in the prompt or CLAUDE.md.
28. Scrub secrets from subprocesses with CLAUDE_CODE_SUBPROCESS_ENV_SCRUB where commands don’t need them.

8. Organisation controls

29. Enforce with managed settings. Deliver the keys above through MDM or server-managed settings; nothing else can override them.
30. Lock hooks and rules to the managed source with allowManagedHooksOnly and allowManagedPermissionRulesOnly if developers should not add their own.
31. Lock the sandbox policy with sandbox.filesystem.allowManagedReadPathsOnly and sandbox.network.allowManagedDomainsOnly.
32. Monitor usage with Claude Code’s OpenTelemetry metrics.

9. Code review and reporting

33. Review security in the loop. Anthropic’s security-guidance plugin reviews Claude’s own changes during the session (/plugin install security-guidance@claude-plugins-official), and /security-review runs an on-demand pass over your branch.
34. Keep humans on the diff. The docs are clear that you are responsible for reviewing proposed code and commands before approval.
35. Report vulnerabilities privately through Anthropic’s HackerOne program, and report suspicious behaviour with /feedback.

A sensible starting configuration

For a small team on macOS or Linux, this .claude/settings.json (committed) plus the sandbox in user settings covers items 5, 6 and 15:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"],
    "ask": ["Bash(git push *)"]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash",
            "args": ["${CLAUDE_PROJECT_DIR}/.claude/hooks/guard-bash.sh"],
            "onFailure": "block"
          }
        ]
      }
    ]
  }
}

Then each developer adds "sandbox": { "enabled": true } to ~/.claude/settings.json, or an admin delivers it through managed settings. Revisit the list when Claude Code ships a release that touches permissions; it changes often.