Harness engineering is the practice of building the layer, including code, that turns an AI model from a text generator into an agent that can take actions. In short, an AI agent is a model plus a harness. The model decides what to do next, and the harness makes it happen, connecting the model to tools, context, external systems, and validation. In a lot of practical work, and especially in security work, the harness decides the quality of the output more than the choice of model does.
What is a harness?
A harness is the orchestration layer around a model, or around many models at once. It's code, workflow logic, prompt design, and validation working together, with the model sitting inside as one component among several. The harness holds the logic that decides which model runs when, what context each one sees, how findings get checked, and when to escalate to a stronger model.
At its simplest, a harness is a short loop of code:
- Call the model
- Model requests a tool
- Harness runs the tool and returns the result
- Repeat until final results are achieved
As harnesses get more complex, they often use some of the following patterns:
- Prompt chaining: Sequential steps with checks between them, for a task that decomposes in a fixed order.
- Routing: A classifier sends each input to a specialized handler, and sends easy queries to a cheaper model while reserving the hard ones for a stronger model.
- Parallelization: Either splitting a task into independent parts or running the same task several times and aggregating the votes.
- Orchestrator-workers: A central model splits the job on the fly and delegates, for work where you can't predict the subtasks up front.
- Evaluator-optimizer: One model generates while another critiques in a loop until the output passes.
The harness is also often responsible for compaction, which is the process that condenses long conversation histories or transcripts by summarizing older messages into a dense block of text. Managing an LLM’s context window correctly also has a major impact on output quality and safety, which has created the new hot topic of context engineering (which we’ll save for another time).
Why you need a harness at all
If you're choosing between models, you're tuning only one variable. Frontier models have converged to the point where the spread between the top ones on standard coding benchmarks is relatively small. Wrap that same model in a weak harness versus a strong one, though, and the difference in what it can actually find is large. In many cases, the harness design will make more of a difference in quality output than the model.
Relying less on one specific model lets you adapt to changing times. Frontier models are facing some extra scrutiny lately and are falling out of favor with some. With the Hugging Face-OpenAI incident of July 2026, a frontier model attacked a company, but they couldn’t use a frontier model to defend, since frontier models regularly block cybersecurity-related tasks. Hugging Face had to use an open-weight Chinese model for their incident response (open-weight models are performing pretty well these days, fortunately). Being at the mercy of models’ refusal is not a sustainable plan going forward.
A capable model also can't run the job on its own. If you ask even the “best” model in a chat window to find the vulnerabilities in a repository, you’ll run into limits pretty quickly. For one, the codebase won't fit in its context, and even the parts it does see, it can’t really connect ideas across files. And of course, the results will be different each time because they’re non-deterministic. To find vulnerabilities effectively, a harness needs to keep a loop running and check what comes back. In our benchmarks of the latest AI models, we show why the harness is so important when finding vulnerabilities in code, and how a reachability check and a validation stage are what separate a pile of maybes from a list you can act on.
There's a cost argument too. Bigger models cost more per run, and ability doesn't scale one-to-one with price. Running several cheaper agents can beat one expensive agent for the same spend, since you can turn agent count into coverage. A cheaper model (generally) produces more false positives, so a harness can manage the multiple runs and filter the noise, with separate agents validating findings and clearing out the junk.
And when the work touches anything sensitive, the harness is the only place safety can live. Just prompting a model to be secure doesn’t cut it (we’ll get into this later).
What are some examples of AI harnesses?
Pretty much any LLM being used as a product is in some harness. Easy example: all of the coding agents that took over developer workflows in the last two years are harnesses wrapped around a frontier model.
Claude Code is Anthropic's terminal agent. It reads and writes code all through the same call-model-run-tool loop from above. The underlying agentic loop chooses tools, accumulates context, and manages long sessions through compaction, with permission modes and sandboxing setting the safety boundaries. Cursor's agent mode is the same idea inside an AI-first editor built on VS Code, where the harness drives editing multiple files from the IDE rather than the terminal.
The most famous harness might be OpenClaw, although arguably it has expanded beyond just a harness. Under the hood, it's a long-running Node.js service that connects an LLM to your Mac Mini and messaging apps. It supplies the gateway, the channels, context assembly, persistent memory, skills, and the loop that ties them together. OpenClaw is also a bit of a cautionary example of security being weak when the harness is loose about it, and the sandbox is essentially non-existent (we’ll revisit this in a bit).
For a detailed, real-world example, Cloudflare published its vulnerability-discovery harness stage by stage, built while pointing security models at dozens of its own repositories. The stages give a good picture of everything a mature harness does, particularly in a security context. Our own harness at Aikido looks similar at a high level— scouting a codebase for candidate entry points, ranking which suspicious flows to open up, digging into each one in depth, then triaging what comes back.
The harness’s role in AI safety and security
In the context of security, the harness is also partially responsible for containing the model, keeping it inside the bounds you set when it drifts off task or gets pushed off it by something in its input. It holds the soft boundaries, and they hold as long as your orchestration behaves the way you built it.
Guardrails like scope and logging need to be part of the tool layer that code controls. Because LLMs are non-deterministic and therefore unpredictable, even the most heroic attempts to control them with prompts alone can’t guarantee security. Prompt injection is one of the biggest problems with trying to control LLMs with prompts, because any attacker-controlled input that makes its way into the context can poison the LLM with enough convincing.
The security controls that the harness covers include:
- Scope control: Rules about what's in bounds, like which domains, hosts, or repos an agent may touch, and refusing to act outside that. In a harness, this looks like an allow-list that checks code runs before a tool fires as well as scope instructions in the prompt.
- Tool mediation: The harness decides which tools exist, what arguments are permitted, and whether a given call is allowed to run. The model can only request a tool, and the harness code chooses whether to execute it
- Context and input handling: Controls against prompt injection and untrusted content, like stripping or quarantining external data, limiting what the model reads, and not feeding it open internet content it could take instructions from.
- Validation and verification: Independent checks on what the model produces, like a second agent trying to disprove a finding, a reachability check, schema validation on output. This catches noise and hallucinations.
- Escalation and routing logic: Rules for when to hand a task to a stronger model, when to require a human, and when to stop. Circuit-breakers and stopping conditions live here too.
- Logging and observability: Recording every request and action so a run can be watched live, paused, or audited. This control lets you intervene when necessary.
- Rate and resource management at the app level: Rate-limiting and load-awareness so agents don't hammer a target or run away with cost.
In some cases, agents will be in a sandbox, generally when the agent interacts with live systems or is allowed to execute shell commands. The sandbox is the container the whole harness runs in and does the hard security enforcement, which includes the OS isolation, the network restrictions, the resource limits, and the separation from your internal infrastructure. Because those boundaries are enforced by the environment, the model can't cross them, whatever it decides to do.
Fun fact: You can also nest sandboxes inside the harness. If the harness gives the model a tool that runs commands, those commands can execute in their own separate sandbox, so a risky capability gets its own hard boundary without loosening the rest of the system.
AI harness security in the real world
Two recent cases show what happens when these boundaries fail, in different ways. OpenClaw shows what happens when the hard boundary is simply missing. The Hugging Face-OpenAI incident shows what happens when it's present but gets breached.
OpenClaw shows how this plays out when the layers are left to the user. It ships with the harness controls but treats the sandbox as opt-in, and by default the main session runs directly on the host machine with full access to its credentials and files. Sandboxing only covers the sessions it’s configured for, and even then some tools are flagged to run on the host anyway. So the common way to run OpenClaw is a capable harness with soft guardrails and no hard boundary underneath it, which is the setup behind its worst incidents. A harness without a sandbox is only as contained as its soft controls hold, and against a non-deterministic model they don't always hold.
The Hugging Face-OpenAI incident I mentioned earlier is a great (or not-so-great) example of the infrastructure around a powerful model failing to maintain security. OpenAI disclosed that, during an internal run of a benchmark, its own models broke out of the test sandbox and reached Hugging Face's production systems to pull the benchmark answers.
The incident shows what happens when both the model’s own judgment and the system around it are compromised at once. OpenAI’s model had been running with cyber refusals off, which is when the model or agents decline to do something you asked, operating on its training rather than any external rules. This makes sense for the testing OpenAI was trying to do, but it also creates serious security risks. In this incident, the surrounding system was entirely responsible for containing these agents instead of a prompt, namely the harness and the sandbox, and both failed.
Even OpenAI, who tried to implement a secure sandbox, was compromised by one vulnerable accessible package registry system. This is of course an extreme example but models will only get smarter, and in your sandbox you will have to account for this.
The design answer has to be architectural and multi-layered. Assess the risk of everything accessible to the agent. That's how we built our harness for our AI pentesting agents. The system separates the part that plans, reasons, and holds sensitive data (the control plane) from an isolated sandbox that runs tools, drives browsers, and touches the network (the execution plane) with strong network policies and software.
The execution side has no access to orchestration secrets or internal infrastructure, because the assumption is that execution can misbehave, and the harness can’t contain everything. This is where the sandbox comes in. The hard enforcement blocks any domain that isn't allow-listed at the network level so the agent can't reach it, whatever it decides to do.
AI harnesses, now and in the future
The model gets the attention, but the harness does a lot of work. It's what turns capability into the best findings, as well as manages many security controls. Large tech organizations are focusing on harnesses, for internal use and as a service. Microsoft recently released a harness framework as a product. As long as we have LLMs, we’ll be containing them in harnesses, so this discipline is only just beginning. We’ve only scratched the surface in this post, but you can also continue AI learning on this awesome page about harness engineering.
Pick your model well, but then spend your serious effort on the harness. That's why we build our own tools, including Aikido's AI Code Analysis and AI Pentesting, as harnesses first.
FAQ
What is a harness?
A harness is the orchestration layer around one or more models. It's the code, workflow logic, prompt design, and validation that turn a model into an agent that can act, deciding which agent runs when, what context each one sees, when to escalate, and how the output gets checked.
What's the difference between the harness and the model?
The model supplies reasoning and language. The harness supplies everything else, the tools, the memory, the loop, the validation, and some scope controls. Swap the model and the harness stays. That's why a strong harness lets you upgrade models without rebuilding your system.
Is harness engineering a real discipline?
It's become one. As frontier models converge on capability, the orchestration around them is where most of the practical difference in output now comes from, which is why teams are investing in harness design as its own body of work.
How does harness engineering apply to security?
In security the harness does two jobs. It raises the quality of findings through narrow scoping and independent validation across parallel agents, and it contains the agent through architectural isolation and network-level scope enforcement, so an agent can't wander into production or leak data.
What are AI agent guardrails?
Guardrails are the constraints that keep an agent inside its intended scope, things like sandboxing, allow-listed domains, rate limits, and a hard separation between the planning layer and the execution layer. The reliable ones are enforced in code and infrastructure rather than requested in a prompt, so the model can't ignore them or be talked past them.