The Rise of the AI Agent Harness: Securing Automated Coding

What is an AI agent harness

An AI agent harness is the software layer that sits between a language model and the real systems it acts on: the sandboxed environment, tool permissions, credential handling, and audit trail that turn a raw model call into a coding agent you can actually trust with a repository. The model writes the code. The harness decides what it's allowed to touch, records what it did, and catches it when it drifts.

The phrase is new but the instinct is old. "Agent = Model + Harness" is how the concept gets summarized across recent engineering writeups, and it's a useful shorthand because it draws a hard line between the intelligence and everything that keeps that intelligence from doing something destructive.¹

Why this is happening now

For the last two years, teams building coding agents mostly wired a model directly to an API key and a shell. That worked when usage was a developer running a CLI tool on their own laptop. It stopped working once companies started running agents unattended, overnight, across real codebases with real credentials.

The security data explains the urgency. Veracode's spring 2026 testing found that AI-generated code passes basic security checks only about 55% of the time, a number that has barely moved in two years even as syntax correctness has climbed above 95%.² Put plainly: models have gotten much better at writing code that runs, and almost no better at writing code that's safe. Java code fared far worse, passing security checks only 29% of the time, and cross-site scripting flaws slipped through in 85% of relevant tasks.²

That gap is exactly what a harness is built to close. It can't make a model reason better about SQL injection, but it can stop the agent from running unreviewed shell commands, block network egress to anything not on an allowlist, and force every risky action through a human checkpoint before it ships.

Three vendors, one pattern

Three recent releases show the industry converging on the harness idea from different directions.

DeepSeek Harness is an open-source, MIT-licensed "agent runtime" where every capability, including the sandbox itself, is a swappable plugin built on a kernel called Cordis.³ Its pitch is transparency: every run produces an append-only session log recording every tool call, every subagent handoff, and every piece of context the model saw, so a run can be replayed and audited after the fact rather than trusted blindly in the moment.³

Zed's Delta approaches the same problem from the collaboration side. It's a new application built around DeltaDB, a database that replicates an agent's conversation and its working code together in real time, so a team can review exactly what an agent did and why, comment on any line whether a human or an agent wrote it, and connect that history to third-party harnesses like Claude Code.⁴ The point isn't just oversight after the fact. It's making the agent's reasoning legible enough that review doesn't require reconstructing intent from a diff.

OneCLI attacks the credential problem directly. It's an open-source gateway that gives every employee's agent its own sandbox and routes its outbound traffic through a proxy that injects the real API keys and passwords at the network layer. The agent itself never sees a credential, and a policy layer decides what each agent's sandbox is allowed to reach.⁵ For teams handing agents access to production services, that separation between "the thing that acts" and "the thing that holds the secrets" is the whole security model.

Different design choices, same underlying bet: the model can't be the trust boundary. Something has to sit around it.

What a harness actually does

Strip away the branding and most harnesses share four jobs:

• Sandboxing. The agent's filesystem, network access, and process execution are confined to an isolated environment, often an ephemeral container or microVM, so a bad action can't touch production even if the model gets confused or a prompt injection succeeds.
• Credential isolation. Secrets are held outside the agent's reach and injected at request time, so a compromised agent session can't leak an API key it never held.
• Feedback loops. Linters, type checkers, structural tests, and even AI code reviewers run automatically after every change, feeding results back to the agent so it can self-correct instead of shipping a broken diff.
• Traceability. Every tool call, file edit, and decision is logged, so a human can reconstruct what happened and why, rather than trusting a summary the model wrote about itself.

Anthropic's own research into long-running coding agents illustrates why the second and third points matter so much. Left alone across multiple work sessions, its coding agent would try to build an entire application at once, run out of context mid-implementation, and then have the next session simply assume the unfinished feature was done.⁶ The fix wasn't a smarter model. It was harness design: a structured feature list the agent could not silently edit, a progress log written at the end of every session, and a rule that each session start by reading that log and re-testing the app before touching new code.⁶ That is harness engineering in miniature: guardrails that compensate for what the model, on its own, will not reliably do.

OpenAI's internal Codex team reached a similar conclusion at much larger scale. Building an internal product with, in their words, zero lines of manually-written code, the team found that architecture enforcement, structured documentation, and automated "garbage collection" passes mattered more than model quality once throughput got high enough that no human could review every change.⁷ Their team of three to seven engineers merged roughly 1,500 pull requests over five months, an average of 3.5 per engineer per day, a pace only sustainable because the harness, not human review, caught most problems first.⁷

What this means for teams building agents in-house

The shift from raw API calls to harnesses is really a shift in where accountability lives. When an engineer calls a model's API directly and pipes the output into a shell script, there's no layer recording what happened, no enforced boundary on what the agent could touch, and no built-in way to prove after the fact that nothing went wrong. That's the same shadow-AI risk companies already wrestle with when employees build their own internal tools with no oversight: useful, fast, and invisible to anyone who has to answer for it later.

A harness doesn't remove human judgment from the loop. It decides where that judgment is spent. Sandboxing and credential isolation handle the mechanical risks so a person only has to weigh in on the decisions that actually require it, like whether an agent should be allowed to delete data or send an email. For teams evaluating whether to build this scaffolding themselves or adopt one of these open frameworks, the honest starting point is the same question any build-vs-buy decision starts with: how much of your agent's activity can you afford not to be able to explain.

FAQ

Is an agent harness the same as a sandbox? No. A sandbox is one piece of a harness, the isolated environment where code actually runs. The harness also covers credential handling, tool permissions, logging, and the feedback loops that let an agent self-correct.

Do I need a harness if I'm just using Claude Code or Cursor? Those tools already ship with a built-in harness handling their own sandboxing and tool access. The gap shows up when you connect that agent to your own infrastructure, credentials, or unattended workflows, since the built-in harness wasn't designed around your specific access boundaries.

Does a harness fix the security problems in AI-generated code? Not directly. Independent testing still finds AI-generated code fails basic security checks in roughly 45% of cases.² A harness limits the blast radius of that code by controlling what it can touch and logging what it did. It doesn't make the model write safer code by itself.

Is DeepSeek Harness, Delta, or OneCLI the "right" choice? They solve different problems. DeepSeek Harness focuses on a swappable, traceable agent runtime. Delta focuses on team collaboration and reviewability. OneCLI focuses on credential isolation across a whole team. Most organizations will end up combining pieces of all three rather than picking one.

Is this just DevOps tooling with a new name? Partly, yes. Sandboxing, policy enforcement, and audit logs are old ideas from infrastructure security. What's new is applying them specifically to a system, the LLM, that writes and executes its own instructions and can be manipulated through the content it processes, not just through its API surface.