The harness matters more than the model: why harness engineering defines your AI projects

When something breaks in an AI-powered build, the reflex is almost always the same: “let’s switch models.” You try a different LLM, upgrade the version, compare benchmark against benchmark. And often the problem isn’t there at all. It’s in the harness: the layer of tools, permissions, memory, sandboxing, and rules that surrounds the model and defines what it can do, when, and within what limits.

What a harness is

A language model, by itself, is a function that predicts text. It doesn’t know how to read a file, run a command, or know which repository it’s touching or which credentials it has available. The harness provides all of that: the code that decides which tools get exposed to the model, how its actions get validated, what context it receives, and what happens when it gets something wrong.

Claude Code, Cursor, the SOC agents running automated playbooks, any system that connects an LLM to real-world actions, is at its core a harness. The model reasons; the harness executes, contains, and audits.

Why harness engineering is the real work

Picking the model is the easy part. Harness engineering is where it’s decided whether the system is useful, safe, and reliable:

• Tool surface: what the agent can do (read files, run commands, call APIs) and what it explicitly cannot do.
• Permissions and human confirmation: which actions require approval before executing, especially irreversible ones.
• Context and memory: what information the model receives on each turn, and what gets filtered or summarized to avoid overloading it or leaking sensitive data.
• Error handling: what happens when a tool fails, when the model hallucinates a parameter, when it tries something out of scope.
• Observability: being able to reconstruct afterward what the agent did and why, with the same rigor you’d apply to auditing any automated process.

Each of those points is a design decision, not an implementation detail. A poorly designed harness turns an excellent model into a fragile or dangerous system. A well-designed harness makes even a mediocre model produce reliable results, because what can go wrong is bounded from the start.

The parallel with offensive security

For anyone coming from pentesting or red teaming, this is familiar territory. An exploit is worth nothing without a well-contained payload, without control over the execution surface, without knowing exactly what it touches and what it doesn’t. The same is true for AI agents: the model is the potential exploit, and the harness is what determines whether that capability turns into something useful and controlled, or into an incident.

In fact, a large share of the AI security incidents we see today (prompt injection that escalates into command execution, agents with write access to systems they shouldn’t touch, data leaks from poorly segmented context) aren’t model failures. They’re harness failures: a missing boundary, a missing confirmation, missing sandboxing.

What to look for when building or evaluating a harness

1. Least-privilege principle for tools. If the agent doesn’t need to delete files, don’t give it that tool.
2. Explicit confirmation checkpoints for any irreversible action or one with impact outside the local environment.
3. Full traceability of every tool call, the same way you’d log any action with elevated privileges.
4. Isolation of the execution environment (containers, sandboxes, ephemeral environments) so an agent error has a bounded blast radius.
5. Periodic review of the exposed surface, the same way IAM permissions get reviewed: tools that made sense to grant the agent three months ago might not make sense anymore.

The takeaway

The model is going to keep improving, that’s inevitable and doesn’t depend on you. What does depend on you is the harness: the limits, the permissions, the memory, the audit trail. That’s where it gets decided whether an AI project is a reliable tool or a risk waiting to materialize. Investing in harness engineering isn’t an extra, it’s the part of the job you actually control.