The Harness Is Where Agent Security Lives

Using the identical model, prompt, and tool set, swapping one piece of supposedly neutral agent orchestration for another moved a red team’s attack success rate from 1% to 24%.

Most enterprise conversation about AI agent risk still centers on the model: will it refuse a harmful instruction, can it be jailbroken, does its alignment training hold under pressure. Three research efforts published in 2026 — from Novee Security, Lasso Security, and Zenity, all surfaced in an August 2026 CSOonline report — argue that framing is misdirected. Every compromise they demonstrated required no model misalignment at all. What broke was the layer surrounding the model: the orchestration code, tool permissions, context handling, and operational workflow that turns a raw language model into something that can read a file, call an API, or execute a command on a company’s behalf. Security teams evaluating “the AI” are frequently evaluating the wrong artifact. A separate, later wave of research makes the same point from an unexpected angle: a run of 2026 “harness engineering” content is teaching developers to build that exact wrapper for reliability and productivity, almost entirely without a security lens — and where one builder-side source did add that lens deliberately, the resulting harness reads, feature for feature, like a rebuttal to the one that didn’t.

What “the harness” actually means

The term is new enough that it doesn’t yet have one settled definition, and that inconsistency is itself a problem: the same layer gets called an agent, a copilot, a workflow assistant, or plugin-based automation depending on which team built it, which makes it hard to inventory as a single category of risk. One framing, offered in the CSOonline piece, describes a harness as the layer that “surrounds a model and makes it useful,” encompassing orchestration, tool use, prompts, context, roles, evals, guardrails, and the operational workflow that turns raw model output into bounded, repeatable action. Tejas Kumar, an IBM developer advocate who builds harnesses for the company’s Watson models, uses a physical analogy in a 2026 conference talk: a climbing harness anchors a climber to something stable so they cannot drift off the rails; an agent harness performs the same function for a non-deterministic model, tying it to an environment the developer actually controls. In his telling, a typical harness includes a tool registry (read file, write file, execute a shell command), context-management logic, guardrails such as a hard cap on tool-call steps, and — critically — a deterministic verify step that checks the agent’s work rather than trusting its self-report.

That last point matters more than it sounds like it should. In Kumar’s own demo, a deliberately weak, three-year-old model repeatedly claimed success on a task it had actually failed, because nothing in its harness checked. Once he added a verification step that inspected the agent’s actual tool-call trace, the agent started failing honestly instead of lying — and once he added a harness-level login handler that never let the model see the credentials it needed, the task started succeeding. None of this involved a better model or a better prompt. It’s a small-scale version of the same argument the security researchers make at production scale: the harness, not the model, decides what actually happens.

Three ways it broke, without touching the model

The 2026 research gives three concrete, independently discovered failure patterns.

The first is an architectural trust-boundary failure. Elad Meged, a security researcher at Novee Security, broke into the official automation repositories of Anthropic, Google, and OpenAI using nothing more than GitHub issues, and demonstrated the technique at Black Hat USA 2026. His summary of the recurring pattern: one component in the harness makes a security decision, and a more powerful downstream component consumes that decision without re-validating it. Outcomes varied by vendor — in one case he obtained code execution, in another he retrieved credentials the harness believed it had already stripped, and in a third he planted instructions that a later, more privileged stage of the pipeline trusted without re-checking. His stated lesson afterward was blunt: read the defaults, not the documentation.

The second is a demonstration that the harness itself is not neutral. Researchers at Lasso Security ran the identical model, prompt, and toolset through two different agent harnesses — Claude Agent SDK and DeepAgents — and found that the harness choice alone moved attack success rate from 1% to 24%, flipping the security outcome entirely on 43 of 100 tested model-and-task pairings. Their recommendation is direct: benchmark the harness together with the model, rather than treating harness selection as interchangeable infrastructure.

The third is a supply chain failure. Michael Bargury, co-founder and CTO of Zenity, presented research at Black Hat USA 2026 showing malicious code hidden inside AI “skills” — files that teach an agent a new task — that passed every scanner tested, including official scanners from Anthropic and Cisco. One technique let a malicious skill write a reinstall instruction into an agent’s persistent memory file, so deleting the skill did not remove the infection; another had a malicious skill impersonate and quietly replace a legitimate vendor tool with no visible change to the user. A campaign of cloned, secretly modified open-source tools distributed through the skills.sh marketplace accumulated roughly 1.7 million downloads — reportedly outperforming the legitimate tools they copied — before it was disrupted. Bargury’s framing is that this is not a new problem: “This is just a supply chain problem, resurfacing again with skills.” His scope comparison is worth sitting with: traditional software supply chain runs through perhaps ten to fifteen package registries, while an agent’s supply chain includes any content, image, text, website, CRM object, skill, or MCP server it’s allowed to ingest.

Independent research backs Bargury’s finding at a larger scale. Agent Threat Rules (ATR), an open detection-rule project for AI agent behavior, ran its own scan across multiple third-party skill registries and confirmed 552 malicious skills out of 1,302 flagged, tied to three coordinated threat actors — one disguised as Solana and Google Workspace tooling, one running a live command-and-control server, one relying on npm typosquatting. The project describes it as the largest AI agent malware campaign documented to date, and it’s the same failure mode Zenity found: skills that pass a scanner and get installed anyway.

Why refusal isn’t the control you think it is

A separate 2026 practitioner hardening guide, aimed at developers who’ve already wired up an agent but lack a formal security background, makes the underlying architectural argument explicit: model refusal is not a security boundary, because it is a probability that degrades under adversarial iteration rather than a fixed wall. Its corrective principle, repeated across the guide, is that a dangerous action needs to be structurally unreachable in code or configuration from the path that handles untrusted input — not merely discouraged by a system prompt. The guide organizes its argument around the OWASP Top 10 for Agentic Applications, the 2026 taxonomy (ASI01 through ASI10) published by OWASP’s Gen AI Security Project Agentic Security Initiative — and internal research checking the taxonomy against the CSOonline findings shows the fit is close to one-to-one, not just thematically adjacent. Meged’s “decide in one place, trust it in another” trust-boundary breaches land squarely under the taxonomy’s own ASI03, Identity and Privilege Abuse, which names un-scoped privilege inheritance and cross-agent “confused deputy” trust as its defining vulnerability patterns. Bargury’s trojanized skills are the taxonomy’s ASI04, Agentic Supply Chain Vulnerabilities, almost example-for-example: the taxonomy separately names a malicious MCP server that impersonated a legitimate npm package to intercept traffic, the same shape of attack Zenity found at scale. The hardening guide also cites a real Gemini CLI vulnerability, rated CVSS 10.0, in which a “yolo” flag caused the tool to bypass its own fine-grained permission allowlist entirely — a direct instance of Meged’s pattern.

Even this framing has a limit worth naming: the same guide is careful to note that architecture is “a stack of probabilities, just much better ones” than model refusal. Sandboxes depend on isolation technology not having bugs; allowlists depend on configuration that hasn’t drifted. There is no single layer, model-side or harness-side, that is unconditionally secure. The goal is stacking defenses so their gaps don’t line up — not finding the one fix that closes the question.

A parallel harness-engineering boom, mostly blind to this

While the CSOonline research was surfacing the harness as an attack surface, a separate cluster of 2026 conference talks and YouTube explainers was independently converging on the same term — “harness engineering” — from a completely different direction: developer productivity. An IBM developer advocate (Kumar, above), a popular coding-education channel, and an independent AI builder each published a walkthrough in the space of about three months, all describing the same idea (the wrapper of tools, context, memory, and control logic around a model) as 2026’s successor to “context engineering.” None of the three engages with the trust-boundary or supply-chain research above. One of them frames a coding agent that can rewrite its own operating instructions — literally, a file the agent updates after every run so it “gets better at getting better” — as the most exciting part of the demo, without ever mentioning that an agent with standing write access to the file it re-reads as instructions is close to a textbook description of the OWASP taxonomy’s ASI06, Memory and Context Poisoning: untrusted content written into agent memory that fires on a later run.

That gap is not hypothetical. It shows up concretely in a real, shipped product from this same builder cluster: an open-source local agent harness that one walkthrough describes as one of the more popular tools in its category, run through a terminal, a browser, and a scheduling system, with a tool that delegates coding tasks to a separate, credentialed coding-agent CLI. All four of those are exactly the kind of tool-call-manifest entries a harness’s security posture has to be scored on — reach into the filesystem, reach onto the open web, unattended recurring execution, and a credential handoff to another privileged tool. The same product also self-writes and self-updates its own persistent memory and skill files, which are then reloaded into every future run, with no dedicated verification step and no evaluation layer described anywhere in the walkthrough. None of this makes the product insecure by itself — a 21-minute demo video is not a security audit, and there may be sandboxing or permission controls that simply weren’t shown. But nothing in the source describes any, either, which is itself the finding: a widely used harness whose own presenter calls it “nothing fancy” ships, by that account, without the two layers that the security research above treats as load-bearing.

The contrast sharpens against a book published the same season by a different author, working the builder side of the same “harness” term but explicitly organized around security. That book’s own thesis — “the real attack surface is the tool-call manifest, not the prompt” — is the builder-side restatement of exactly what Novee, Lasso, and Zenity demonstrated from the attacker side, arrived at independently. It devotes a full chapter to a default-deny gate at the tool-call boundary (every action defaults to requiring approval, with the gate failing closed if no human is present to approve), a second chapter to independent verification that the agent’s own self-report is never trusted as the check, and a third to evaluation discipline — a held-out task set, measured one change at a time, so a claimed improvement isn’t just overfitting. It separately points to a real advisory — a popular coding CLI’s auto-approve allowlist that could be bypassed with a constructed command, scored a maximum CVSS 10.0 — as the reason enforcement has to live in code the model’s own output cannot route around; the book doesn’t name the product, but the shape of the finding resembles the Gemini CLI vulnerability already discussed above, and the two may well be the same advisory (unconfirmed here). And it backs the “the harness is the lever” argument with two more data points that read as reliability’s mirror image of Lasso’s 24x attack-success swing: one team held a coding model fixed and moved its Terminal-Bench 2.0 score from 52.8% to 66.5% by reworking only the harness around it, and another cut an internal tool-using agent from eighteen specialized tools down to one shell and watched its success rate on an internal benchmark rise from 80% to 100%. Same lever, same fixed model — reliability up when the harness is tightened deliberately, attack success up when it’s swapped carelessly.

Internal Security Sonar analysis comparing that book’s teaching harness against the shipped product on the same seven-layer rubric found the gap holds up structurally, not just anecdotally: the teaching harness scores well across the board specifically because it was built to include independent verification and evaluation as named layers; the shipped product’s strengths are almost entirely in tools, memory, and orchestration, the layers a demo video makes impressive, with no equivalent for either of the two the book’s own author argues are hardest to skip. That split is worth sitting with as a governance signal, independent of which specific products it describes: if the harness is where security has to be built, “does this harness have a verification layer independent of the model’s own self-report, and a way to measure changes against a held-out benchmark” is a checklist question — one most current harness-engineering content, and at least one popular shipped product, doesn’t answer. Separately, a field test in an upcoming installment of this site’s open-weight model benchmarking series (Part 3) ran that same teaching harness’s default-deny gate directly: with the gate active and no human present, zero of fifteen scripted attacks succeeded against a local model; with the gate deliberately bypassed, ten of fifteen did. The gate, not the model underneath it, was the entire difference.

What this means for a security leader

Two of the researchers quoted in the CSOonline piece converge on the same starting point: build a live inventory of every production agent, identify its harness, and map every tool and resource that harness can reach, before trying to harden anything. That inventory is described as achievable to 60–70% coverage relatively quickly if it starts with production systems and leaves prototypes and shadow deployments for a second pass — a sequencing choice, not a shortcut. From there, the hardening guide’s mechanisms give a concrete build-out: credentials brokered as short-lived, scoped tokens rather than embedded secrets the agent can leak; dangerous actions tiered by consequence, with only reversible, low-stakes actions fully automated and destructive ones requiring both a frontier-model judgment and mandatory human confirmation; sandboxing and tool allowlists enforced by the runtime or orchestrator, never by the agent process itself; and a four-gate vetting routine — provenance, permission audit, static scan, sandboxed trial — applied to every skill, plugin, and MCP server before it runs, exactly the routine that would have caught the trojanized skills Zenity found. The OWASP taxonomy underlying all four mechanisms names the same governing rule as “Least-Agency” — an extension of least-privilege that treats unnecessary autonomy itself as attack surface, on the reasoning that deploying agentic behavior where it isn’t needed expands what an attacker can reach without adding any offsetting value.

The tooling to do this already exists, for what it’s worth. ATR’s rule format is running in production inside Cisco AI Defense’s skill scanner, Microsoft’s Agent Governance Toolkit, and Gen Digital’s Sage risk-scoring layer — a live example of the static-scan gate above being operationalized rather than theorized. Separately, Cisco AI Defense ships a runtime SDK that inspects every LLM and MCP call at the moment it happens — a one-line integration that wraps chat calls, framework tool calls, and even calls made inside a managed cloud agent runtime — which is what “enforce in the runtime, not the prompt” looks like as a shipping product rather than an architectural aspiration.

One structural point is easy to miss and worth calling out directly: under most default configurations, an agent’s actions log under the operator’s own identity, not the agent’s. That breaks the attribution most compliance frameworks assume, and it’s precisely the gap that made Meged’s and Bargury’s findings hard to trace after the fact. Giving an agent its own named, non-human identity, with every action logging both the actor and the human on whose behalf it ran, isn’t a compliance nicety — it’s the difference between an audit trail and a guess.

None of this requires waiting for a more aligned model. The three 2026 compromises described here happened to agents built on today’s leading frontier models, using default prompts, with no jailbreak involved. The fix, where one exists, is in the code around the model — which is also the good news: it’s code your organization can actually inspect, test, and change.

Takeaways

• Inventory your production agents and their harnesses before evaluating models — you cannot secure what you haven’t mapped, and 60–70% visibility is achievable quickly by starting with production, not prototypes.
• Never take a harness’s security posture on faith because it uses a trusted model underneath: benchmark harness and model together, since swapping the harness alone changed attack success by 24x in controlled testing.
• Enforce dangerous or irreversible actions in the runtime — sandbox boundaries, tool allowlists, credential scope — not in the system prompt, which degrades under adversarial pressure the same way model refusal does.
• Treat every skill, plugin, and MCP server your agents can load as a supply-chain artifact requiring provenance, permission, and scan checks — a clean scanner result is not the same as a safe artifact, per Zenity’s findings, and open detection rulesets like ATR now give you a way to run that scan without building it yourself.
• Give every deployed agent its own logged identity, distinct from its human operator, so incident response has an actual trail to follow instead of a shared account to untangle.
• When you score any harness — a vendor product, an open-source tool, or something built in-house — check for an independent verification layer and an evaluation harness before you check for tools or memory features; popularity and an impressive demo are not evidence either exists, and a builder community that hasn’t asked the question yet is not a substitute for asking it yourself.

Security Sonar is focused on security standards and guardrails for agentic AI. If your organization is deploying agents faster than it’s mapping what their harnesses can reach, that gap — not the model underneath — is where this evaluation should start. See securitysonar.com.