When AI agents get compromised, the first instinct is still to blame the model. A growing body of research says that instinct is incomplete. In August 2026, CSO Online reported a sharper framing: when agents fail, the code wrapped around the model is often the real problem, and most organizations aren't watching it closely enough.

That surrounding layer is the harness. Michael Bargury, co-founder and CTO of Zenity, calls it the model's hands and legs and eyes. Rob T. Lee of the SANS Institute describes the model as the engine and the harness as the chassis. Michael Sromin, senior ML engineer at Lasso Security, calls it the operating system of the agent loop. Omar Santos, distinguished engineer at Cisco, offers the formal version: "An AI harness is the layer that surrounds a model and makes it useful. This includes orchestration, tool use, prompts, context, roles, evals, guardrails, and the operational workflow that turns raw model output into bounded, repeatable action."

Four descriptions, one security problem. The harness is where the agent's authority gets exercised, sitting between the model's reasoning and a real filesystem, API key, or production database. If that is where authority lives, visibility and enforcement have to meet the agent there, across the surfaces where work already runs.

Model Safety Doesn't Equal Agent Safety

Most security programs have spent the last two years debating which models to approve, which prompts to ban, and which consumer AI destinations to allow. Those choices matter. They are not the same as governing what happens after the model starts acting on a user's behalf.

The research covered by CSO Online makes the gap concrete. Elad Meged, founding engineer and security researcher at Novee Security, broke into the official automation repositories of Anthropic, Google, and OpenAI using nothing more than GitHub issues. One vulnerability gave him code execution. One leaked credentials the harness believed it had stripped. Another let him plant instructions that a later, more privileged stage trusted without re-checking them. Three different bugs, one architectural mistake. Meged's summary of the pattern is worth memorizing: "Decide in one place, consumed in another with more power."

A second finding is more uncomfortable for teams that treat scaffolding as interchangeable plumbing. Lasso Security ran a thousand red-team attacks across five models and two off-the-shelf harnesses, holding the model, prompt, tools, targets, and scoring judge fixed and changing only the harness underneath. Averaged across the study, the two harnesses nearly tied at 21% and 19% attack success. The average is where the story hides. Drop to individual model-and-mission pairings and 43 of 100 flipped outright, meaning one harness broke into the target at least once and the other never did.

DeepSeek-V4-Pro shows the effect most cleanly. Under one harness it extracted system prompts 44% of the time and produced harmful content 17% of the time. Under the other harness, the same model reversed to 4% and 50%. Same tools, same twenty turns of work, roughly the same number of messages sent to the target. Only the wording each harness assembled around the model differed, and that alone decided which class of attack landed. As Sromin puts it, the harness is not adding or removing capability. It is steering it.

Two caveats keep this honest. Lasso is an AI security vendor and the study is its own, and its most dramatic single number, a model that moved from 1% to 24% on a harness swap, traces to a protocol translation bug rather than a security property. Lasso says so plainly. Research in cooperative settings finds smaller effects, with the ALE-Claw study on long-horizon computer-use tasks reporting the model mattered about three times more than the harness. The pattern that survives all of it is a gradient. Harness influence grows with adversarial pressure and task length, and it runs largest on the open, reasoning-forward models enterprises increasingly self-host. Heavily tuned commercial models barely moved. The recommendation follows directly: benchmark the harness and the model together, on the work you will actually run.

The Frontier Model Forum draws the same stack distinction in its June 2026 issue brief on agent security. Models, system guardrails and architecture, harnesses, and tools are separate layers with different controls. A well-aligned model sitting inside a permissive harness that trusts a wildcard shell pattern, reuses a contaminated workspace, or over-privileges a tool is still an enterprise problem. Securing the model isn't the same as securing the agent, and treating the harness as pass-through infrastructure is a security decision with sweeping effects on data protection and governance.

High-Fidelity Visibility Means Seeing the Full Chain

You cannot govern what you cannot reconstruct, and high-fidelity visibility is not a monthly inventory of approved chat apps. It is a live picture of the prompt and prompt response, the tool call and its associated response, the file touch, the MCP interaction, and the human or non-human identity that started the path.

That bar is hard because enterprises do not speak one language for AI. The same runtime shows up as an agent in engineering, a copilot in the business suite, a workflow assistant in operations, or a browser sidebar nobody filed a ticket for. Santos puts the inventory problem in exactly those terms.

"One team may call something an agent, another a copilot, another a workflow assistant, another a plugin-based automation, even though all of them are effectively harnesses." - Omar Santos, distinguished engineer, Cisco

Perfect coverage is not the entry price. Santos estimates organizations can reach 60% to 70% visibility relatively quickly by starting with production systems and leaving prototypes and shadow AI for a second phase. Build a live inventory of every production agent, identify its harness, map every tool and resource it can reach, then cut those permissions to the minimum the work requires.

Supply-chain events raise the stakes on live visibility. On July 11, 2026, attackers uploaded skills to the open registry skills.sh that typosquatted two popular tools, Paperclip and Browser Use. The skills were clean, and they stayed clean while they accumulated installs and trust. By August 2 they had passed 1.7 million combined downloads. Only then did the attackers add instructions telling agents to pull a credential stealer from GitHub and hunt for SSH keys, cloud credentials, database logins, and access tokens. Zenity Labs, which disclosed the campaign, found the malicious versions outranking the legitimate tools they copied. Every scanner on the market had cleared them, including official ones from Anthropic and Cisco.

Install-time scoring answers a question about a moment that has already passed. The live path is where the damage happens: a coding agent pulls the skill, opens a secondary document, clones a repository, and reaches for credentials already sitting on the machine. Bargury frames the exposure in one line. "You're sharing your laptop with your agents, and your laptop has everything. It has your identity, has your files, has your secrets."

This is the same shadow AI visibility problem security teams already feel with unsanctioned chat tools, except the blast radius now includes tool calls and filesystem access. Island Enterprise AI is built as a single control plane across all modalities of AI use, so teams can see the full chain from prompt to tool call to file across browser, desktop, network, and agent tooling rather than hoping a model catalog maps to operational reality.

Runtime Enforcement Has to Span Multiple Control Points

Visibility without enforcement is a very risky practice. Because agents move across tools and surfaces, a single inspection and enforcement point leaves gaps. Runtime policy has to evaluate actions before they complete, with limits that sit outside the model's own reasoning loop.

The Frontier Model Forum is direct about where the load sits. Deterministic controls placed outside the agent's reasoning loop, including limits on tool access and permitted actions that cannot be overridden through context manipulation, remain valuable, and agent security should not rely on detection alone. Detection is probabilistic. Permissions are not. The brief pairs that with the lethal trifecta: agents that combine access to private data, exposure to untrusted content, and the ability to communicate externally concentrate risk at every hop in the path. Containment that only lives in a coding sandbox, only in a network proxy, or only in a model gateway will miss the hops those controls never see.

Runtime enforcement therefore has to span the places enterprise work already happens. In the browser and across desktop applications, that means inspecting prompts, uploads, downloads, clipboard movement, and extensions in context. On the network, it means seeing AI destinations and data movement that never pass through a sanctioned chat UI. At the MCP and LLM gateway layer, it means governing which tools an agent may call, under which identity, with what audit trail.

Island approaches that map as one environment rather than a pile of point sensors. The deterministic layer is the MCP gateway, where defined permissions decide which tools an agent may invoke and under which identity. That boundary sits outside the reasoning loop, which means no amount of context manipulation talks past it. AI Protect supplies the other half, inspecting prompts, tool calls, and files inline and blocking or reshaping risky steps while the work is still in motion. Inspection is what makes the permission boundaries tunable, because no team can scope an agent to least privilege until it can see what that agent actually does. The same policy fabric extends across the Enterprise Browser, the Island Extension, Island Desktop, network services, and LLM gateway integrations, so humans and agents are not governed by two disconnected programs. The goal is proportional, context-aware control at the source, not another binary allow-or-block list that forces teams to choose between productivity and safeguarding. That is how enterprises expand governance to the AI workforce without freezing the work the business is already doing.

Scanners and Benchmarks Aren't a Substitute for Runtime

The strongest objection is fair. Better install-time scanning, vendor benchmarks, and model evaluations are necessary. Skills registries, signature checks, and red-team scores all reduce avoidable risk, and no serious program should skip them.

They are still not a substitute for runtime governance. Skills and harnesses change after approval. Defaults diverge from documentation. Vendor claims about blocked attacks may not match the combination of model, harness, tools, permissions, and external inputs your organization will actually run. A vendor citing a 99% prompt-injection block rate, Bargury notes, may be citing a benchmark that is not attached to reality on the ground. Meged distilled the lesson after breaking three vendors' official automations: "Read the defaults, not the documentation."

Supply-chain hygiene answers whether something should have been installed. Runtime control answers what it is allowed to do next: which tool call proceeds, which file can be read, which credential can be used, and which outbound action is in scope. Programs that stop at the first question leave authority ungoverned at the moment it matters.

Govern Agents Where Work Already Happens

Every major shift in enterprise infrastructure taught the same lesson. Security that arrives after the work surface is chosen ends up bolted on, delayed, and incomplete. AI is no different. The infrastructure for doing AI safely has to meet the infrastructure for doing AI at all.

That meeting point is the harness layer across the enterprise workspace. High-fidelity visibility of the full execution chain, plus runtime enforcement at multiple control points, is how teams say yes to agents without pretending model cards are a control plane. The model still matters. The place where tokens become action is where your governance either shows up or doesn't.

If you're evaluating how to govern agents where work already happens, schedule a demo and we'll walk through the control points in your environment.

FAQs

What is an AI harness in practical terms?

It is the software around a model that turns reasoning into work: orchestration, prompts, context, tools, guardrails, and the loop that issues shell commands, file writes, API calls, or MCP actions. If the model is the engine, the harness is the chassis and the controls.

Why isn't choosing a safer model enough for agent deployments?

Model choice shapes reasoning quality and some classes of misuse. Agent risk also depends on what the harness can see, which tools it trusts, which permissions it holds, and whether security decisions get re-checked before powerful actions complete. Lasso's red-team data shows the same model landing entirely different attack classes depending on the harness around it.

Does the harness matter more than the model?

Not universally. Research in cooperative settings finds the model dominates, while adversarial red-teaming finds the harness can decide whether an attack happens at all. The practical read is that harness influence grows with adversarial pressure, task length, and how open the underlying model is, so evaluate the pairing rather than either component alone.

What does high-fidelity visibility include beyond usage logs?

It includes the prompt, tool calls and responses, files and credentials touched, MCP and gateway interactions, and the identity that initiated the path, correlated enough that security can reconstruct what happened without guessing from destination counts alone.

How is runtime enforcement different from blocking AI tools?

Blocking removes a destination. Runtime enforcement stays in the flow of work and applies granular policy to specific actions, so teams can approve useful AI while limiting reads, writes, tool calls, and data movement that fall outside policy.

Where should security teams start if they can't inventory everything at once?

Start with production systems and high-privilege agents, map the tools and data those harnesses can reach, reduce standing permissions, and put monitoring plus deterministic limits on the actions that matter most. Widen coverage after the highest-risk paths are under control.

‍