TL;DR: A 2026 survey from researchers at Carnegie Mellon, Yale, Amazon and others maps agent reliability into ETCLOVG, a seven-layer harness taxonomy that separates execution, tooling, context, lifecycle, observability, verification and governance across more than 170 open-source projects, according to TruFoundry. The practical message is that agent risk is now a system-design problem, and control of identity, state, telemetry and policy matters more than prompt quality alone.
At a glance
What this is: TruFoundry explains ETCLOVG as a seven-layer taxonomy for agent harnesses that separates execution, tooling, context, lifecycle, observability, verification and governance around the model.
Why it matters: IAM, NHI and AI security teams should care because the article frames agent reliability as a runtime governance problem where identity, policy, telemetry and approval paths determine blast radius.
Context
ETCLOVG is a way to describe the control surface around an AI agent, not the model itself. The article argues that production failures usually come from the harness, where execution, tools, context, lifecycle and governance interact. For identity and security teams, that means the relevant question is not only what the model can do, but who or what is allowed to run it, steer it, observe it and stop it.
The taxonomy is especially useful because it separates the structural runtime from the control plane. E, T, C and L make an agent operate, while O, V and G make that operation visible, testable and safe. In NHI terms, this is the same shift seen in machine identity governance: the core risk is not just capability, but the way permissions, state and telemetry are orchestrated across the workflow.
Key questions
Q: What breaks when AI agent execution is not isolated from the harness?
A: Untrusted tool calls and generated code can affect the harness itself instead of being contained within a separate execution boundary. That undermines blast-radius control, makes failure modes harder to contain, and increases the chance that one agent workflow disrupts other workloads. Isolation has to exist at runtime, not only in policy documents.
Q: Why do AI agent reliability problems keep turning into governance problems?
A: Because reliability in production depends on who can act, what they can reach and how those actions are approved. Once agents can persist state, call tools and span multiple steps, the question becomes authority management, not just output quality. That is why harness design and identity control converge.
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: When should agent permissions be treated as identity governance rather than a feature setting?
A: As soon as the AI system can call tools, reach data, or trigger actions on behalf of a user or service. At that point, its permissions behave like non-human identity access and need scope, lifecycle, review, and revocation controls. Otherwise the agent becomes a standing access path with weak accountability.
Technical breakdown
Why harness engineering matters more than prompt quality
Prompt engineering treats the model input as the main variable, but agent reliability depends on the system wrapped around the model. ETCLOVG captures that shift by showing how execution environments, tool protocols, context windows and lifecycle loops create the actual operating conditions for the agent. Once tasks span multiple steps or touch external systems, the harness becomes the control boundary that shapes failure modes, side effects and recoverability. That is why post-incident analysis often lands on runtime design rather than prompt wording.
Practical implication: Treat prompt work as one layer in a larger control stack, and assess harness design before you judge agent reliability.
Execution, tooling and context define the agent's blast radius
Execution controls where code or actions run, tooling controls how capabilities are discovered and invoked, and context controls what the model can see across a task. In practice, these three layers determine whether an agent can act safely inside a bounded workspace or drift into uncontrolled side effects. The article's mapping of MCP, sandboxes and long-horizon context shows that reliability and safety are linked to the runtime substrate, not only the model output. If these layers are loose, retries, tool calls and context growth can amplify mistakes quickly.
Practical implication: Bind execution, tool access and context handling to explicit policy so a single agent action cannot expand into an uncontrolled chain.
Observability, verification and governance are separate control planes
ETCLOVG is strongest when it treats observability, verification and governance as distinct layers rather than vague quality functions. Observability records what happened, verification judges whether it was correct, and governance decides what should be allowed in the first place. That separation matters because traces do not equal evaluation, and evaluation does not equal policy enforcement. The article also shows why these layers often live in different teams or products: they answer different operational questions and need different evidence.
Practical implication: Keep traces, evaluation logic and policy enforcement distinct so one control failure does not masquerade as another.
Threat narrative
Attacker objective: To use agent runtime permissions and workflow coupling to produce harmful actions, data exposure or uncontrolled system behavior under legitimate-looking execution paths.
- Entry occurs when an agent is given access to tools, context or execution environments that extend beyond the model itself.
- Credential or authority is then exercised through the harness, where runtime permissions and state determine what the agent can actually touch.
- Impact appears when a mis-scoped harness lets the agent make destructive, persistent or unaudited actions that the model alone could not have taken.
Breaches seen in the wild
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
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
ETCLOVG is best understood as a governance taxonomy for AI runtime identity, not just a reliability framework. The article shows that the important control question is who or what can act inside the harness, with what permissions, and under which approvals. That places agent identity, state and policy in the same design conversation as execution and tooling. For practitioners, the lesson is to govern the runtime actor, not only the model output.
Execution and tooling are where agent risk becomes operational. Once agents can invoke tools or run inside sandboxes, the problem shifts from text generation to authority use. This is why blast radius is a runtime property, not a prompt property, and why tool interfaces deserve the same scrutiny as any privileged control path. For practitioners, the actionable move is to treat tool discovery, session scope and execution boundaries as enforceable controls.
Observability without verification is telemetry, not assurance. The article rightly separates traces from evaluation and evaluation from governance, because a log of agent activity does not tell you whether the outcome was safe or correct. That distinction matters in production, where teams often confuse visibility with control. For practitioners, the implication is clear: instrument the harness, but do not mistake instrumentation for decision authority.
Harness engineering is becoming the equivalent of identity architecture for AI systems. The more agents operate across tasks, tools and sessions, the more their permissions and state resemble machine identities with delegated authority. That makes policy, approval and revocation part of the core design, not downstream administration. For practitioners, the field is moving toward runtime governance models that should be owned jointly by platform, security and identity teams.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Harness governance is becoming the missing control plane for enterprise AI. As agents move from demos to production workflows, the governing issue is no longer whether the model can answer correctly but whether the surrounding runtime can bound, observe and revoke its authority. That is a familiar identity-security pattern, but applied to software actors that now behave like privileged workloads.
ETCLOVG makes the control gap easier to see. Execution, tooling and context expose what an agent can do, while lifecycle, observability, verification and governance determine whether the organisation can explain, approve and constrain that behaviour. For security teams, the practical signal is to move from prompt-centric review to runtime policy review.
AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026. That reinforces the article's core message: the surrounding harness is often where the real exposure lives, so telemetry, secrets control and policy enforcement need to sit at the runtime boundary.
For practitioners
- Define the harness boundary for every production agent Document which layers are owned by the model, the runtime, the tool gateway and the policy engine so incident reviews can map failures to the correct control surface.
- Separate tracing from evaluation and governance Keep telemetry pipelines, evaluator logic and permission enforcement independent so a good trace does not get mistaken for a safe or correct outcome.
- Bind tool access to explicit session scope Require every external tool to carry session-scoped authority, with the tool registry, approval path and execution context tied together.
- Treat execution environments as blast-radius controls Use isolated sandboxes or equivalent runtime boundaries for code execution, browser use and file operations, then revoke the workspace at task end.
- Review agent permissions as identity controls Inventory which agents can read, write, call tools or trigger approvals, and align those permissions to role-based policy rather than ad hoc application logic.
Key takeaways
- ETCLOVG reframes agent reliability as a harness problem, where execution, tooling, context and lifecycle shape what the model can actually do.
- The article draws a hard line between observability, verification and governance, which is where many AI programmes currently blur control with visibility.
- For practitioners, the governing question is whether the agent runtime has explicit authority boundaries, because that is where reliability and risk are now decided.
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 addresses the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on agent authority, tool use and runtime privilege boundaries. |
| ASI02 — Tool Misuse | Tool interfaces and session-bound tool use are core to the taxonomy. | |
| ASI08 — Cascading Failures | The article highlights cross-layer coupling where one change can break multiple layers. | |
| Recommendation — Map agent permissions and approval paths to ASI03 and restrict tool access to scoped runtime authority. Control tool discovery, selection and invocation so agents cannot misuse external capabilities outside policy. Design harness controls to limit cross-layer failure propagation across execution, context and governance. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance of AI runtime behavior and accountability. |
| Recommendation — Establish governance ownership for agent runtime policy, approvals and accountability across the lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Agent permissions and scoped authority are central to the article's control model. |
| Recommendation — Apply entitlement controls to agent runtime access so tools, sandboxes and actions remain explicitly authorized. | ||
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.
- Execution Layer: The execution layer is the operational point where identity policy becomes system change. It is where approvals, provisioning, revocation, and session controls either complete successfully or fail in ways that create drift. For practitioners, this is where governance is proven, not merely documented.
- Governance intelligence layer: A governance intelligence layer is an independent observability capability placed above existing identity tools to correlate accounts, roles, access paths, and policy violations. It does not replace core IAM or IGA systems. Its purpose is to improve visibility, simulate change, and accelerate governance decisions.
- Verification Layer: A verification layer is the control stage that inspects code before it is promoted to production. It looks for defects, secrets, dependency issues, and maintainability problems so that release decisions are based on evidence rather than developer confidence alone.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and platform teams translate runtime control problems into identity and access decisions.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org