TL;DR: Open source AI agent harnesses now determine whether agent loops, tool calls, and execution happen inside a governable boundary or a DIY trust gap, according to Stacklok’s review of Mecatl, OpenCode, Pi, and custom frameworks. The real decision is whether your AI agent stack can enforce identity, policy, and isolation architecturally rather than as an afterthought.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Stacklok's blog post: Leading open source AI agent harnesses are compared, and only one, Mecatl, bakes in isolation, policy, identity, and auditing as architectural seams rather than add-ons.
Why it matters: IAM, PAM, and security teams need to treat the harness as part of the control plane, because agent governance fails when execution, tools, and identity are managed in one undifferentiated runtime.
Context
An AI agent harness is the coordination layer that sits between the model and the tools or execution environment it uses. In practice, that layer decides what the agent can see, what it can call, and where untrusted work runs, which makes it a governance boundary rather than a simple runtime wrapper.
For organisations running agents on Kubernetes or in regulated environments, the harness architecture is as important as the model itself. The article frames a familiar IAM problem in a new form: if identity, policy, and isolation are bolted on after the fact, the environment inherits the same trust gap that NHI programmes already struggle to control.
The article’s central claim is that open source options differ less by feature checklist than by how much governance they expose to platform teams. That is typical of the current market, where developer convenience, enterprise deployment, and security boundary design do not line up cleanly.
Key questions
Q: What breaks when an AI agent harness does not separate planning from execution?
A: The trust boundary collapses. When the same runtime plans actions, selects tools, and executes untrusted work, identity checks and policy enforcement become hard to prove and harder to audit. The result is governance by convention rather than by architecture, which leaves security teams unable to show where authorised behaviour ends and unsafe behaviour begins.
Q: Why do delegated identity and tool boundaries matter for AI agent governance?
A: Because agents do not just consume data, they initiate actions through tools. If tool access is not tied to delegated identity and explicit scope, the agent can inherit broad permissions that are difficult to constrain after the fact. That turns access control into a runtime guess instead of a governable decision.
Q: How do security teams know whether an open source agent harness is actually governable?
A: Look for explicit seams between the agent loop, tool access, and untrusted execution. A governable harness makes those layers separable, inspectable, and auditable. If the design requires the team to reconstruct isolation and policy controls manually, governance is still aspirational rather than operational.
Q: How should teams compare agent frameworks and harnesses?
A: Compare them as different layers. Frameworks orchestrate what the agent should do, while harnesses enforce where and how it may execute. If the article’s distinction holds, governance decisions should start with the harness layer because that is where isolation, attribution, and policy enforcement either happen or fail.
Technical breakdown
Agent loop, tool calls, and execution boundaries
An agent harness is not the model. It is the software layer that coordinates the agent loop, routes tool calls, and decides where execution occurs. The security significance is that the harness defines the trust boundary. If the loop, tools, and execution all live in one process or one trust domain, policy becomes advisory rather than enforceable. A harness that separates those functions can attach controls at the seam between them, which is where identity checks, audit logging, and policy enforcement become meaningful instead of cosmetic.
Practical implication: treat harness design as part of access control architecture, not just developer tooling.
Delegated identity and MCP security in agent harnesses
The article’s strongest governance signal is that delegated identity and MCP security are now first-class concerns in agent infrastructure. MCP connects models to tools and data sources, so the harness must govern which tools are reachable, under what identity, and with what scope. Without that layer, the agent can inherit broad, poorly separated access to the surrounding environment. For AI coding agents and autonomous workflows, that is an identity problem, not just an integration problem, because the trust decision sits at the boundary between the agent and the toolchain.
Practical implication: require explicit identity boundaries for tool access before expanding agent reach into production systems.
Isolation seams for untrusted execution
The key architectural distinction in the article is whether untrusted execution happens inside the same runtime as the agent or in a separate isolated layer. Separation matters because tool output, code execution, and environment access are not equally trustworthy. An isolated layer lets platform teams sandbox risky actions, instrument behaviour, and audit what happened without rewriting the agent. In contrast, a build-your-own stack can reach production only if the team recreates those seams manually, which is why many frameworks remain prototypes until governance is engineered in.
Practical implication: validate where untrusted execution lands and insist on a separate enforcement layer before production rollout.
Threat narrative
Attacker objective: The objective is to make agent-driven execution cross trust boundaries in a way that bypasses identity, policy, and audit controls.
- Entry occurs when an agent is allowed to interact with tools, code, or external data through a harness that does not enforce a clear trust boundary.
- Escalation happens when the same runtime that plans the action also executes untrusted work, letting tool outputs and environment access blend into one control plane.
- Impact follows when the harness cannot prove which actions were authorised, isolated, or audited, leaving governance teams with little evidence to contain misuse or replay the session.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
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
Open source AI agent harnesses are becoming the governance layer that decides whether agent behaviour is controllable at all. Once the harness mediates tool access, execution, and policy, it effectively becomes part of the identity plane. That shifts the security question from model quality to boundary design, which is where platform and IAM teams must focus their attention.
Delegated identity is now a structural requirement for agent governance, not an advanced feature. The article shows that some harnesses still treat identity as an add-on, but that approach breaks down when agents can call tools, switch contexts, and execute untrusted actions. Practitioners should read that as a market signal: agent security is moving toward governance at the harness boundary, not within the model.
Open source frameworks that require teams to build their own loop, tool registry, and execution layer leave the hardest security problems unowned. That is not a tooling preference issue, it is a governance gap. If a team must assemble isolation, audit, and policy from scratch, then the real product decision is whether the organisation is prepared to operate an agent control plane, not just run an agent.
Agent harness architecture is now where NHI governance and agentic AI governance converge. The same control patterns that matter for workload identity, privilege scope, and environment isolation now apply to agent execution paths. Security leaders should treat harness selection as a programme decision about who can authorise, observe, and constrain machine-driven actions.
Open source does not mean low governance; it means governance must be visible in the architecture. That is the enduring lesson here. Teams that cannot point to clear seams between agent intent, tool invocation, and untrusted execution are still operating with a trust gap, even if the stack is self-hosted.
From our research library:
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
- Read next: Agentic AI Identity Guide
What this signals
Identity governance for agents now starts in the harness. The article makes clear that the practical control point is not the model, but the layer that decides which tools an agent can reach and which execution contexts it can enter. Teams that cannot describe those seams precisely are not ready to scale agentic workflows safely.
Open source harnesses expose a familiar NHI lesson: when security is treated as an integration task, control boundaries become inconsistent across environments. The difference between a laptop workflow and a Kubernetes workflow should be a deployment detail, not a change in trust model.
Agentic AI governance and NHI governance are converging on the same operational question: who can authorise machine actions, and where is that authorisation enforced? Once the answer is only “inside the runtime,” the programme is relying on behaviour rather than control.
For practitioners
- Define the harness as a governance boundary Map the agent loop, tool registry, and execution environment as separate control points so identity, policy, and audit can attach to each layer.
- Require delegated identity for tool use Do not allow agents to reach production tools unless each invocation is tied to a specific delegated identity and an explicit access scope.
- Separate untrusted execution from orchestration Place code execution, sandboxing, and environment access in a layer that is distinct from the planning loop and can be independently audited.
- Test whether build-your-own stacks can reach production Review custom frameworks for the exact controls they must recreate, including isolation seams, policy enforcement, and evidence capture.
- Align agent rollout to Kubernetes governance If agents will run on Kubernetes or local infrastructure, verify that the same backend does not collapse development and production trust assumptions.
Key takeaways
- Open source AI agent harnesses are now governance infrastructure, because they define where identity, policy, and untrusted execution are separated or blurred.
- The article’s main distinction is architectural, not cosmetic: only one option described here builds isolation, delegated identity, and audit seams in by design.
- Teams should judge harnesses by whether they can enforce control at the boundary between planning, tool use, and execution, not by whether the stack is self-hosted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Agent harnesses determine whether tools can be misused through unsafe orchestration and weak boundaries. |
| ASI03 — Identity & Privilege Abuse | The article centres on delegated identity and whether agents can inherit or exceed intended privilege. | |
| Recommendation — Separate tool invocation from agent planning so tool misuse can be constrained and audited. Bind agent actions to delegated identity and explicit privilege scope at the harness boundary. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Delegated identity and harness boundaries fail when agent authentication is not explicit and enforceable. |
| NHI-05 — Overprivileged NHI | Agent harnesses can silently concentrate privilege if tool access is not separated from orchestration. | |
| Recommendation — Enforce explicit authentication paths for agent-to-tool access rather than implicit runtime trust. Limit each agent to the minimum tool and environment permissions needed for the task. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principles — Never trust, always verify | The harness is a trust boundary that should verify each tool call and execution context. |
| Recommendation — Apply zero trust principles at the agent boundary and verify each tool request independently. | ||
Key terms
- AI Agent Harness: The control layer that surrounds a model and makes it operational in a real environment. It manages context, memory, tool use, and action gating, so the system can behave safely within policy and access constraints rather than acting on model output alone.
- Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
- Untrusted Code Execution: Untrusted code execution happens when a pipeline runs code or build logic that an attacker can influence. In practice, this usually means contributor input, modified workflow files, or imported steps that are not sufficiently constrained. It is a common path to secret exposure, artifact tampering, and broader supply chain compromise.
- MCP Security: MCP security is the set of controls that protect Model Context Protocol connections between agents, tools, and data sources. It covers connector permissions, secret handling, and policy enforcement because the protocol can become a direct path from agent intent to enterprise action.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 16, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org