Agent harnesses are replacing frameworks in AI systems

At a glance

What this is: Arize argues that AI agent harnesses are replacing frameworks because the running control loop now determines decomposition, retries, sandboxing, context management, and reporting.

Why it matters: For IAM and AI governance teams, this matters because the harness becomes the place where execution rights, tool use, and operational accountability concentrate.

Context

An agent harness is the runtime control loop that decides how an AI agent breaks down work, retries tasks, manages context, isolates execution, and reports outcomes. That shifts the security and governance problem from design-time orchestration to run-time control, where behaviour is measurable but also easier to misuse or misconfigure.

For practitioners, the key issue is that the most consequential decisions now happen inside the loop around the model, not in the prompt itself. Where an agent can call tools, spawn subtasks, or run code, the harness becomes the control point for authorisation, observability, and failure containment.

The article's underlying message is typical of the current agent tooling market: the layer that looked like plumbing is becoming the product surface, and with it the place where governance must attach.

Key questions

Q: How should security teams govern AI agents that run inside harnesses?

A: Treat the harness as the runtime authority layer and apply identity controls to the session, not just the model. Limit credential scope, isolate execution, log tool use, and make every retry and recovery step visible. If the harness can act independently, it needs the same governance discipline as any other privileged non-human identity.

Q: Why do agent harnesses change the risk profile of the same model?

A: The harness determines how context is assembled, which tools are available, and whether decisions are rechecked before action completes. Two environments using the same model can therefore produce very different security outcomes. In practice, the surrounding orchestration often matters as much as the model’s raw capability.

Q: What are the signs that an agent harness is failing in practice?

A: Common signs include plausible but wrong outputs after truncation, repeated loss of earlier constraints, bloated token counts from always loaded tool schemas, and debugging that feels like archaeology because step level telemetry is missing. Another warning is when every session behaves as if it needs the same isolation and approvals, even when only a few actions are actually risky.

Q: What should teams do when an agent runs code or handles files inside a sandbox?

A: Require narrow task scope, ephemeral execution boundaries, and explicit permissions for every action that touches code or files. The sandbox should reduce blast radius, not become an open-ended workspace. If the agent can expand its own authority inside the runtime, the control boundary is too weak.

Technical breakdown

Why harnesses displace agent frameworks

A framework is a construction kit for humans building agent workflows. A harness is the live runtime that already contains the loop, context handling, tool invocation, retry logic, and execution boundaries, so the user supplies a goal rather than assembling every step. That matters because it moves engineering value from wiring components to governing how the loop behaves under load, error, and ambiguity. In practice, the harness is where tool choice, task decomposition, and recovery decisions are made repeatedly, not once at design time. For security teams, that means the meaningful control surface is operational and continuous, not just configuration-based.

Practical implication: Treat the harness as a governed runtime and review its decision points as part of AI system control design.

Sandboxing and permission layers in agent execution

Modern harnesses increasingly wrap agent actions in sandboxes and permission layers so code execution, file access, and tool calls happen inside bounded environments. That is not just an engineering convenience. It is a containment model for agent behaviour, especially when the agent can reason, execute commands, and manage context on its own. The difference between a safe task and a risky one often sits in the limits of the runtime, not in the model response. When the sandbox is ephemeral and scoped correctly, the harness can reduce the blast radius of errors and constrain unintended actions.

Practical implication: Define execution boundaries for every agent task and make sandbox scope part of your approval and audit model.

Observability turns harness behaviour into evidence

If the harness is the product, traces, retries, tool calls, and success trajectories become the evidence of whether it is working. That is why outcome-only evaluation is insufficient: two agents can reach the same final answer while one burns through tokens, spawns unnecessary subagents, or repeatedly recovers from the same failure. The relevant question is not just whether the task completed, but what the loop did to get there. This is also where evaluation and governance meet, because a harness that cannot expose its own trajectory cannot be reliably tuned, audited, or compared.

Practical implication: Instrument agent trajectories, not just final outputs, and use those traces as the basis for control and evaluation decisions.

Threat narrative

Attacker objective: The objective is to influence the agent's runtime control loop so that execution, tool use, or resource consumption drifts beyond intended bounds.

1. Entry occurs when an agent receives a goal and begins operating through its harness, which may include tool access, subagent spawning, and code execution.
2. Escalation happens inside the loop when the harness makes repeated retries, parallel calls, or broader tool use than the task actually needs.
3. Impact appears as wasted quota, unstable behaviour, incorrect outputs, or unsafe execution decisions concentrated in the running control layer.

Breaches seen in the wild

• Ultralytics PyPI compromise 2024: A GitHub Actions injection and a leftover PyPI token let attackers publish four Ultralytics releases that installed a cryptominer.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Harness-level governance is now the real control problem for AI agents. The article shows that the decisive behaviour is no longer in the prompt or even the model, but in the runtime loop that decomposes work, retries failures, and manages execution. That means governance has to attach to the harness as an operating control point, not as a design-time afterthought. For AI teams, the practical conclusion is that agent oversight now starts with loop control.

Operational risk concentrates where the agent can act, not where it reasons. As soon as a harness can spawn subtasks, run code, or call tools, the security question becomes whether those actions are bounded, recorded, and reversible. That is a governance shift with direct implications for agent identity, delegated authority, and runtime authorisation. Practitioners should treat the harness as the place where privilege is expressed and constrained.

Context quality is becoming a named design concept, but it is also a governance dependency. The article's move away from heavyweight frameworks signals that agent systems are increasingly judged by how well they manage context, not just how well they compose steps. Context quality affects reliability, but it also affects what the agent can infer, retain, and act upon. The practitioner takeaway is that context handling is now part of control design, not just model tuning.

Observability is replacing intuition as the basis for agent assurance. When traces, retries, and tool-efficiency metrics become the primary evidence, the organisation can finally evaluate the loop instead of arguing over subjective agent quality. That is a stronger foundation for AI governance, but only if the telemetry is tied to decision rights and execution boundaries. Teams should measure the harness because the harness is where failure becomes operational.

AI agent identity will increasingly be defined by the harness that constrains it. The article points toward a future where the question is not only what model is running, but what runtime identity, permission layer, and execution context surround it. That is directly relevant to agentic AI governance and to NHI thinking, because agent authority is now expressed through machine-controlled runtime behaviour. Practitioners should align identity controls to the harness, not to the model alone.

What this signals

Context quality is becoming a governance control, not just a model-input concern: the more an agent depends on runtime context to decide what to do, the more security teams need to treat context integrity as part of the control plane. That is especially true for systems that can invoke tools or spawn subagents, because the harness determines both the action path and the failure path.

Agent systems are moving toward measurable runtime behaviour, which means programme owners should shift evaluation away from isolated prompt tests and toward traces, retries, and execution boundaries. The organisations that will govern this well are the ones that can explain not only whether an agent succeeded, but how it behaved while doing so.

For practitioners

• Instrument the agent control loop Track retries, tool calls, recovery paths, and task completion so you can see how the harness behaves rather than only judging the final answer.
• Bound execution with sandboxing Require every code-running or file-touching agent to operate inside an ephemeral sandbox with explicit task scope and narrow permissions.
• Define agent authorisation at runtime Map each tool, subagent, and file operation to a clear approval boundary so delegated actions stay inside intended authority.
• Use trajectory-based evaluation Score agent runs on trajectory quality, including retry patterns and tool efficiency, instead of relying only on outcome accuracy.

Key takeaways

• Agent harnesses are taking over the runtime decisions that used to be spread across agent frameworks, which makes the control loop the real governance layer.
• The security and reliability problem shifts from prompt quality to execution behaviour, including retries, sandboxing, tool use, and context management.
• Teams need trajectory-level observability and runtime authorisation if they want to govern AI agents with any confidence.

Key terms

• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• Trajectory Evaluation: Trajectory evaluation checks the sequence of decisions an agent makes from start to finish rather than only the final answer. It is used to confirm task decomposition, tool choice, state retention, and termination logic across multi-step workflows.
• Execution sandboxing: Execution sandboxing is the practice of constraining an agent’s command, file, and network permissions so tool use cannot produce broad system impact. For agentic systems, it is a boundary control that limits what happens when trust decisions go wrong.
• Model Hallucination: Model hallucination is when an LLM produces confident but incorrect, unsupported, or fabricated content. It is not a simple typo problem. In security and business settings, hallucination becomes dangerous when teams trust generated output without validation, especially in decisions involving data, compliance, or customer-facing advice.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners connect runtime control, delegated access, and identity governance across modern AI systems.