Agent harnesses are replacing frameworks in AI systems

At a glance

What this is: This analysis says the center of gravity in agent engineering has moved from frameworks to harnesses that run the control loop and shape reliability.

Why it matters: That matters because identity, permissioning, and execution controls now sit inside the runtime loop, which changes how IAM, NHI, and AI security teams govern agent behaviour.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Arize's analysis of why agent harnesses are replacing frameworks

Context

Agent harnesses change how AI systems are operated because they own the control loop rather than just the orchestration library. For identity and security teams, that matters when the loop can retry actions, isolate execution, manage context, and report outcomes without human intervention, because governance has to follow runtime behaviour as well as code.

This is where the identity and NHI angle becomes explicit. When an agent harness decides what tools to call, what credentials to use, and how to recover from failure, it becomes a privileged control point for non-human identity and agentic AI governance. That makes loop-level telemetry, permission boundaries, and execution sandboxes part of the security model, not just engineering preference.

The shift is not typical framework adoption. It is a structural move toward agents that arrive as running systems, which means practitioners need to treat harness behaviour as a first-class security and assurance surface.

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 create new non-human identity risks?

A: Because the harness decides how credentials are used, what tools are called, and how failures are retried. That means a single session can accumulate privilege, expand its blast radius, or perform unintended actions before anyone reviews the outcome. The risk is not the model alone, but the runtime authority wrapped around it.

Q: What signals show that a harness is operating outside safe boundaries?

A: Watch for repeated retries, unexpected parallel subagents, unusual tool calls, failed recovery loops, and session costs that rise faster than task complexity. Those patterns show the harness is compensating for weak control logic or overbroad permissions. In production, trajectory anomalies are often the earliest sign of governance failure.

Q: How do organisations decide whether a harness is safer than a framework?

A: Judge it by containment and evidence, not by architecture labels. A safe harness limits session authority, keeps execution isolated, and produces traces detailed enough to explain every action. If the system cannot show who or what used a credential and why, the governance model is incomplete regardless of how the agent was built.

Technical breakdown

Why agent harnesses change the control plane

A framework gives developers building blocks for prompts, tools, memory, and workflow composition. A harness is different: it is the running control plane that decides task decomposition, retries, context compression, tool selection, and execution order at runtime. That shift matters because the agent’s behaviour is no longer a static flow written by humans. It becomes an adaptive loop whose operational quality depends on how the harness manages state, permissions, and recovery. In practice, the harness is where policy meets execution, which is why failures now show up as orchestration defects rather than model errors.

Practical implication: security teams should review harness design as part of access and execution governance, not treat it as a pure application-layer implementation detail.

Why observability now belongs in the harness loop

When a harness runs the agent, the important signals are trajectory-based: retries, tool calls, recovery from errors, and where the loop diverged from the intended path. Traditional output-only evaluation misses these behaviours because it only scores the final answer. Harness observability captures the path taken, which is essential for understanding why an agent used a credential, invoked a tool, or spiralled into wasteful execution. That makes traces, spans, and session artifacts more valuable than isolated prompts or responses. In identity terms, the control story is about how the loop exercised privilege, not just whether it eventually succeeded.

Practical implication: instrument agent traces and privilege-use events together so identity reviewers can reconstruct what the harness actually did.

Why sandboxed execution becomes a security boundary

Harnesses increasingly run code, manage files, and call tools inside ephemeral sandboxes. That design reduces persistence, but it also creates a new security boundary where credentials, file access, and external calls must be constrained per session. A sandbox is only useful if the harness enforces isolation consistently and logs what happened inside it. Otherwise, ephemeral execution can still become a route for data exfiltration, misuse of tokens, or unreviewed tool chaining. For NHI governance, the key point is that the runtime environment is now part of the identity boundary, because the agent’s access is defined as much by the harness as by the token it holds.

Practical implication: require per-session sandbox policy, short-lived credentials, and auditable tool boundaries for every production agent.

Threat narrative

Attacker objective: The objective is to abuse the agent runtime to obtain unauthorized access, execute unintended actions, or extend the blast radius of a compromised non-human identity.

1. Entry occurs when an AI agent or workflow is allowed to run inside a harness that can call tools, manage files, and retry actions without close supervision.
2. Escalation happens when the harness has access to broader credentials or can spawn parallel subagents, expanding the blast radius of a single session.
3. Impact follows when the loop performs unintended tool use, wastes quota, exposes data, or executes actions that exceed the operator’s intended scope.

NHI Mgmt Group analysis

Harnesses are becoming the real identity control surface for AI systems. Once an agent loop decides what to do, retries, and which tools to invoke, the harness becomes the place where privilege is exercised. That changes the governance question from model quality to runtime authority. The practitioner conclusion is straightforward: if the loop can act, the loop needs identity controls.

Loop-level observability is now a security requirement, not an engineering luxury. A harness can only be governed if the organization can reconstruct tool calls, retries, and recovery paths after the fact. This is where agent telemetry intersects with NHI oversight, because the security team needs to know not only what the agent returned, but what access it consumed along the way. The practitioner conclusion is to treat traces as evidence.

Ephemeral execution does not eliminate risk if credentials remain broad. Sandboxed harnesses reduce persistence, but they do not fix overbroad access, reusable tokens, or weak session boundaries. The named concept here is runtime privilege compression: reducing a session’s authority to the minimum needed for that exact task. That is the governance model AI operators now need to adopt.

The framework era was about composition; the harness era is about containment. Frameworks helped developers stitch together workflows, but harnesses decide how much damage a session can do when something goes wrong. That shifts market demand toward controls for execution policy, sandboxing, and per-session authorization. The practitioner conclusion is to evaluate whether current governance assumes static workflows when the system is now dynamic.

Agent security is converging with NHI governance. Once a harness assigns credentials, selects tools, and manages its own context, the agent behaves like a non-human identity with delegated authority. That means identity lifecycle, secret scope, and access review all need to account for runtime decision-making. The practitioner conclusion is to align AI operations with NHI governance rather than treat them as separate programmes.

What this signals

Runtime governance is becoming the differentiator for AI security programmes. As harnesses absorb more of the control loop, organisations need to shift from model-centric checks to session-centric control design. That means tying execution policy, sandboxing, and credential scope together in one operating model, with guidance from the OWASP Top 10 for Agentic Applications 2026.

Runtime privilege compression: the practical goal is to reduce every agent session to the minimum access needed for that exact task, then revoke it as soon as the task ends. This is especially important when the harness can spawn subagents or perform recovery actions, because broad standing access turns a minor orchestration fault into a wider identity event.

Secret handling and traceability will become inseparable. If a harness can call tools, it can also expose tokens, API keys, or backend credentials unless those secrets are bounded by session and monitored as part of the trace. Teams should prepare for more joint reviews between AI engineering and IAM, especially where ephemeral execution meets privileged data access.

For practitioners

• Instrument the harness, not just the prompt Track retries, tool calls, context compression, and recovery paths so every agent session can be reconstructed as an execution trace.
• Constrain session authority by design Issue short-lived credentials, scoped tool permissions, and per-session sandbox rules so a harness cannot expand privilege beyond the task.
• Review agent traces as identity evidence Join harness telemetry with identity logs so reviewers can see which non-human identity used which credential, when, and for what action.
• Measure trajectory quality, not only final output Use success rate, recovery time, tool efficiency, and hallucinated tool calls to determine whether the harness is safe enough for production.

Key takeaways

• Agent harnesses move the security problem from prompt quality to runtime authority.
• When the loop controls retries, tools, and context, identity governance has to follow the execution path.
• Production AI programmes need traceability, sandboxing, and short-lived credentials before they scale further.

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.
• Runtime Privilege Compression: The practice of reducing an agent session’s authority to the smallest possible scope for the duration of a single task. It limits the blast radius of AI systems by ensuring credentials, tool access, and execution rights expire or narrow as soon as the session no longer needs them.
• 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.

What's in the full article

Arize's full analysis covers the operational detail this post intentionally leaves for the source:

• Specific harness patterns for decomposition, retries, and context compression across coding agents
• Detailed discussion of observability metrics such as tool hallucination, bash recovery, and cost per successful trajectory
• Examples of harness-level evaluation and telemetry from agent platforms and production traces
• The operational rationale behind sandboxed execution and loop-level instrumentation

👉 The full Arize post covers harness behavior, observability, and the production implications of loop-level control.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to govern non-human access as AI systems become operational.