The Claude Code Harness Is Your New Attack Surface

A widely shared best-practices piece on running Claude Code in large codebases made a claim that should get every security team's attention, even though it was written for engineering leads. The most important determinant of Claude Code's performance, it argued, is not the model at all. It is the harness: the ecosystem around the model, made up of CLAUDE.md files, hooks, skills, plugins, LSP integrations, and MCP servers. Get the harness right and a capable model becomes a great teammate. The uncomfortable corollary is that every one of those harness elements is editable configuration, and it is distributed across every developer's laptop and every repository you own.

Claude Code is Anthropic's terminal-based coding agent. Unlike tools that index your code into embeddings, it uses agentic search - it traverses the filesystem and greps the live codebase on demand, which sidesteps the stale-index problem. That is part of why the harness matters: the agent reads whatever is actually on disk, including the instruction files, hooks, and tool definitions that shape its behavior. What makes the harness powerful for productivity is exactly what makes it a security surface. This post reframes it as an attack surface, element by element.

The harness is the product you are actually deploying

When an organization rolls out Claude Code, the mental model is usually 'we adopted an AI coding tool.' The reality is that you deployed a configurable runtime whose behavior is determined by files sitting next to your source code. The model is the same for everyone; the harness is unique to each machine and each repo. A CLAUDE.md file steers what the agent does. A hook runs a shell command on a lifecycle event. A skill or plugin is an executable third-party bundle. An MCP server grants the agent reach into tools and data. None of these are hypothetical - they are the documented, intended mechanics of the tool, walked through in how Claude Code works.

For a defender, the shift is this: the thing you have to govern is not one binary with a version number. It is a spread of small, editable configuration objects, most of which a developer can add, change, or install without asking anyone. Each new feature widens that spread, a pattern we tracked feature by feature in Claude Code features in 2026. The harness is not a side effect of adoption; it is the thing you adopted.

Every harness element is also an input an attacker can edit

Look at each element the way an adversary would. A CLAUDE.md file is an instruction input, so a poisoned one is prompt injection with a persistence mechanism: it lives in the repo and loads automatically. Hooks run shell commands on lifecycle events, and because hook output can re-enter the model context they are also an injection path - the mechanics are in how Claude Code hooks work. Skills and plugins are executable third-party bundles, often installed from a marketplace, which is a supply-chain surface. MCP servers define the blast radius of what the agent can touch. And which of these run without a confirmation is decided by permissions, covered in how Claude Code permissions work.

None of these is a flaw; each is a deliberate, documented capability that makes the tool better. The point is that what a security team must now account for is not one application - it is a live, editable configuration graph spread across endpoints and repos. This is the same argument we make more broadly in securing AI coding agents and CLIs.

The layered CLAUDE.md pattern multiplies the instruction surface

The best-practices advice on CLAUDE.md is sound engineering: keep the root file lean with high-level pointers, and push local conventions into per-subdirectory CLAUDE.md files so the agent picks up the right context for whatever part of the tree it is working in. Teams are also told to scope test and build commands per subdirectory and to use .claude/settings.json for version-controlled exclusions of generated files. Every one of these is a real productivity win.

It is also a proliferation of instruction inputs. A large monorepo following this advice does not have one instruction file to review - it has dozens, scattered through the tree, each auto-loading when the agent enters its directory, each committed by whoever last touched that folder. The .claude/settings.json exclusions and per-directory command scopes are behavior-changing configuration living in version control where any contributor can edit them; the hardening choices for these files are laid out in the permissions and hooks hardening guide. The security question is not whether the pattern is good practice. It is: across all your repos and endpoints, do you know how many of these files exist, what they say, and when one changed?

The 'agent manager' is a governance role with nothing to enforce with

The same best-practices piece reaches a conclusion that is, in effect, a security recommendation dressed as a productivity one. It argues that organizations need a dedicated owner - a DRI, or an emerging 'agent manager' role - to curate plugins, MCP servers, and CLAUDE.md conventions, prevent fragmentation, and review the whole configuration every three to six months as models evolve. It also advises investing infrastructure work, like pre-configured plugins and MCP servers, before a broad rollout - the rollout mechanics themselves are covered in deploying Claude Code across a fleet.

Read that as a defender and it is a governance program: an owner, a curated allowlist, a review cadence, and a controlled rollout. The problem is that curation is unenforceable without visibility. You cannot curate a set of plugins you cannot enumerate, review CLAUDE.md conventions you cannot see, or catch a rogue MCP server on a laptop you never inspect. A quarterly review is only as good as the inventory it runs against, and on most fleets that inventory does not exist. This is the same gap we described across the ecosystem in the 2026 agentic AI visibility trends, and it is why fleet-wide review is a distinct discipline, laid out in auditing Claude Code across a fleet.

It also matters that this is not a one-time check. A plugin that was clean when the agent manager approved it can be updated in place, and a CLAUDE.md file that was benign at rollout can be edited in the next commit. The difference between checking configuration once and governing it continuously is the subject of scan-time versus runtime governance. And because most organizations run more than one agent, the curation problem spans tools with different config models, compared in Claude Code versus Codex versus Cursor permission models.

How Anomity makes the harness governable

The harness is powerful because it is local, editable, and per-developer. That is also why it is invisible to security: the CLAUDE.md files, the hooks, the installed skills and plugins, and the configured MCP servers all live on individual machines and in individual repos, and no central console shows them to you. The 'agent manager' role the best-practices piece calls for cannot function on aspiration alone. It needs an enumeration of what is actually deployed.

Anomity provides exactly that. A lightweight, unprivileged Endpoint Sensor runs on Windows, macOS, and Linux and inventories eight AI artifact types across every managed endpoint. Five of them are the harness itself: the AI agent and its CLAUDE.md instruction files, its hooks, its skills, its plugins, and its MCP servers - so the productivity surface and the security inventory become the same list. The sensor flags drift and new additions as they appear, sends metadata only, with secrets redacted on the endpoint, and where an agent exposes a hook it returns an allow, deny, or log decision at the Claude Code PreToolUse hook before the call runs. Every change and decision lands in a queryable 90-day audit trail routed to your SIEM, Slack, email, or Jira, and the platform is SOC 2 Type II. It complements your EDR, DLP, network, and GRC controls rather than replacing them, and both the deployment shape and where it sits next to your existing stack are documented.

You can't govern what you can't see.

The harness is what makes Claude Code good, and it is what turns every laptop into a small, editable slice of your attack surface. Turning the 'agent manager' aspiration into something enforceable starts with seeing the harness across your whole fleet, not one machine at a time. Request early access to inventory and govern it.