A root-owned settings file is the one thing on a developer’s laptop the developer cannot argue with. Everything downstream of it still can.
Why Claude Code Security Matters Now
Coding agents crossed a line this year that autocomplete never did. Claude Code, Cursor, Aider, Cline, Goose — they don’t just suggest a diff, they read the repository, write the files, and run the terminal commands themselves. Procurement moved fast because the productivity case was obvious. The security review, in most enterprises, is still catching up to what “agent” actually means on a developer’s machine: standing filesystem access, shell execution, and now a growing list of Model Context Protocol servers and third-party skills the agent can call without a human in the loop for each step.
The reflexive answer is a policy memo: acceptable-use language, a training deck, a line in the security handbook. None of that is enforced at the point where the agent actually acts. The one control that is enforced sits lower down — in the managed settings file that loads before the coding session even starts, and that the developer using it cannot edit, symlink around, or quietly disable. Understanding exactly what that file does, and where it stops, is the whole game.
| Metric | Value | Source |
|---|---|---|
| Organizations reporting an AI agent security incident this year | 88% | Ospiri research |
| Added breach cost where shadow or unmanaged AI tooling was a factor | up to +$670K | IBM Cost of a Data Breach Report 2025 |
| Typical enterprise timeline from AI coding tool pilot to enforced policy | 12–18 months | Ospiri research |
That gap — pilot now, policy in a year and a half — is exactly the window an unmanaged Claude Code install, an unreviewed skill, or an unapproved MCP endpoint lives in.
Three Layers of “Locked Down,” Only One Enforced at the OS
Ask a platform team whether Claude Code is “locked down” in their environment and you’ll usually get a confident yes, pointing at a settings file. The trouble is there are several files that go by roughly that name, and they sit at very different points on the trust ladder. Only one of them is actually tamper-resistant.
| Control layer | Who can change it | What it actually governs | Blind spot |
|---|---|---|---|
Project settings (.claude/settings.json, CLAUDE.md) |
Anyone with repo write access | Default permissions and allowed tools for that one repo | Forked, edited, or deleted with the rest of the checkout |
User settings (~/.claude/settings.json) |
The developer, locally | Personal defaults — allow/deny lists, auto-accept behavior | Lives on the same disk the agent has write access to |
Managed / enterprise settings (macOS root-owned plist, Windows registry policy, Linux /etc managed-settings.json) |
IT or MDM only | Cannot be symlinked, overridden, or edited by the session user; loads with no network required | Only covers what Claude Code itself reads at startup |
| Kernel / runtime enforcement | Security team, OS-level hook | Every file write, process spawn, and network call, regardless of which tool made it | Nothing — this is the layer built to close the other three |
Notice the pattern. The first three rows are progressively harder for a developer to bypass, and the third — machine-level managed settings — is a genuinely good control: it is root-owned, it survives a laptop wipe and redeploy through MDM, and it loads before the session has a chance to negotiate. Most enterprise Claude Code rollouts stop there, satisfied. That’s the mistake.
Where the Managed-Settings Model Breaks: Three Blind Spots
Managed settings answer one question well: which tools and MCP servers is this install allowed to call. They don’t answer what happens once something on that allow-list actually runs. Three patterns show up repeatedly in the field:
- The unsigned skill pulled off GitHub. A
SKILL.mdreads like documentation — bullet points, a description field — but its content is interpreted as instructions the moment the agent loads it. Managed settings can restrict which skills load; they don’t inspect what a permitted skill’s instructions actually tell the agent to do. - The MCP server pointed at an unapproved endpoint. An allowed local stdio server can still proxy a request to a remote host nobody reviewed. The connection itself is invisible to a settings file that only tracks which servers are configured, not where their traffic actually goes.
- The permission mode quietly widened. A project ships a
.claude/settings.jsonthat sets auto-accept for file edits inside a directory the reviewer assumed was scratch space, but that turns out to include a deploy script or a credentials path. Technically inside policy. Not what anyone intended when the policy was written.
None of these three requires the developer to do anything malicious, or even to notice. That’s the same shape of risk this publication keeps coming back to across agent categories: the control that stops the obvious case is easy to build; the control that catches the permitted-but-wrong case is the one that actually needs a runtime view.
The Blind-Spot Exposure Formula
Blind-Spot Exposure = (Unmanaged Endpoints × Session Autonomy) + (Unsigned Skills × Repo Write Access)
Read literally: exposure rises with every MCP server or tool outside the managed allowlist, multiplied by how much the agent can do without a human confirming each step, plus every unreviewed skill multiplied by how much of the filesystem that session can actually touch. Both terms are things a platform team can measure this quarter, not abstractions.
| Factor | What it measures | How to reduce it |
|---|---|---|
| Unmanaged endpoints | MCP servers and tools not on the enterprise allowlist | Enforce the allowlist at the OS layer, not only inside settings.json |
| Session autonomy | How much runs without a human confirmation — auto-accept edits, unattended shell commands | Default to confirm-on-write outside a scoped, sandboxed working directory |
| Unsigned skills | Skill or plugin files sourced from public repos without internal review | Require a review or provenance check before a skill is permitted to load |
| Repo write access | The actual scope of what the agent’s session can read and write | Scope sessions per project; explicitly deny credential and deploy paths |
What Managed Settings Gives You, and What They Don’t
It’s worth being precise about this, because vendors and platform teams both tend to oversell the settings-file layer once it’s deployed.
| Control point | What managed settings gives you | What it doesn’t |
|---|---|---|
| Tool allow/deny list | Enforced, root-owned, survives redeploy | No inspection of what an allowed tool does once invoked |
| Network egress | Can be paired with OS-level firewall rules | Claude Code itself has no native egress control of its own |
| Skill and plugin provenance | Can restrict install sources in some configurations | No content-level verification of a permitted skill’s instructions |
| Audit trail | Local session transcripts exist by default | Not centrally aggregated or correlated unless you build that pipeline |
This is the honest scope: managed settings are a real, enforced floor. They are not an audit function, an egress control, or a content scanner, and treating them as if they were is how a genuinely good control becomes a false sense of coverage.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1. Inventory | Enumerate every laptop running Claude Code, Cursor, Cline, Aider, or Goose against your MDM and EDR records | A real device count against the one in your asset system | Low |
| 2. Lock the floor | Deploy machine-level, root-owned managed settings as the enterprise minimum on every managed device | A tamper-resistant tool and MCP allowlist that survives a wipe | Medium |
| 3. Close the content gap | Add a review or scan step for skill files and MCP endpoints before they’re added to the allowlist, not only after an incident | Provenance checking that doesn’t rely on developer self-reporting | Medium |
| 4. Add the runtime layer | Deploy kernel-level observability that sees file, process, and network activity regardless of which tool generated it | Coverage for exactly the three blind spots above | Higher, phased |
The Bottom Line
Managed settings are necessary and not sufficient — they are the one Claude Code control a developer genuinely cannot argue with, which is exactly why every serious enterprise rollout should start there. What they don’t do is tell you what an allowed skill or an allowed MCP server actually did once the session started running. That gap is architectural, not a configuration mistake anyone can fix by writing a stricter policy file. If your team is sizing Claude Code, Cursor, or Copilot governance for this budget cycle, request a working session: we’ll walk through your fleet’s actual coding-agent footprint against your managed-settings baseline and scope exactly where kernel-level enforcement needs to sit. Ninety minutes, no slideware.