Claude Code enterprise security is a design problem

The guide to running Claude Code in a company almost always stops at the install. Get the proxy right, trust the certificate, allowlist the domains. That work is real, and I have written the setup guide for exactly it. But the install is the easy ten percent. The other ninety percent, the part almost nobody writes, is the security design around a tool that, by its nature, runs shell commands, reads files, and reaches the network on your behalf.

That is the claim of this post. Claude Code enterprise security is not an install task that finishes. It is a design problem you either solve deliberately or inherit by accident. An agentic command-line tool inside a regulated company is a new kind of actor on the network: not a person, not a traditional script, something in between that takes initiative. Securing it means answering questions a setup guide never raises. Can you reconstruct what it did. Can hostile content it reads turn it against you. What is it allowed to do, and who decides. The install gets you a working tool. Only the design gets you a tool you can defend.

Why the install is the easy part

Begin with what Claude Code actually is, because the threat model follows from it. It is an agentic command-line tool: you give it a goal, and it works toward that goal by reading files, running shell commands, making network requests, and calling MCP servers, taking each step itself rather than waiting for you to type it. That autonomy is the entire value, and it is also the entire security question. A traditional script does exactly what its author wrote. Claude Code decides what to do as it goes, which means the security boundary cannot be “review the code first,” because there is no fixed code to review. The boundary has to be built around the tool: limits on what it can touch and a record of what it did, plus a policy that holds even when the tool does something its operator did not foresee. An install gives you the capability. The threat model is about everything that capability can reach.

The good news is that Claude Code’s defaults are not reckless. Out of the box it runs with read-only permissions and asks before it edits a file or runs a command. Its write access is confined to the project folder it was started in; it cannot modify files in parent directories without explicit permission. It blocks commands that fetch arbitrary web content, like curl and wget, by default. So the starting posture is reasonable, and an enterprise security review should credit that rather than assume the worst. The work is not undoing a dangerous default. It is deciding, deliberately, where the design areas below land for your organization, because the defaults are a sane starting point and not a finished policy. This is the same shift in thinking that enterprise AI security demands generally: the tool is not the threat surface, the way you deploy it is.

It helps to give that actor a name in your own model. Claude Code is not a user account, and it is not quite a service account either. It runs as a developer, with that developer’s machine access and often that developer’s credentials, but it makes its own decisions about what to do with them. A security team used to drawing a clean line between human identities and machine identities now has a third thing on the diagram, and the four design areas below are really the work of fitting that third thing into a model that did not anticipate it.

The audit trail you have to build

Here is the first design area, and it surprises people. Claude Code running on a local machine does not hand you a compliance-grade audit log by default. The cloud version, Claude Code on the web, does: Anthropic states that all operations in those managed environments are logged for compliance and audit. Local Claude Code is different. What you get is monitoring, through OpenTelemetry metrics that Claude Code can emit and that you have to wire into your own observability stack before they record anything. There is also a ConfigChange hook that can fire when someone alters settings mid-session. Both are real, and neither is automatic. The implication for a regulated company is direct: if an auditor asks what Claude Code did on a developer’s machine last quarter, the answer exists only if someone set up the telemetry to capture it first. The audit trail is not missing. It is opt-in, and opting in is a design decision you make before rollout, not after the audit.

What that telemetry should capture is the same short list any access log needs: who ran Claude Code, in which repository, and when, plus the configuration in force at the time. The OpenTelemetry route emits metrics you can send to whatever your organization already uses for logs, which means the audit story for Claude Code does not need a new system, only the decision to connect it to the system you have. Make that connection part of the rollout, the same week you configure the proxy, and the audit question is answered before anyone thinks to ask it.

There is a deployment lever hidden in this. Because the cloud version logs everything and the local version does not, the audit requirement can itself push a decision: a team with a hard audit mandate may choose Claude Code on the web precisely for the built-in logging, accepting the cloud execution model as the price of the audit trail. A team that needs local execution accepts that it owns the telemetry wiring instead. Neither is wrong. The point is that the audit question is not separate from the deployment-shape question; it is one of the inputs to it, and it deserves to be decided rather than defaulted.

Prompt injection is the live wire

The second design area is the one the security community now treats as the defining risk of agentic tools: prompt injection. The attack is quick to describe. Claude Code reads a lot of content it did not write, files, web pages, pull request descriptions, issue comments, and an attacker who can place text in any of those can try to smuggle in instructions, hoping the agent follows them as if they came from you. In April 2026, researchers showed this was not theoretical. A disclosure named “Comment and Control” demonstrated that a specially crafted GitHub pull request title could hijack agentic coding tools, Claude Code among them, into running commands and extracting credentials. Anthropic classified the issue as critical. The lead researcher, Aonan Guan, named the structural reason cleanly:

“These AI agents are given powerful tools (bash execution, git push, API calls) and secrets (API keys, tokens) in the same runtime that processes untrusted user input.” — Aonan Guan, security researcher, reported by SecurityWeek

Claude Code has real defenses against this, and they are worth knowing. Its web-fetch tool runs in a separate context window, so a malicious page cannot inject straight into your main session. Sensitive operations need approval. Suspicious commands require manual approval even when a similar command was allowlisted before. And Anthropic’s security documentation is plain about the limit, in a sentence every security team should internalize: these protections reduce risk, and no system is immune to every attack. That is the right way to hold it. Prompt injection is not a bug waiting for a patch; it is a structural property of giving an agent both untrusted input and real tools, and the defense is layered, the same posture prompt injection security takes everywhere. You reduce the blast radius. You do not pretend the wire is dead.

What does a security team add on top, then? Two things, mostly. The first is least-privilege tooling: the fewer tools and the narrower the command allowlist Claude Code carries into a task, the less an injected instruction can accomplish even if it lands. An agent that cannot push to a remote or read a credentials file is an agent a hijack cannot use to push or to read. The second is discipline about what the agent is pointed at. Prompt injection needs a delivery vehicle, an untrusted file or a hostile pull request from outside. Treat those inputs as the attack surface they are, and the most dangerous case, an agent with broad tools turned loose on unreviewed external content, never gets set up in the first place.

Permission modes and the policy file

The third and fourth design areas are about control, and Claude Code gives you real levers for both. Permission modes set how much the tool can do without asking. The default mode is read-only until you approve each action; plan mode goes further and makes no changes at all; at the other end, bypassPermissions skips the checks and, in Anthropic’s own words, offers no protection against prompt injection, which is why it belongs only in throwaway containers. Between them sit modes for accepting edits and for locked-down CI. The lever that matters for an organization, though, is not the mode a developer picks. It is managed settings, a policy file IT deploys that sits at the top of the precedence order and cannot be overridden by a user or a project. With it, an administrator can force a permission baseline, block bypassPermissions outright, and define exactly which tools and commands are allowed, fleet-wide.

Control over the network is the fourth area, and it overlaps with the install. The same proxy and allowlist that make Claude Code work also make it bounded: a tool that can only reach the domains you approved cannot exfiltrate to a domain you did not. Managed settings and the permission policy, together with a tight outbound allowlist, are the locked-down-network posture, and none of the three is a default you receive. Each is a decision an organization makes.

The reason managed settings is the load-bearing control deserves a moment. Claude Code reads settings from several places, and an enterprise-managed file outranks the user file and the project file both. A deny rule in that managed file cannot be overridden by a developer’s own settings or by anything checked into a repository. There are even a few keys that only work in the managed file and are ignored everywhere else, exactly so an organization can lock a decision that an individual cannot quietly undo. That precedence is what turns a policy from a suggestion into a control. Without it, every setting is advisory, and advisory security is the kind that holds right up until someone is in a hurry.

Designing that policy into something a security team will sign off on is work worth doing once, properly, before the tool is in a hundred developers’ hands. Blue Sheen helps organizations design exactly that.

A security baseline to start from

Pull the four areas into a baseline a security team can act on. Set a default permission mode no looser than acceptEdits, and use managed settings to block bypassPermissions across the fleet. Wire Claude Code’s OpenTelemetry output into your existing logging before rollout, so the audit trail exists from day one. Keep the outbound allowlist tight, exactly the Anthropic domains and nothing spare. Treat every MCP server as untrusted code until reviewed, because Anthropic lists connectors in its directory but does not security-audit them. And train developers on the one habit that matters most: be wary of pointing Claude Code at untrusted content, the random repository or the unreviewed pull request, because that is where prompt injection gets in. None of these is exotic. Each is a decision, made once, written into a policy file, and enforced from the top. That is what a defensible Claude Code deployment is made of.

The implication runs back to where this post started. An organization that treats Claude Code as an install gets a working tool and an undefined security posture, and the gap between the two surfaces at the worst time, during an incident or an audit. An organization that treats it as a design problem spends a few deliberate days up front and gets a tool its security team chose the shape of. The second path is not slower in any way that matters; it is the same rollout with the order corrected. And it is the antidote to the shadow AI problem too, because the reason people reach for unsanctioned tools is that the sanctioned ones were never made properly available. Design the deployment, and Claude Code becomes the safe, obvious choice instead of the thing security found out about later.