Harness engineering is redefining how LLM systems are built

At a glance

What this is: Drata argues that harness engineering is the third major shift in LLM application design, moving the control surface from prompts and context into the runtime that governs tools, policy, memory, and observability.

Why it matters: This matters because agent governance now depends on identity, authorisation, and audit-grade control of what an AI system can do, not just the quality of its outputs.

Context

Harness engineering is the shift from shaping model output to governing the runtime that surrounds the model. In practice, that means the important questions are now about tool access, policy enforcement, state handling, observability, and recovery when something fails. For identity and security teams, the change is material because the runtime becomes the control point for agent identity, delegated authority, and evidentiary traceability.

The article frames this as an evolution of LLM building rather than a replacement for prompt or context engineering. That matters because the new layer does not remove earlier work; it absorbs it and adds operational controls that look much more like distributed systems governance. In AI and GRC settings, the harness becomes the place where human identity, non-human identity, and audit requirements meet.

Key questions

Q: How should teams govern agent actions when an LLM can call tools in production?

A: Teams should treat the harness as the control plane for agent action. That means explicit delegation scope, tenant boundary enforcement, pre-action authorization, and durable audit records. If the agent can invoke production systems, governance has to constrain what it may do before execution, not after output appears.

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: How do security teams know if agent harness controls are actually working?

A: Look for two signals: untrusted repository configuration being blocked before execution, and a clean correlation between allowed hooks and the processes they launch. If tools only detect suspicious behaviour after a process starts, then you have telemetry, not control. Effective governance stops the conversion from repository state to execution.

Q: What is the difference between context engineering and harness engineering?

A: Context engineering curates what information the model sees, while harness engineering governs what the system can do with that information. Context is about the input environment; the harness is about runtime authority, state, observability, and recovery. The distinction matters because governance failures usually occur in execution, not in prompt wording.

Technical breakdown

What is an agent harness in LLM systems?

An agent harness is the runtime environment around the model. It decides which tools an LLM can call, how context is assembled, where memory lives, how policies are enforced, how runs are traced, and how failures are retried. The model performs reasoning, but the harness determines the action boundary, the state boundary, and the evidence boundary. That makes the harness closer to an operating system than a prompt template, because it governs execution rather than just generation.

Practical implication: Treat the harness as the control plane for agent behaviour, not as a thin wrapper around prompts.

Why policy, memory, and observability become runtime controls

The article shows that the hard problems in agent systems are old distributed-systems problems: concurrency, state, policy, resource accounting, observability, and failure recovery. Memory is not just retrieval, policy is not just output filtering, and observability is not just logging. Each has to operate at runtime because the agent is making decisions while it runs, often across multiple tools and services. In regulated use cases, policy is better understood as an authorization gate before action, not a post-hoc review step.

Practical implication: Move controls to the decision point, where access, state, and evidence can still shape the action.

How does agentic AI change identity and authorization design?

Harness design makes identity a first-class engineering issue because an agent may act for a human, inside a tenant boundary, and across multiple services. That creates a need to distinguish which agent is acting, on whose behalf, and under what scope. Traditional OAuth-style delegation helps with one slice of that problem, but the article argues that agent-to-agent chains, action-level policy, and audit-grade attestation require a deeper identity model. This is where agent governance intersects directly with NHI control, because the runtime effectively becomes a machine identity broker.

Practical implication: Define agent identity, delegation scope, and tenant boundaries explicitly before an agent can invoke production tools.

Threat narrative

Attacker objective: The objective is to obtain or misuse delegated runtime authority so actions can occur with machine speed and poor attribution.

1. Entry occurs when an AI system is allowed to operate inside a production harness that can call tools, assemble context, and move state between services.
2. Credential access and privilege use happen when the agent is permitted to act on behalf of a human or tenant through delegated scopes and tool permissions.
3. Impact appears when poor policy, weak observability, or missing reversibility lets the agent take actions that cannot be reconstructed, attributed, or safely rolled back.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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 engineering is really a governance shift disguised as an architecture trend. The article is right to move attention away from prompts and toward the runtime, because the runtime is where authority, evidence, and recovery are enforced. Once agents can call tools and carry state, the question stops being output quality and becomes controlled execution. For identity teams, that means the agent harness is now part of the access model, not just the application layer.

Policy has to move from content review to authorization logic. The article’s strongest point is that regulated environments need policy as a gate before action, not a filter after generation. That aligns with how IAM and PAM already treat privileged operations: decide first, then execute, then record. In agent systems, the gap is that many teams still rely on post-hoc review for something that should be pre-authorised.

Auditability is becoming a primary product requirement, not a compliance add-on. The piece is explicit that an auditor needs reconstruction of what the agent did, on whose behalf, and under which policy version. That is an identity and evidence problem, not just logging. The named concept here is audit fabric: a durable evidentiary layer that preserves decision attribution, policy state, and action lineage for external review. Practitioners should design for traceability before production rollout.

Agent identity is now a three-part problem: actor, delegate, and tenant. The article correctly separates which agent is acting, on behalf of which human, and within which boundary. That distinction matters because machine identities do not fit neatly into human IAM patterns, especially when multiple tools and services are involved. The practical implication is that agent runtime design must encode those boundaries explicitly or governance will collapse into assumptions.

The next bottleneck is not model capability but operational composition. The article is strongest when it treats harness engineering as the place where concurrency, state, observability, and failure recovery become unavoidable. That is why NHI, authorization, and audit controls are no longer adjacent to agent design. They are the substrate that determines whether an agent is a demo, a workflow, or a governed system.

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 engineering pushes agent governance into the same territory that IAM and PAM already manage for humans and privileged services: who can act, under what scope, and how the action is evidenced. That means security teams should stop thinking about the model as the primary control point and start treating the runtime as the unit of governance.

Audit fabric: the article’s most useful concept is the idea that an agent needs a durable evidentiary layer, not just logs. For regulated environments, that shifts implementation priorities toward decision attribution, policy versioning, and reconstructable action lineage.

Agent systems will expose control gaps that many organisations have already accepted in service-account governance. If an agent can act faster than a human reviewer can certify, then standing access, unclear delegation, and weak rollback become operational liabilities rather than theoretical risks.

For practitioners

• Define agent identity and delegation boundaries Model which agent is acting, which human it represents, and which tenant owns the context before any production tool access is enabled.
• Treat policy as a pre-action gate Move policy checks to the point of authorization so the agent cannot execute sensitive actions unless the current scope, exception state, and control version all permit it.
• Make audit fabric a design requirement Capture policy version, evidence source, tool calls, and decision attribution in a durable record that can support external review months later.
• Separate retrieval from true memory Distinguish working, episodic, semantic, and procedural memory from simple context retrieval so the runtime does not confuse stored content with governed state.
• Build reversibility into every tool Require each exposed action to state how it is compensated, rolled back, or escalated when the system later proves it made the wrong decision.

Key takeaways

• Harness engineering moves the security question from model quality to runtime control, where policy, memory, tools, and observability determine what an agent can safely do.
• The article’s central governance insight is that production AI now depends on identity, delegation, and evidence as first-class design primitives.
• Teams building agent systems should assume that auditability and reversibility will matter as much as capability, especially when regulated workflows are involved.

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.
• Audit Fabric: A durable evidentiary layer that preserves the full chain of an agent’s decisions, actions, policy state, and supporting evidence. It is designed for later reconstruction by auditors or investigators, and it carries stronger guarantees than ordinary application logging.
• Delegated Agent Identity: An identity used by one actor to act on behalf of another under explicit scope and policy. In agentic environments, this can describe both human-authorised assistants and machine-to-machine handoffs, so the delegation path must remain auditable at every step.
• Policy As Gate: Policy as gate means authorization is checked before an agent acts, not after it generates an output. The control evaluates identity, scope, tenant context, exception state, and action type before execution. That is a stronger security posture than post-hoc filtering because it can prevent risky tool calls from ever starting.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It is designed for practitioners who need to govern machine identities, delegated access, and audit-ready controls.