Open source AI agent harnesses and the governance gap in 2026

At a glance

What this is: This review compares leading open source AI agent harnesses and finds that only Mecatl bakes isolation, policy, and delegated identity into the architecture.

Why it matters: For IAM, NHI, and AI governance teams, the harness becomes part of the control plane because it decides how agent identities, tool access, and untrusted execution are separated.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Stacklok's review of leading open source AI agent harnesses

Context

An AI agent harness is the coordination layer between the model, the tool calls, and the execution environment. In practice, that makes it an identity and governance boundary, not just an orchestration detail. For agentic AI programmes, the question is whether the harness can constrain what the agent can see, call, and run without forcing teams to bolt on controls later.

That matters because open source harnesses can either preserve security boundaries or collapse them into a single trust domain. In regulated or Kubernetes-heavy environments, the architectural choice determines whether policy, identity, and audit are attached to the execution boundary or left to custom implementation. For teams already thinking in NHI terms, the harness is where delegated identity becomes governable or not.

Stacklok’s assessment treats the harness as the control point that decides how much trust an agent receives around tools and untrusted execution. That is the right lens for current enterprise deployments, especially where local development paths later promote into production clusters.

Key questions

Q: How should security teams govern agentic AI as it moves into production?

A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature. That means assigning ownership, scoping permissions tightly, logging every tool action, and revoking access on a defined lifecycle. Production rollout should require clear approval points for high-risk actions and continuous monitoring for drift.

Q: Why do open source agent harnesses create governance risk when identity is implicit?

A: Implicit identity makes it hard to prove which runtime actor used which tool and under what authority. That creates audit gaps, weak scoping, and unclear revocation paths when workflows move from development into production. The problem is not open source itself. The problem is the absence of explicit delegated identity and boundary enforcement.

Q: What is the difference between an agent harness and the model behind it?

A: The model generates decisions, but the harness governs how those decisions reach tools and execution environments. That distinction matters because identity, policy, and isolation belong in the harness layer. Without that separation, security teams end up trying to govern runtime behaviour inside the model, which is the wrong layer.

Q: Should teams choose Kubernetes-native harnesses before custom build-your-own frameworks?

A: If production is headed for Kubernetes, a native harness is often easier to govern because the runtime boundaries align with platform controls. Build-your-own frameworks can work, but they push more identity and policy design into integration work. Teams should choose the path that preserves auditability and isolation with the least custom trust glue.

Technical breakdown

Agent loop, tool calls, and execution boundaries

An AI agent harness sits between the model and the systems it touches. The harness usually coordinates three functions: the agent loop, which decides the next action; tool calls, which invoke external capabilities; and the execution environment, which runs code or commands. When those layers are fused into one trust domain, the agent can inherit broad access without a distinct governance point. When they are separated, security teams can apply policy, audit, and identity at the boundary rather than inside the model itself.

Practical implication: Treat the harness boundary as a control surface and require separate governance for action selection, tool invocation, and code execution.

Why Kubernetes-native agent harness design changes the risk model

A Kubernetes-native harness changes where trust is enforced. Instead of a local process handling everything, the harness can run agent logic, tools, and untrusted workloads in distinct containers or layers with isolation between them. That matters because Kubernetes already gives platform teams scheduling, namespace, and workload controls that can be aligned to agent behaviour. The architectural shift is not about making the model smarter. It is about making each step of agent execution observable and governable in the infrastructure where the workload actually runs.

Practical implication: Map agent runtime boundaries to Kubernetes isolation, namespace, and workload controls before production rollout.

Delegated identity and MCP security in agent orchestration

Delegated identity means the agent acts through a constrained identity rather than borrowing ambient access from a developer session. In agent harnesses that support MCP, the tools and data sources the agent can reach become part of a structured delegation chain. That is a material governance change because the harness can bind access, policy, and audit to the runtime identity rather than to the human who launched the session. For AI governance teams, that makes identity the mechanism that limits tool misuse, not a separate afterthought.

Practical implication: Bind agent tool access to delegated identity and review every MCP-connected capability as an identity dependency.

Threat narrative

Attacker objective: The objective is to expand agent influence from a bounded workflow into broader execution and tool access that bypasses intended governance boundaries.

1. Entry begins when an agent is granted access to tools or code execution through a harness that does not separate runtime trust domains.
2. Escalation occurs when the harness allows the agent loop to invoke untrusted execution or privileged tools without distinct policy and identity boundaries.
3. Impact follows when the agent can chain tool calls across untrusted environments, creating broad operational exposure that is hard to audit or contain.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Open source agent harnesses are now identity infrastructure, not developer convenience tools. Once the harness decides what an agent can see, call, and run, it becomes part of the trust boundary that IAM and NHI teams must govern. That means platform architecture and identity architecture are converging at the same control point. Practitioners should evaluate harnesses as runtime governance layers, not just as orchestration frameworks.

Architectural separation matters more than feature lists for agent security. A harness that separates the agent loop, tool calls, and untrusted execution gives security teams something to enforce and audit. A harness that collapses those layers forces policy to live in code, configuration, or manual review. The difference is not cosmetic. It determines whether delegated access is bounded by design or extended by default.

Delegated identity is the real dividing line between enterprise-ready and developer-only agent harnesses. The article’s strongest signal is that MCP support alone is not enough when the identity layer remains implicit. Agent governance becomes meaningful only when the runtime identity is explicit, scoped, and auditable. That is why the market is moving toward harnesses that treat identity and policy as first-class design elements.

The new control question is not whether an agent can use tools, but whether the harness can prove which identity exercised which tool at what boundary. This shifts governance from model-centric thinking to execution-centric thinking. For IAM and AI security programmes, that means auditability must follow the agent’s runtime path, not just the user who initiated it. Practitioners should judge every harness by whether it preserves that evidence chain.

Built-in isolation closes the gap that DIY frameworks leave open. Frameworks you assemble yourself can be flexible, but they move security responsibility into integration work. That is where identity scoping, boundary enforcement, and audit hooks are most likely to become inconsistent. Teams should expect to spend governance effort where the harness is not opinionated, because the operational burden does not disappear when the code is open source.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 44% of developers are reported to follow security best practices for secrets management, showing that process design alone does not close the behaviour gap.
• For the broader identity context, see Ultimate Guide to NHIs for lifecycle and governance patterns that apply when agent workflows expose credentials.

What this signals

Delegated identity is becoming the practical dividing line in agent governance. As organisations move from local experimentation to Kubernetes-backed deployments, the harness starts to function like a runtime trust broker. Teams that cannot trace tool use back to a scoped identity will struggle to make audit, offboarding, and containment decisions that hold up in production. For the broader identity context, the Ultimate Guide to NHIs remains the right reference point for lifecycle and delegated access.

Open source flexibility only helps when the execution boundary remains visible. The article’s core message is that architectural seams matter more than brand or language choice. That aligns with the broader governance lesson from agentic AI: policy has to live where action is taken, not just where code is written. The OWASP Top 10 for Agentic Applications 2026 is a useful external reference for teams formalising those boundaries.

Harness architecture will influence how quickly teams can move from proof-of-concept to controlled production. If the runtime cannot preserve identity and auditability across environments, the organisation will accumulate security debt every time a workflow is promoted. That is the real signal here: the control plane for agents is drifting closer to the workload layer, and identity teams need to decide whether they own that boundary or inherit the fallout.

For practitioners

• Classify the harness as a control boundary Map where the agent loop ends, where tool calls begin, and where untrusted execution runs. Treat each boundary as a distinct governance surface for identity, policy, and audit.
• Require explicit delegated identity for agent sessions Do not allow the harness to inherit ambient developer credentials for tool access. Bind runtime access to a scoped identity that can be reviewed, revoked, and audited independently.
• Test whether isolation survives promotion from laptop to cluster Run the same workflow locally and in Kubernetes, then verify that the policy and identity boundaries remain intact after deployment changes.
• Review MCP-connected tools as privileged dependencies Inventory every MCP-connected tool and data source as an identity dependency, then decide whether the harness can limit access to only what the agent needs for the task.

Key takeaways

• Open source agent harnesses are no longer just developer scaffolding because they now define the security boundary for agent identity, tools, and execution.
• The central practitioner question is whether the harness makes delegated identity, isolation, and auditability explicit enough for Kubernetes and regulated environments.
• Teams that build on harnesses without strong runtime seams will keep shifting identity risk into custom code and operational workarounds.

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.
• Execution boundary: The point at which an authorised task turns into a real system change, such as writing data, deleting records, spending money, or invoking a downstream tool. In AI governance, controlling the execution boundary matters more than simply approving access, because harm occurs when actions are allowed to complete unchecked.
• 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.

What's in the full article

Stacklok's full blog insight covers the operational detail this post intentionally leaves for the source:

• Comparative notes on Mecatl, OpenCode, Pi, and DIY frameworks for different deployment models
• How the harness handles local development, Kubernetes promotion, and headless operation in practice
• The specific way identity, policy, and audit hooks attach to the execution boundary
• Why the vendor argues that built-in separation matters for regulated and platform-managed environments

👉 Stacklok's full post covers the harness comparison, deployment model differences, and architectural details behind Mecatl's identity and policy seams.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.