The AI agent harness is becoming a new enterprise attack surface

Ask a security leader where the risk sits in an AI agent, and the answer usually starts with the model itself — whether it can be jailbroken, whether its weights can be trusted. That instinct is increasingly out of date. A growing body of exploit demonstrations, independent red-teaming and researcher assessments points instead to the code sitting between the model and the outside world. That code is called the harness: it equips a model with tools and turns its text output into real actions — a shell command, a file write, an API call. In many organizations, that layer is neither fully inventoried, nor tested, nor clearly owned by any team.

What an AI harness actually is

Ask practitioners to define it and the metaphors converge from different directions. Michael Bargury, co-founder and CTO of AI security firm Zenity, calls it the model's 'hands, legs and eyes': the model only produces tokens, and the harness turns them into a shell command, a file write or an API call. Rob T. Lee, chief AI officer and head of research at the SANS Institute, compares the model to an engine and the harness to the chassis. Michael Sromin, senior ML engineer at Lasso Security, describes it as the operating system running an agent's entire loop, connecting model, tools and user. Omar Santos, distinguished engineer at Cisco, offers the most formal definition: the layer that surrounds a model and makes it useful — orchestration, tool use, prompts, context, roles, evaluations and guardrails included. All four descriptions point to the same problem: the harness is where an agent's authority is actually exercised. It sits between a model's reasoning and a real filesystem, an API key or a production database. A perfectly aligned model does little good if the surrounding code trusts an arbitrary shell pattern or reuses a workspace with untrusted content across multiple runs.

Three ways a harness fails

Elad Meged, founding engineer and security researcher at Novee Security, showed at Black Hat USA how he broke into the official automation repositories of Anthropic, Google and OpenAI using nothing more than GitHub issues. The specific flaws differed by vendor — code execution, exposed credentials, injected instructions that a more powerful downstream component trusted without re-checking them. But the underlying architectural mistake was strikingly consistent across all three: one component made a security decision that a more powerful component further down the chain trusted without validating it again. 'That's not a model failure, it's a trust-boundary failure,' Meged says.

The second failure mode lies in the harness's own design, with no coding mistake required. Researchers at Lasso Security simply swapped the harness under one open-weight model, keeping the model, prompt and tools identical. The attack success rate moved from 1% to 24%, and the outcome flipped entirely on 43 of 100 tested model-and-task pairings. 'Choose a different harness and you effectively get a different agent,' Sromin says, recommending that organizations benchmark harness and model together instead of adopting a default configuration untested.

The third weakness runs through the harness's supply chain. Michael Bargury's team at Zenity examined 'skills' — files that teach an agent a new task — and found credential-stealing malware hidden inside ones that had passed every scanner on the market, including Anthropic's and Cisco's own. One malicious skill wrote itself into the memory file an agent reloads on every restart; deleting the skill left the reinstall instruction behind, so the malware returned the next time the agent ran. Another masqueraded as a legitimate Anthropic tool, deleting the real one after execution and replacing it with the attacker's version, with no visible change for the user. The most striking case was a campaign of cloned open-source tools secretly modified to steal credentials, which racked up roughly 1.7 million downloads before being caught and shut down.

• Inventory: catalogue every harness running in production, even ones labeled internally as a 'copilot,' 'workflow assistant' or 'plugin'
• Map access: identify exactly which tools and data each harness can reach, then cut those rights to the minimum needed
• Test independently: benchmark harness and model together rather than trusting a default configuration untested

Teams think in terms of apps, services, pipelines or bots. Harnesses disappear into code repositories, SaaS products and vendor configuration screens instead of showing up as assets in a security inventory.

What this changes for companies rolling out AI agents

For a company deploying AI agents internally — as an extension of Copilot-style tools, a homegrown automation, or an agent framework — the harness is still rarely tracked as its own line item in a security inventory. Santos's advice is not to wait for full visibility: 60% to 70% coverage is achievable relatively quickly by starting with production systems, leaving prototypes and shadow AI for a second pass. That maps onto obligations that already exist in several jurisdictions to document high-risk automated systems: the tool that actually executes an agent's actions belongs in the same inventory as the model. In practice, that means treating the harness as its own component in procurement and audit processes — with its own risk assessment, its own patch cycle, and least-privilege access, regardless of which model runs behind it.