{"id":9107,"date":"2026-08-12T08:25:00","date_gmt":"2026-08-12T08:25:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=9107"},"modified":"2026-08-12T08:25:00","modified_gmt":"2026-08-12T08:25:00","slug":"the-ai-harness-is-the-new-attack-surface","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=9107","title":{"rendered":"The AI harness is the new attack surface"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Ask a security researcher what makes an AI agent dangerous, and the instinct is to talk about the model \u2014 what it will and won\u2019t refuse, how easily it can be jailbroken, whether its weights can be trusted.<\/p>\n

That instinct is increasingly out of date. A growing body of security research \u2014 exploit demonstrations, independent red-teaming, and assessments by security researchers\u2014 points to the code sitting between the model and the world instead.<\/p>\n

That code, increasingly called the harness, wraps the model, gives it tools, and turns its token-by-token output into a shell command, a file write, an API call. It is also under-inventoried, under-tested, and frequently under-owned inside enterprises.<\/p>\n

Elad Meged<\/a>, founding engineer and security researcher at Novee Security, broke into the official automation repositories<\/a> of Anthropic, Google, and OpenAI using nothing more than GitHub issues.<\/p>\n

Researchers at Lasso Security found that swapping one piece<\/a> of supposedly neutral agent plumbing for another moved a model\u2019s attack success rate from 1% to 24% \u2014 using the identical model, prompt, and tools.<\/p>\n

And Michael Bargury<\/a>, co-founder and CTO of AI security firm Zenity, found attackers hiding credential-stealing malware inside AI \u201cskills\u201d<\/a> that had already passed every scanner on the market, including official ones from Anthropic and Cisco.<\/p>\n

The failures are different, but they share an important characteristic: None requires a model to become malicious or even behave unexpectedly. They exploit the software around it \u2014 the layer that determines what the model can see, what it can touch, and what happens when it acts.<\/p>\n

That\u2019s why a growing number of AI security researchers argue that the harness needs to be treated as an attack surface in its own right, rather than invisible scaffolding that arrives with the model.<\/p>\n

What a \u2018harness\u2019 actually is<\/h2>\n

Ask practitioners to define a harness and the metaphors converge from different directions.<\/p>\n

Bargury tells CSO he calls it the model\u2019s \u201chands and legs and eyes.\u201d The model itself produces tokens in and tokens out; the harness turns those tokens into a shell command, a file write, or an API call.<\/p>\n

Rob T. Lee<\/a>, chief AI officer and chief of research at the SANS Institute, describes the model as the engine and the harness as the chassis. Michael Sromin<\/a>, senior ML engineer at Lasso Security, likens it to the operating system of the agent, running the agent\u2019s loop and connecting the model, tools, and user. \u201cI see it as \u2026 an operating system that operates this entire \u2026 infinite loop of the agentic application,\u201d he tells CSO.<\/p>\n

Omar Santos<\/a>, distinguished engineer at Cisco, offers a more formal definition.<\/p>\n

\u201cAn AI harness is the layer that surrounds a model and makes it useful,\u201d Santos tells CSO. \u201cThis includes orchestration, tool use, prompts, context, roles, evals, guardrails, and the operational workflow that turns raw model output into bounded, repeatable action.\u201d<\/p>\n

The descriptions all point to the same security problem, namely that the harness is where an agent\u2019s authority gets exercised. It sits between a model\u2019s reasoning and a real filesystem, API key, or production database.<\/p>\n

\u201cSecurity teams should treat the harness as an attack surface because it is where the agent gets its authority, context, and paths to act,\u201d Santos says.<\/p>\n

And harness code has vulnerabilities just like any other software.<\/p>\n

A perfectly aligned model can sit inside a harness that trusts a wildcard shell pattern or reuses a workspace across two passes of untrusted content. At that point, the model\u2019s alignment is largely beside the point. The vulnerability isn\u2019t in the model.<\/p>\n

Three failure modes, one attack surface<\/h2>\n

Some of the most detailed research this year has exposed three distinct ways harnesses fail: architectural trust boundaries, implementation choices, and supply-chain compromise.<\/p>\n

Meged demonstrated<\/a> the first (architectural trust boundaries) at Black Hat after breaking into Anthropic\u2019s, Google\u2019s, and OpenAI\u2019s official automations using nothing more than GitHub issues.<\/p>\n

The recurring pattern, he said, was: \u201cDecide in one place, consumed in another with more power.\u201d<\/p>\n

Each vendor\u2019s vulnerability was different. One gave him code execution. One leaked credentials the harness thought it had stripped. Another let him plant instructions that a later, more privileged stage trusted without re-checking them.<\/p>\n

But the underlying architectural mistake was remarkably consistent. One component made a security decision and a more powerful component downstream trusted that decision without validating it again.<\/p>\n

That\u2019s not a model failure. It\u2019s a trust-boundary failure.<\/p>\n

Lasso\u2019s research exposes a second problem. Even without an exploitable coding mistake, the design of the harness itself can radically alter an agent\u2019s security.<\/p>\n

\u201cWhen you choose your LLM and the tools and everything, and you choose the harness, you get one agent,\u201d Sromin says. \u201cAnd when you choose another harness, you get a completely different agent.\u201d<\/p>\n

That is a bigger distinction than many organizations may realize. Some security professionals still treat the harness as little more than a pass-through loop \u2014 interchangeable plumbing between the model and its tools.<\/p>\n

Lasso\u2019s numbers suggest otherwise. Swapping harnesses under an identical open-weight model moved its attack success rate from 1% to 24% and flipped the outcome entirely on 43 of 100 model-and-task pairings.<\/p>\n

\u201cIt\u2019s not just an arbitrary choice,\u201d Sromin says. \u201cIt\u2019s a careful choice. It can really affect and move the needle in whatever you\u2019re doing out there.\u201d<\/p>\n

His recommendation is to benchmark the harness along with the model. Selecting one off the shelf without testing it means making a consequential security choice without knowing you\u2019ve made one.<\/p>\n

The harness\u2019s supply chain is rapidly expanding, Bargury\u2019s research at Zenity shows, and it\u2019s already being exploited.<\/p>\n

His team investigated \u201cskills\u201d \u2014 files that teach an agent how to perform new tasks \u2014 and found an old security problem appearing in a new form.<\/p>\n

\u201cThis is just a supply chain problem, resurfacing again with skills,\u201d Bargury said at Black Hat<\/a>.<\/p>\n

But agent skills create some unusual variations on that problem because they can alter the environment an agent repeatedly trusts.<\/p>\n

Every time an agent starts, for example, it can reload a memory file containing instructions about what it is supposed to do. Zenity found that a malicious skill could write itself into that memory. Delete the skill and the instruction to reinstall it remains, allowing the malware to return the next time the agent runs.<\/p>\n

Another malicious skill Zenity examined masqueraded as a legitimate Anthropic tool. Once executed, it deleted the real tool and replaced it with the attacker\u2019s version, leaving the agent running malicious code without an obvious change visible to the user.<\/p>\n

The most striking example was a campaign of cloned versions of popular open-source tools, secretly modified to steal login credentials. The malicious skills outperformed the legitimate tools they copied on skills.sh and accumulated roughly 1.7 million downloads<\/a> before the campaign was disrupted.<\/p>\n

The lesson across all three bodies of research is the same: Securing the model is not the same thing as securing the agent.<\/p>\n

What CISOs should know<\/h2>\n

For CISOs, the research points to three immediate problems: finding the harnesses already running inside the organization, controlling what they are allowed to touch, and independently testing whether their security controls actually work.<\/p>\n

The first may be harder than it sounds because most organizations don\u2019t maintain a category called \u201cAI harness.\u201d<\/p>\n

\u201cTeams think in terms of apps, services, pipelines, or bots,\u201d Santos says. Harnesses disappear into code repositories, SaaS products, and vendor configuration screens instead of showing up as discrete assets in security inventories.<\/p>\n

Even the terminology is inconsistent.<\/p>\n

\u201cOne team may call something an agent, another a copilot, another a workflow assistant, another a plugin-based automation,\u201d Santos says, \u201ceven though all of them are effectively harnesses.\u201d<\/p>\n

His recommendation is to build a live inventory of every production agent, identify its harness, and map every tool and resource it can access. Then reduce those permissions to the minimum required.<\/p>\n

Organizations shouldn\u2019t wait for perfect visibility. Santos estimates that 60% to 70% visibility can be achieved relatively quickly by starting with production systems, leaving prototypes and shadow AI for a second phase.<\/p>\n

The second problem is controlling everything the harness trusts.<\/p>\n

Agents don\u2019t operate in isolation. They ingest instructions and content from tools, plugins, skills, MCP servers, websites, and other systems, often while holding credentials and permissions that let them act on behalf of users.<\/p>\n

Attackers therefore don\u2019t need to compromise the model. They need to compromise something the harness is willing to trust.<\/p>\n

\u201cYou\u2019re sharing your laptop with your agents, and your laptop has everything \u2014 has your identity, has your files, has your secrets,\u201d Bargury says.<\/p>\n

For organizations without a dedicated AI security budget, he recommends, at minimum, running agents inside open-source containment tooling. \u201cThis is not a fix,\u201d he cautions, \u201cbut it is helpful.\u201d<\/p>\n

The size of the potential supply chain makes the problem qualitatively different from conventional software dependency management.<\/p>\n

\u201cSupply chain for software is, what, 10 or 15 package registries?\u201d Bargury says. \u201cSupply chain for agents is any content, any image, any text, any website, any CRM object, any skill, any MCP server, any content on the internet.\u201d<\/p>\n

The third problem is assuming a vendor\u2019s security claims transfer to the environment where an agent will actually run.<\/p>\n

A vendor claiming it blocks 99% of prompt injections, Bargury says, may be citing \u201ca benchmark that is not attached to reality on the ground.\u201d<\/p>\n

Lasso\u2019s findings demonstrate why that matters. Hold the model, prompt, and tools constant and change only the harness, and the security outcome can change dramatically.<\/p>\n

That means organizations evaluating agents may be asking the wrong question. It isn\u2019t simply which model is safest. It\u2019s which combination of model, harness, tools, permissions, and external inputs remains safe under the conditions in which the organization will actually deploy it.<\/p>\n

Meged distilled the lesson from breaking three vendors\u2019 official automations: \u201cRead the defaults, not the documentation.\u201d<\/p>\n

\u201cThe product said it was safe,\u201d he said, \u201cand that\u2019s where we started.\u201d<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Ask a security researcher what makes an AI agent dangerous, and the instinct is to talk about the model \u2014 what it will and won\u2019t refuse, how easily it can be jailbroken, whether its weights can be trusted. That instinct is increasingly out of date. A growing body of security research \u2014 exploit demonstrations, independent […]<\/p>\n","protected":false},"author":0,"featured_media":9108,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-9107","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9107"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9107"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9107\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/9108"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9107"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9107"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9107"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}