The agent harness is the new attack surface

Anthropic is right about the architecture

Anthropic's recent guidance on Claude Code in large codebases gets the central architecture right: agent performance is not just a model-quality problem. It is a harness problem.

In a small repository, a capable model can brute-force its way through enough files to be useful. In a large codebase, that breaks down quickly. The agent needs a terrain map, scoped conventions, local commands, deterministic checks, symbol navigation, and a way to split exploration from editing. Without that surrounding system, the model burns context trying to discover basic facts about where it is and what rules apply.

That is the useful lesson in the article. The winning organizations are not merely buying access to a better coding model. They are shaping the codebase into an environment an agent can navigate.

The harness is not just productivity infrastructure

The missing piece is that every part of this harness is also a governance and security surface.

A root context file is not just documentation. It is a standing instruction source. A hook is not just automation. It is code that runs at privileged workflow moments. A skill is not just helpful expertise. It is a reusable behavioral package. A plugin is not just distribution. It is a supply-chain vehicle for skills, hooks, and tool configuration. An MCP server is not just integration. It is an authorization boundary between an agent and internal systems.

Once these pieces guide what agents read, write, execute, retrieve, and believe, they become part of the organization's control plane. Treating them as informal developer productivity glue is too weak a posture.

Context files create instruction risk

Layered context files are architecturally correct. They let the agent inherit broad repo knowledge at the root and local conventions in the relevant subtree. They also create a new instruction hierarchy that has to be governed like code.

If a context file can shape agent behavior, then stale, careless, or malicious context can misdirect an agent. It can tell the agent to skip tests, prefer an unsafe helper, ignore a class of failures, use the wrong deployment target, or route sensitive work through the wrong tool. In a monorepo, path-local context can become especially dangerous because it may be maintained by a narrow team while affecting any agent that enters that subtree.

The practical answer is not to abandon context files. It is to review them, version them, keep them lean, and distinguish durable architecture from temporary workaround instructions. Context debt becomes governance debt.

Hooks and plugins become supply-chain objects

Hooks are one of the highest-leverage parts of the harness because they turn repeated behavior into deterministic checks. Formatting, linting, test scoping, security gates, and session-capture workflows should not depend on a model remembering a paragraph of policy.

But a hook is also executable code. It may run before tool use, after file writes, at session start, or at session stop. That gives it access to project files, command output, environment variables, and sometimes credentials. A compromised or poorly scoped hook can leak data, weaken validation, rewrite agent instructions, or create false assurance around a bad change.

Plugins amplify that risk. They are how a working setup spreads across an organization, which is exactly why they need ownership, review, signing or provenance controls where possible, and a clear update path. Good setups should not stay tribal, but neither should executable agent infrastructure spread as unreviewed convenience packages.

MCP and LSP change what the agent can reach

MCP servers and LSP integrations are not optional details in large systems. MCP gives the agent structured access to tools, tickets, documentation, analytics, databases, and internal APIs. LSP gives the agent symbol-aware navigation so it can follow definitions and references instead of guessing with grep.

Those capabilities are exactly why they matter operationally. They are also exactly why they have to be permissioned. An MCP server that exposes too much internal data, accepts under-specified write operations, or returns untrusted content without clear boundaries can turn a coding assistant into a broad internal automation principal. An LSP or code-intelligence layer that points at the wrong workspace can make the agent confidently wrong at scale.

The governance posture should be explicit: least privilege by task class, clear separation between read and write tools, logging of agent-mediated actions, and review of tool descriptions because tool descriptions are themselves prompts that influence behavior.

Subagents introduce result-laundering risk

Subagents are useful because they isolate exploration. A read-only scout can map a subsystem and return a concise file list or design summary while the main agent keeps its context clean for editing. That pattern is sound.

The risk is that subagent output can feel like verified fact when it is only another model's report. If the parent agent treats that report as evidence without checking files, tests, logs, or source systems, the workflow has merely laundered uncertainty through a smaller summary.

The safe pattern is scout, cite, verify, then edit. Subagents should return concrete paths, commands, test results, or source excerpts. The parent should verify the handles before acting on them. This is especially important when the subagent touched security-sensitive code, production configuration, or external systems.

What teams should govern first

The right response is not to slow-roll agent adoption until every theoretical risk is solved. It is to recognize that the harness is now part of the software delivery system and govern it accordingly.

• assign an owner for agent configuration, not just tool procurement
• keep root context files short, reviewed, and focused on durable architecture
• move procedural expertise into versioned skills instead of bloating always-loaded prompts
• treat hooks and plugins as executable supply-chain artifacts
• separate read-only MCP tools from write-capable tools and permission them by task class
• log agent-mediated actions against the same audit expectations as human developer actions
• require scoped validation commands before agent-authored changes merge
• review the harness every few months because model improvements can turn old guardrails into drag

The bottom line

Anthropic is right that large-codebase agents need more than a better model. They need a harness: context, hooks, skills, plugins, MCP, LSP, subagents, and organizational ownership.

But that harness is not a neutral productivity layer. It is the new attack surface and the new governance surface. The same machinery that makes agents effective also determines what they can see, what they can run, what they can change, and what they believe. Boards and security teams should treat agent harness design as part of the secure software delivery lifecycle, not as a side project for enthusiastic developers.