Guide
What should a security team check before approving Claude Code for the company?
Updated
Short answer
Check six things: what the agent can execute, read and send out; whether controls are enforced or only suggested; who can change them; what the agent's own settings can't see; how you audit it; and how you roll out without blocking engineers. Check the defaults yourself. The sandbox is off until someone turns it on, and Bash rules match command text. Start in watch-only, then enforce.
Start with the defaults, not the vendor's security page. If a review reads the settings file and never asks what actually runs, it can approve a tool that behaves differently from what the document says.
Below are the six checks, with what each built-in control does and doesn't give you.
What can the agent execute, read and send out?
Answer three reach questions first. Can it run any shell command? Can it read `~/.ssh`, `~/.aws/credentials` and `.env` files? Can it connect to a host you've never heard of?
Anthropic's sandbox docs are blunt about the defaults. "The sandbox is off by default." Even with it on, most of the machine, "including credential files such as `~/.ssh` and `~/.aws/credentials`," stays readable by default.
Are the controls enforced, or just suggested?
Read what the permission rules actually match. Bash rules match the whole command text, with `` standing in for any text. Claude Code knows about shell operators, so `Bash(safe-cmd )` won't approve `safe-cmd && other-cmd`.
That's careful engineering, and it's also the limit. A rule judges the command as it's written. It doesn't follow what a script does after it starts, so treat a deny rule as a tripwire on text and put a behavioral control behind it.
The sandbox is the stronger control for shell commands, and it has a scope you need to write down. From the same docs: "The sandbox covers shell commands only. Claude's file tools, MCP servers, and hooks run outside it."
Who can change the controls?
Managed settings handle this. Anthropic says Claude Code applies them above every other level, so no user, project, local or `--settings` value overrides them. A few security-sensitive exceptions let a stricter lower-level value still count.
Check three things:
- Is bypass mode disabled in managed settings, or can a developer start a session with permissions off?
- Can a project's own settings file add allow rules that matter? Anyone who clones a repo is trusting its config.
- Does a laptop that missed the managed settings fail loudly, or quietly fall back to defaults?
What can the agent's own settings not see?
Settings control what Claude Code's tools do. They don't control the supply chain around it.
A trojanized build of the Claude Code extension, version 2.1.313, was distributed through Cursor's marketplace for about 11 hours, and up to 5,000 developers may have been exposed. The malicious code ran when the extension loaded, "without requiring user interaction with Claude Code." The agent never had to propose anything.
Plugins carry the same risk. CVE-2026-86063 is a hash pin bypass in the plugin install process, rated CVSS 7.5, affecting versions below 2.1.179. So a hash pin you reviewed doesn't guarantee the code that runs.
Add to the review: minimum version floors, a plugin and MCP server allowlist, and a record of which extension builds sit on which laptops. Each MCP server is code you didn't write, and it runs outside the sandbox.
How do you audit it?
Ask what you'd hand an auditor after an incident. Can you show every command the agent ran, every file it edited and every push, across all developers, in one place? Transcripts scattered across laptops don't count.
Also ask who produced the evidence. If the agent's own harness enforces the rule and writes the log, the harness grades its own homework.
Prompts don't fill the gap either. In Anthropic's study of 1,053 testers, humans caught 13.6% of dangerous commands, and people approve 93% of prompts anyway. At 145 actions per agent session on average, a click isn't evidence of review.
How do you roll out without blocking engineers?
Engineers route around controls that stop them constantly. Roll out in stages:
- First: watch-only. Log what agents do, enforce nothing, and read the results.
- Next: turn on the sandbox and managed deny rules for the clear cases (credential paths, force-push to the default branch, piping curl to a shell).
- Then: enforce on a pilot team, review every block, and widen.
Where Harden fits
Everything above lives in the agent's own configuration. Harden Agentic Integrity Foundation (AIF) sits outside it. AIF runs on the developer laptop at the agent's pre-execution hook and checks every command, file edit and push against the session's intent before it runs, with decisions made locally.
It applies one policy across Claude Code, Codex, Cursor and other agents that expose a pre-execution hook. It starts watch-only, ships through your MDM, records every decision for export to your SIEM, and fails closed: if the check can't run, the action doesn't run.
AIF adds one check at the hook. You still need least privilege, scoped credentials and egress policy, and it won't contain a process that's already malicious, like the trojanized extension above. See how it works for security teams and the AIF trust page.
The printable checklist
- Sandbox enabled in managed settings, and credential paths denied for reads
- Bypass mode disabled by managed policy
- Project settings can't loosen managed rules (tested on a real laptop)
- Bash deny rules treated as tripwires, backed by a behavioral control
- Claude Code, extension and plugin versions floored (2.1.179 or later for CVE-2026-86063)
- Plugin and MCP allowlist, with an owner for each entry
- Secrets off disk where possible; scoped, short-lived credentials where not
- One record of every command, edit and push, kept outside the agent
- Watch-only pilot before any enforcement
Approve Claude Code when the controls still hold if the agent, a plugin or a rushed developer gets it wrong.
FAQ
Related questions
Is the Claude Code sandbox on by default?
No. Anthropic's docs say the sandbox is off by default. You turn it on with /sandbox or by setting sandbox.enabled in a settings file. It covers shell commands only, so file tools, MCP servers and hooks run outside it.
Do Claude Code deny rules stop a command from running?
They block commands whose text matches the rule, and Claude Code understands chained commands. A rule judges the command as written, though, so treat it as a tripwire and back it with the sandbox or a check outside the agent.
Can developers override managed settings?
Managed settings sit above user, project and local settings, so a developer can't loosen them. For a few security-sensitive settings, a stricter lower-level value still counts. Test enforcement on a real laptop before you rely on it.
How long should a Claude Code pilot run before enforcing?
Stay in watch-only until you've seen real usage across the pilot team. Then enforce the clear cases on that one team, review every block, and widen from there.
Does a tampered extension get past permission rules?
It can. In the trojanized-extension case, the malicious code ran when the extension loaded, without any interaction with Claude Code. Extensions and plugins need their own version floors and allowlists.