Coding Harnesses: The Attack Surface Hiding in Plain Sight
The Security Research team at Ent, like many engineering and data focused teams, spends an amazing amount of time leveraging popular coding harnesses such as Anthropic’s Claude Code and OpenAI Codex in our software engineering and research. Along the way, we've been researching these tools to understand the scope of this new attack surface.
While intended for software engineering, language model harnesses do far more than write code. They spawn agents that interpret text-based instructions, invoke tools, read and write files, and execute OS commands, often with little user interaction or awareness. Power users run multiple agents across sessions at once, and harnesses increasingly delegate work to subagents the user never sees. The same capabilities are now reaching less technical users through desktop agent apps, where the command line no longer filters who’s driving. This series focuses on Claude Code and OpenAI Codex, where our research was done, but we expect many of the findings to carry over to similar coding harnesses.
It’s clear that much of users' work is transitioning from the browser into these coding harnesses, which is reminiscent of when work moved from desktop applications to the browser. That transition opened the door to years of browser vulnerabilities and malicious or vulnerable extensions. Eventually, browser security improved, but our journey with coding harnesses may be more challenging. Unlike browsers, coding harnesses are designed to take instructions, read and execute files, run CLI commands, and do all of this with minimal human oversight.
A single malicious instruction buried in a repository or a Markdown file can lead an agent to download and execute code, expose credentials, or modify files using its existing permissions by invoking the model directly, without the user. Beyond local capabilities, harnesses are often connected to GitHub repos, ticketing systems, and internal knowledge bases, and can even allow remote control of the machine with just a few clicks. Just when you thought the problem couldn't get worse, consider the sheer number of built-in features and extensibility mechanisms that can be abused without exploiting a single vulnerability.
The underlying security problems are familiar, but the path from untrusted content to system compromise looks very different. Traditional indicators like hashes, domains, and command lines still matter, but they don't explain why an agent took an action. Detection engineering must now account for semantic intent, the deviations between what the user wanted to do and what happened, while defenders face the challenge of tracing agent behavior back to the instructions that influenced it.
The harness itself is not a security boundary; it’s an OS.
Current threat landscape fueled by AI
Every industry is currently being pummeled by one security incident after another. While those fires are burning, we're quietly deploying AI coding harnesses across our environments and endpoints without proper visibility or controls, and that's going to bite us eventually.
Ent has been tracking malicious content targeting agents: poisoned context files like AGENTS.md and CLAUDE.md, malicious SKILL.md files, and MCP servers. Most of that conversation focuses on what agents consume - the instructions, packages, and integrations an attacker can tamper with. That's only half of the equation; the harness is what gives the agent the ability to act on those instructions. It's the difference between a malicious sentence sitting in a repository and that sentence influencing commands executed on someone's workstation.
The harness is part of the attack surface
Codex, Claude Code, and similar tools aren't just chat interfaces with a terminal attached. They're execution environments with many ways to extend or automate what an agent can do.
Shell access, tool calling, filesystem operations, hooks, skills, MCP integrations, subagents, permissions, rules, and project-specific configuration. Not every harness implements these in the same way, and the details matter. Some features require approval. Others can be configured to run without interruption.
Our research team has identified roughly 100 security-relevant issues across coding harnesses. To be clear, not 100 CVEs, rather 100 different features and/or bugs that, through the lens of an attacker, become very attractive. Most involve legitimate features… and it gets complicated because a matrix of these features/bugs results in a myriad of attack paths.
The shape of this feels like a phishing attack and smells like a supply chain issue. Instead of the email carrying the link to the credential-harvesting site, or a malicious attachment, it includes a link to a malicious git repo. The attacker also has that huge toolbox of options to build a nefarious git repo… and the unsettling part is that the harness may be working exactly as designed when the user opens that repo in their coding harness.
Trust is more than a prompt
Developers clone repositories every day. It's a common part of the job, and they frequently have broad access to source code, credentials, cloud environments, and internal systems.
Consider what a repository can contain beyond code: context files that instruct the agent, configuration that changes harness behavior, and artifacts that extend its functionality.
A developer might ask the agent, "What does this project do?" or “Set this project up.” They probably don't expect that question to trigger a series of decisions based on untrusted repository content. Yet the agent may read those instructions, choose tools, delegate work, and execute commands before the developer understands what happened.
The developer might have clicked "Trust and continue" one time, but they’re never asked again. Trust once, attack forever. Real sandboxing and enterprise-enforced policies can constrain that risk. But an agent's instructions aren't a security boundary, and a trust prompt doesn't make untrusted content safe.
Detection gets complicated
Say an AGENTS.md file instructs the agent to download and run a "backup script" before making any changes. The same instruction could be written a hundred ways, each carrying the same intent.
Traditional indicators can still help. A hash, suspicious command line, or outbound connection can identify malicious execution. But those artifacts don't explain why an agent performed the action, and they may appear only after the damage has started.
Endpoint telemetry might show a shell running a script. It may not tell you which repository instruction influenced that decision, whether the agent delegated the work, or which configuration made execution possible.
We need to connect four things:
-> what the user intended,
-> what the agent consumed,
-> what it decided,
-> and what it executed.
That's a difficult problem when harnesses vary in their logging, expose different levels of agent activity, and sometimes obscure communications between agents. It also means detection engineering needs more than another list of IOCs. We need behavioral correlation and some understanding of semantic intent.
A command can be perfectly legitimate in one context and a serious warning sign in another. The context is the difference.
What can enterprises actually control?
Both OpenAI (via Managed Configurations) and Anthropic (via Managed Settings) provide enterprise controls for their coding harnesses. That's good. But how many organizations have reviewed them closely?
Which features are enabled? What can a repository configure? Can a developer override a policy? What can run outside a sandbox? What gets logged when an agent delegates a task? Can you see what subagents do?
Those questions get harder when developers use several harnesses, each with different settings and permission models.
Central policy, real isolation, least privilege, and endpoint visibility all matter. So does knowing which controls are actually enforced, not just presented to the agent as instructions. That difference becomes critical when an attacker can influence what the agent is being told to do.
What's next
We are not arguing that developers should stop using agents. The productivity gains are obvious. We are stating that these tools cannot be secured by only looking for malicious skills or treating an approval dialog as informed consent.
There is a need to understand the legitimate capabilities available to agents, how untrusted content can influence them, and what evidence defenders can recover when something goes wrong.
In our next blog, we'll show you how a developer can clone a repository, open Codex, accept its trust prompt, and ask an innocent question… only to have documented harness functionality lead to code execution and host compromise.
No software exploit. No malicious command typed by the developer. Just a few files, a trust decision, and an agent doing what it was told.
Request a demo to see how Ent protects human and agentic work. You can also read the Ent overview and the solutions brief to learn more.