Claude Code Security for Enterprises: What It Controls and What It Leaves Open

How to secure Claude Code across a company: managed settings, permission rules, sandboxing, MCP restrictions and telemetry, a baseline to deploy through MDM, and the gaps a security team still has to close.

By Kontext.

Published 2026-11-12.

Claude Code runs on a developer's machine with that developer's access. It reads the repository, runs shell commands, calls MCP servers and fetches web pages. For a security team, the question is what it is allowed to do when nobody is watching, and how you would know.

This guide covers the controls Claude Code ships with, how to roll them out across a company, and the gaps a security team still has to close. It reflects Anthropic's public documentation as of November 2026. Setting names change between releases, so check the linked pages before you deploy.

Short answer: Claude Code has real enterprise controls: managed settings that developers cannot override, allow and deny rules, an operating-system sandbox for shell commands, MCP server restrictions, hooks, and OpenTelemetry export. Deploy them through your MDM. They do not give you an inventory of every agent in the company, they match shell commands by their text, the sandbox does not cover hooks or MCP servers, and they only apply to Claude Code. Plan for a layer that sees and controls all agents at runtime.

What Claude Code can reach

Start with the access, because every control below is a limit on it.

  • The shell. Claude Code runs commands as the signed-in user. Anything the developer can run, it can run: package installs, git push, cloud CLIs, database clients.
  • Files. It reads and edits the working directory. Depending on settings it can also read the rest of the machine, including ~/.ssh and cloud credential files.
  • MCP servers and connectors. Each one adds tools, often with its own token to a production system such as a ticket tracker, a database or a cloud account.
  • The network. It fetches web pages and can run curl. Content it reads from a page, an issue or a README can contain instructions aimed at the agent. That is prompt injection.
  • Other surfaces. The same agent runs in the terminal, the IDE extensions, the desktop app and in cloud sessions. Not every setting reaches every surface.

The controls Claude Code ships with

Permission modes and rules

A permission mode decides which actions run without a prompt. In Manual mode Claude Code asks before it edits a file or runs a command that is not read-only. In auto mode a separate classifier model reviews actions in place of the developer. Current versions start interactive sessions in auto mode unless a setting changes that.

Rules sit on top of the mode. A deny rule blocks a tool call, an ask rule forces a prompt, and an allow rule skips it. Deny wins over ask, and ask wins over allow. Rules are enforced by Claude Code, not by the model, so an instruction in a prompt or a CLAUDE.md file cannot grant access.

Managed settings

Managed settings are how a company sets policy. They arrive through an MDM profile, a managed-settings.json file in a system directory, or server-managed settings from the Claude admin console. They sit above every file a developer or a repository controls. A developer can run /status to see which managed source applies.

Three settings matter most for a security baseline:

  • allowManagedPermissionRulesOnly makes managed settings the only source of permission rules, so a repository or a developer cannot add their own allow rules.
  • disableBypassPermissionsMode, under permissions, removes the mode that skips permission prompts altogether.
  • disableAutoMode, also under permissions, turns the classifier mode off if you want a human to approve actions.

Sandboxing

The sandbox isolates shell commands at the operating-system level, with Seatbelt on macOS and bubblewrap on Linux and WSL2. Writes are limited to the working directory and a few named locations. Network traffic goes through a local proxy that checks each hostname against an allowlist, which starts empty. This is the control that does not depend on what a command looks like.

MCP restrictions

Managed MCP configuration lets you restrict which servers run in your organization. This matters because a repository's .mcp.json does not show every server a session can load. Servers also come from user settings, plugins and claude.ai connectors. Anthropic reviews connectors before listing them in its directory but does not security-audit MCP servers.

Hooks

Hooks run your own code at fixed points. A PreToolUse hook sees the full tool call before it runs and can block it. A ConfigChange hook can audit or block settings changes during a session.

Telemetry

With CLAUDE_CODE_ENABLE_TELEMETRY=1, Claude Code exports metrics and events through OpenTelemetry to your own collector. Events include each tool result and each accept or reject decision, with the source of the decision. You set the collector in managed settings, and a repository cannot enable telemetry or redirect it.

Data handling

Under commercial terms, Anthropic does not train models on code or prompts sent to Claude Code unless the customer opts in. Standard retention is 30 days, and zero data retention is available to qualified Enterprise accounts. Session transcripts are also stored on the developer's disk in plaintext under ~/.claude/projects/, for 30 days by default.

A baseline to deploy

This managed settings file is a starting point. It locks permission rules to the company's, removes bypass mode, protects credential files, turns the sandbox on in strict mode, and sends telemetry to your collector.

{
  "allowManagedPermissionRulesOnly": true,
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://collector.example.com:4317"
  }
}

Test it on a pilot group first. Strict sandboxing breaks tools that ignore proxy settings, such as plain ssh and most database drivers, and locking rules to managed settings removes every allow rule developers have saved. Expect to add allowed domains and commands before you roll it out company-wide.

Where the built-in controls stop

The documentation is direct about most of these limits. They are the part a security review should spend its time on.

_What each built-in Claude Code control enforces and what it leaves open._

ControlWhat it enforcesWhat it leaves open
Deny rules for shell commandsThe command as written.The same program by path or inside a shell wrapper. A rule on curl does not stop /usr/bin/curl.
Deny rules for filesThe file tools and commands such as cat.Commands that read files without naming them, such as a recursive grep.
SandboxShell commands and the processes they start.Hooks, local MCP servers, the built-in file and web tools, and native Windows, where commands run unsandboxed.
Managed settingsDevices and accounts your policy reaches.Personal accounts, unmanaged devices, and surfaces a given delivery method does not cover.
TelemetryNothing. It records counts, tool names and decisions.Prompts and tool inputs are redacted unless you opt in.
Trust promptsInteractive sessions.Headless runs show no trust prompt.

Four gaps follow from that table.

1. You do not have an inventory. Managed settings tell Claude Code what to do where they are installed. They do not tell you which machines run Claude Code, under which account, with which MCP servers and which tokens. That is the first thing an auditor asks for.

2. Text matching is not enforcement. A deny rule on a command is a guardrail for an agent that is behaving. An agent that has read a malicious instruction can phrase the same action differently. The sandbox closes this for shell commands, and only for them.

3. MCP servers run outside the sandbox. A local MCP server is a process with the developer's access and often a long-lived token. Restricting which servers load is necessary. It says nothing about what an approved server is asked to do, or where the data it returns goes next.

4. It is one agent. The same developers use Cursor, Codex, Copilot and workplace agents. Each has its own settings format, its own gaps and its own logs. A policy written in Claude Code's managed settings covers none of them.

Where Kontext fits

Kontext is the layer across agents. It runs where your AI agents run and gives a security team one place to see them and decide what they may do.

  • Agent discovery. Find Claude Code and the other coding and workplace agents on your endpoints, with the tools, MCP servers and systems each one can reach.
  • Runtime authorization. Decide on each action before it runs, based on what the agent is doing and what it touches, and keep the decision as evidence.
  • Risk detection. See what agents did across sessions and where data moved, not only how many tool calls were made.

Kontext does not replace the baseline above. Keep managed settings and the sandbox on, and use Kontext for the inventory, the cross-agent policy and the evidence. It ships as one signed package that you push through the same MDM. More on how security teams use it is on the security teams page.

Rollout checklist

  1. Decide who may use it. Require sign-in with the company account and choose where model traffic goes: the Claude API, Amazon Bedrock, Google Cloud or Microsoft Foundry.
  2. Ship managed settings through MDM. Start from the baseline above, in a pilot group.
  3. Turn the sandbox on and build the domain allowlist from what the pilot group needs.
  4. Restrict MCP servers to a reviewed list, and replace long-lived tokens with scoped ones where you can.
  5. Send telemetry to your collector and decide, with legal, whether to log prompts and tool inputs.
  6. Inventory every agent, not only Claude Code, and write policy once for all of them. Runtime authorization explains the model.
  7. Add agents to incident response. Know how to revoke a token, pull a session transcript and disable a server on one machine within minutes.

FAQ

Is Claude Code safe for enterprise use?

It can be, with configuration. The defaults are built for a single developer who reviews each action. A company needs managed settings, the sandbox, a restricted MCP list and telemetry before a wide rollout, and a way to see and control agents beyond Claude Code.

Does Anthropic train on our code?

Not under commercial terms, which cover Team and Enterprise plans, the API and third-party platforms, unless you opt in. Consumer plans have a setting that allows training, so require company accounts.

Can developers override managed settings?

No. Managed settings take precedence over user, project and command-line settings. Permission rules from other files still merge with yours unless you set allowManagedPermissionRulesOnly. Managed settings only apply on devices and accounts your policy reaches.

Do deny rules stop prompt injection?

They reduce what an injected instruction can do. They do not stop it, because shell deny rules match the command text. Use the sandbox for network and filesystem limits that hold regardless of the command, and a runtime control for actions that go through MCP servers.

How do we audit what Claude Code did?

Export OpenTelemetry events to your SIEM for tool calls and decisions. Prompts and tool inputs are redacted by default. Full transcripts live on the developer's machine for 30 days. For evidence across agents, with the policy decision attached to each action, you need a layer such as Kontext.

References

Related reading

Back to Articles