Claude Code Enterprise Security Controls for Engineering Teams
Anthropic gives enterprise admins real levers for Claude Code: managed settings, permission rules, sandboxing, managed MCP configuration and usage telemetry. This page walks through what each one enforces from Anthropic's own documentation, where each one stops, and the point at which a team running agents against production systems needs a second control.
Direct answer
Claude Code enterprise security rests on managed settings that developers cannot override, allow, ask and deny permission rules, a sandboxed bash tool, managed MCP configuration, model allow lists and OpenTelemetry usage metrics. Anthropic states that no system is immune to every attack, and that a Bash command you approve can still write anywhere your account can. Those controls decide what Claude Code may attempt on a laptop. They do not judge a specific action against a production system or hold it for a second approver.
Try it live
Watch AgentShield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A US platform team rolls Claude Code out to two hundred engineers with a managed settings file that denies reads of .env files and blocks curl. It is a good policy. Three months later one team connects the agent to a deploy tool and a ticketing system through MCP so it can open pull requests and close incidents. A poisoned dependency README tells the agent to run the deploy tool against production. Every control in the managed file passed, because the file governs which commands and servers are allowed, not whether this particular call, with these arguments, should happen right now.
How AgentShield handles it
Start with Anthropic's controls, because they are good and they cost nothing extra: managed settings, deny rules, sandboxing and a managed MCP allow list. Then, for agents that act on systems outside the laptop, route those calls through an AgentShield gateway. Rules check the arguments of each tool call, high-impact actions wait for a named approver, and every allowed and denied action lands in one attributed record that an auditor can read.
The controls
The controls that secure what Claude Code may run across every engineer, and which commands and MCP calls wait for a named approver.
What Claude Code enforces for an organization
The honest summary is that Claude Code gives administrators strong control over what runs on a developer machine, and Anthropic itself says the controls reduce risk rather than remove it. The facts below come from Anthropic's Claude Code documentation on settings and security, read in October 2026. Confirm them against the current pages before a purchase or rollout decision.
| Control | What it does | Where it stops |
|---|---|---|
| Managed settings | A managed-settings.json file, an MDM policy or server-managed settings from the claude.ai console. Managed is the top of the precedence stack, and nothing in a developer's own files or the --settings flag overrides a managed key | Server-managed settings reach cloud sessions, while a file or MDM profile on a device does not. A few restrictive keys can still be tightened by a developer |
| Permission rules | Allow, ask and deny rules for tools. Setting allowManagedPermissionRulesOnly stops allow rules from other scopes from being merged in | A deny rule matches a command as written, so it is not network enforcement |
| Sandboxed bash tool | Filesystem and network isolation for bash commands, configured with /sandbox | Covers bash. It does not describe what an approved MCP tool does downstream |
| Managed MCP configuration | Restricts which MCP servers run in the organization | Decides which servers connect, not which calls on a connected server are safe |
| Model controls | availableModels and deniedModels lock which models developers can pick | Says nothing about actions |
| Usage telemetry and hooks | OpenTelemetry metrics, and ConfigChange hooks that can audit or block settings changes during a session | Observation after the fact, not a decision on each call |
Anthropic also documents an auto mode in which a separate classifier model reviews actions instead of the user and blocks the ones it judges unsafe. Your own ask and deny rules still apply, and an organization can turn auto mode off. A classifier is a probabilistic control, which is worth a line in your risk register next to the deterministic ones.
What Anthropic says the controls do not cover
Anthropic's security page is direct about limits, and a buyer should read it as a list of residual risks. It says a working directory boundary is a permission prompt, so "a Bash command you approve can still write anywhere your user account can". It says that "no system is completely immune to all attacks". It also notes that a session started with the -p flag shows neither the workspace trust prompt nor the project MCP approval prompt, and that a repository's files can run code before trust is given.
| Gap | Why it matters in an enterprise rollout |
|---|---|
| Approved commands run with the developer's full account access | An injected instruction that reaches an approved command inherits everything the engineer can reach |
| Headless runs skip the trust and MCP approval prompts | CI jobs and scheduled agents are where nobody is watching, and where prompts never appear |
| MCP servers are trusted by configuration | Anthropic says it does not security-audit or manage any MCP server. A server you allow can still return hostile text |
| Rules match text, not intent | A deny rule on curl does not stop a script that makes the same request another way unless the sandbox network rules cover it |
| Evidence is usage metrics | Metrics tell you how much was used. An auditor asks who approved a specific production change |
None of this is a criticism of the product. It is the normal shape of a client-side control. The decision point sits on the machine where the injection happens, so the strongest policy is one that is also enforced somewhere the model cannot reach. The same logic drives our coding agents guidance, and the Claude agent security page covers the Agent SDK side.
Claude Code enterprise security checklist for US platform and security teams
- Deliver a managed policy. Use server-managed settings if your developers sign in with the organization account, or a managed file and MDM for devices. Run /status on a sample machine to confirm the Setting sources line shows it.
- Set allowManagedPermissionRulesOnly if you want the managed rules to be the only allow rules, so a developer's "don't ask again" approval cannot widen them.
- Deny reads of secrets files and the commands you do not want an agent to run. Treat these as guardrails, not a perimeter.
- Turn on the sandbox for bash and define the network domains the agent may reach.
- Use managed MCP configuration to list the servers you allow. Remove everything else, including servers that plugins can add.
- Lock models with availableModels or deniedModels if procurement or data residency requires a specific set.
- Export OpenTelemetry metrics to the system your security team already reads, and add a ConfigChange hook if you must log or block settings changes.
- Decide, in writing, which production actions an agent may never take alone. Deploys, payments, access grants and bulk deletes are the usual list.
Steps one to seven cost engineering time and no license fee beyond your Claude Code plan. Step eight is the one that needs a mechanism, and it is where teams usually look for a second control.
Where a second control earns its place
An AgentShield gateway sits on the paths your own agents use to reach systems of record, such as a deploy API, a ticket system, a database tool or a payment service. It does not replace managed settings. It adds a decision on each action, outside the model and outside the laptop.
| Risk | Claude Code control | Second control |
|---|---|---|
| Engineer runs an unreviewed MCP server | Managed MCP configuration | None needed. Use the allow list |
| Agent reads a secrets file | Deny rules and sandbox | None needed for local files. Add data loss checks for what leaves |
| Injected text triggers a production deploy | Approved tool, so it runs | Rule on the deploy target and arguments, held for a named approver |
| Bulk change to tickets, records or repos | Developer permission only | Count limit per run and per day, approval above it |
| Customer data leaves in a tool call | Sandbox network rules at best | Content scan on outbound arguments |
| Proof for SOC 2 or a customer review | Usage metrics | One attributed record of allowed, denied and approved actions |
The gateway works for agents you build or route yourself, including headless and CI runs where Claude Code's own prompts never appear. It cannot sit inside a vendor client that talks straight to a third party, so set the Anthropic controls first. See tool and data permissions for how rules are written.
When to buy nothing, use Anthropic controls, or add AgentShield
| Your situation | What to do |
|---|---|
| Engineers use Claude Code on application code and nothing else | Buy nothing. Managed settings, deny rules and the sandbox are enough |
| You need to restrict which MCP servers and models developers can use | Use managed MCP configuration and the model allow lists |
| You need usage reporting for finance or leadership | Use OpenTelemetry metrics |
| Agents run headless in CI or on a schedule | Add a gateway, because trust prompts do not appear there |
| Agents call deploy, billing, identity or customer data tools | Add argument rules and approval on those calls |
| An auditor wants proof of who approved what | Add the gateway record, and keep Anthropic metrics for usage |
Three of six rows end without a purchase from us. If you are comparing assistants before you choose, our Gemini CLI and Claude Code security comparison sets defaults side by side, and human approval for AI agents explains how to decide which actions deserve a person.
FAQ
Common questions about claude code enterprise security.
Is Claude Code secure for enterprise use?
Claude Code ships enterprise controls: managed settings developers cannot override, permission rules, a sandboxed bash tool, managed MCP configuration and usage telemetry. Anthropic also states that no system is immune to all attacks, and that an approved Bash command can write anywhere the account can. High-impact actions on production systems still need a second check.
How do I enforce Claude Code settings across my organization?
Use managed settings. Deliver a managed-settings.json file, an MDM policy, or server-managed settings from the claude.ai console. Managed settings sit at the top of the precedence stack, so nothing in a developer's own files or the --settings flag overrides them. Run /status to confirm which source applies on a machine.
Can developers override Claude Code managed settings?
Not for the keys your organization sets. Managed settings rank above command line, project and user settings. Anthropic lists a few restrictive keys, such as disableClaudeAiConnectors, where a stricter developer value is still honored. Allow rules from other scopes merge unless you set allowManagedPermissionRulesOnly.
How do I restrict which MCP servers Claude Code can use?
Use Anthropic's managed MCP configuration to define which servers run in your organization. Reviewing a repository's .mcp.json is not enough, because servers at other scopes, claude.ai connectors and plugins can add servers too. Anthropic does not security-audit any MCP server, so treat what they return as untrusted text.
Does Claude Code protect against prompt injection?
It reduces the risk with permission prompts, network command approval, command injection detection and fail-closed matching, plus an optional classifier in auto mode. Anthropic says no system is completely immune. An injected instruction that reaches an approved command or MCP tool still runs with the developer's access.
How do I audit what Claude Code did?
Anthropic recommends monitoring usage through OpenTelemetry metrics and using ConfigChange hooks to audit or block settings changes. Those show volume and configuration. For proof of who approved a specific production action, a gateway that records each tool call with its decision gives an auditor something they can read.
Does AgentShield work with Claude Code?
Yes, for agents that call tools through a gateway endpoint, where it checks the arguments of each call and holds risky ones for a named approver. It adds to managed settings rather than replacing them, and it covers headless and CI runs where Claude Code's interactive prompts never appear.
More use cases