Harness engineering is redefining how LLM systems are built

At a glance

What this is: This analysis argues that the centre of gravity in building with LLMs has moved from prompts to context and now to the agent harness, where runtime controls determine what the model can see, do, and prove later.

Why it matters: For IAM, PAM, and NHI programmes, the shift matters because agent harnesses turn authorization, identity boundaries, and audit evidence into first-class security controls rather than downstream implementation details.

👉 Read Drata's analysis of harness engineering and agent runtime design

Context

Harness engineering is the emerging practice of governing the runtime around an LLM or agent, not the model alone. The article frames this as the third major shift in three years, moving from prompt engineering to context engineering and now to the control layer that handles tools, memory, policy, tracing, and recovery. For identity teams, the important point is that agent behaviour is no longer just a model-quality issue; it is a runtime governance problem with a real identity and authorization surface.

That matters because the same categories that underpin IAM and NHI governance show up inside the harness: who or what is acting, what it is allowed to access, which policy version applies, and whether the resulting actions can be reconstructed for audit. In regulated environments, this is not an abstract architecture trend. It is the place where agent identity, delegated access, and evidentiary controls converge, and that convergence is still immature in most organisations.

Key questions

Q: How should security teams govern agent actions inside a harnessed runtime?

A: Security teams should treat the harness as the enforcement point for authorization, state, and audit. The right pattern is to bind the agent, the sponsoring human, and the tenant context before execution, then require policy checks before any tool call or data access. That gives teams a governable boundary instead of relying on model behaviour alone.

Q: Why do agent harnesses create new IAM and PAM requirements?

A: Agent harnesses create new IAM and PAM requirements because they turn delegated action into a runtime decision. The system must know which agent is acting, on whose behalf, under which tenant boundary, and with what scope. Traditional user-centric controls do not fully capture that chain of responsibility, so privilege decisions need to move closer to execution.

Q: What do security teams get wrong about memory in agent systems?

A: Security teams often treat memory as if a vector store were enough. In practice, memory includes working state, durable state, and policy-relevant context, each with different access, retention, and audit needs. If those are collapsed into one mechanism, the system becomes hard to govern, hard to troubleshoot, and hard to prove after the fact.

Q: How can organisations make agent decisions auditable for compliance?

A: Organisations need an evidentiary record, not just operational logs. That means capturing who or what acted, the policy version in effect, the evidence used, the tool calls made, and the resulting decision. When that information is tied together, auditors can reconstruct the action chain without relying on informal explanations later.

Technical breakdown

What an agent harness actually controls

An agent harness is the runtime wrapper around an LLM or agent. It controls tool access, context assembly, memory, policy enforcement, retries, state handling, tracing, and output handling. The model generates candidates, but the harness decides which inputs are present, which actions are permitted, and how failures are recovered. That distinction matters because most production risk sits outside the model weights. It sits in orchestration, permissions, and state transitions. In practice, the harness becomes the operating environment in which identity, data access, and action approval are enforced or bypassed.

Practical implication: Treat the harness as a governed runtime and subject it to the same access and audit expectations as other privileged control planes.

Why policy has to behave like authorization

The article correctly separates policy as a gate from policy as a filter. In many agent systems, policy is applied after an output is generated, which is too late for regulated or high-risk actions. A safer design treats policy as pre-action authorization, checking whether the agent may call a tool, on behalf of which tenant or human, under which control set, and with which exception state. That moves policy closer to IAM and PAM logic than content moderation. It also means policy must be dynamic, because the relevant state can change between one action and the next.

Practical implication: Design agent policy checks as pre-execution authorization decisions, not post-generation content filters.

Why memory, state, and auditability are the hard problems

The article distinguishes retrieval from memory and points out that most systems still confuse the two. Real memory is not a vector store alone. It is a managed set of working, episodic, semantic, and procedural state with lifecycle rules. The same is true for auditability: application logs show that something happened, but an evidentiary record shows who acted, under what policy version, with what supporting evidence, and why the action was taken. That is the level required when agents operate across regulated workflows or shared tenancy boundaries.

Practical implication: Separate retrieval, state, and evidence into different governed services so audit reconstruction remains possible.

NHI Mgmt Group analysis

Harness engineering is really a privilege governance problem in disguise. The article shows that the interesting decisions are no longer about prompt quality, but about what the runtime allows an agent to do. That is an IAM and PAM problem at the boundary of model, tool, and tenant. Once the harness decides tool access and action scope, it becomes the practical enforcement point for least privilege, exception handling, and delegated authority. The practitioner conclusion is straightforward: if the harness is ungoverned, the agent is ungoverned.

Agent identity now needs to be treated as a first-class control plane concept. The article’s three-way identity framing, the agent, the human on whose behalf it acts, and the tenant boundary, is the right model for production systems. That is especially relevant where autonomous or semi-autonomous action crosses data, workflow, or approval boundaries. Existing IAM patterns can support pieces of this, but they do not fully solve runtime attribution and delegated action chains. Practitioners should expect agent identity to become part of access governance, not a separate AI concern.

Audit fabric will become the evidence layer that separates toy agents from operational ones. The article is right to distinguish logs from evidentiary records. Compliance, forensics, and supervisory review need chain-of-custody, policy-version traceability, and decision attribution, not just observability dashboards. That makes audit design a security architecture decision, not a back-office reporting feature. The practitioner conclusion is that agent systems must be built to answer who acted, under which policy, and with what evidence from day one.

Policy-as-gate is the named concept this market needs. The article exposes a common failure mode: treating policy as a content check after the model has already decided what to do. In harnessed systems, that is too late for high-risk or regulated actions. Policy has to sit in front of execution and block unauthorised tool calls before they happen. That shift aligns agent governance more closely with authorization architecture than with prompt safety. Practitioners should design for pre-action control, not post-output review.

The next bottleneck is not model capability, it is control composition. The article makes a persuasive case that orchestration, state, observability, and recovery are now the limiting factors. That is a familiar pattern in identity security: once the core identity engine matures, governance fails at the seams between systems. The same is happening here. The practitioner conclusion is that agent programmes will succeed only if they can compose controls across identity, policy, data, and workflow without losing attribution or reversibility.

What this signals

Policy-as-gate is the operational idea that will matter most to identity teams as agent runtimes mature. The more an agent can plan, chain actions, and call tools, the less useful after-the-fact review becomes. Governance has to move upstream into the moment before execution, with identity, scope, and exception state checked in real time.

Agent programmes will also force a cleaner separation between retrieval, state, and evidence. That separation is already familiar in mature identity governance, where entitlements, approvals, and audit trails are different objects for a reason. The same design discipline now needs to apply to AI runtimes if teams want attribution that survives an audit or incident review.

For practitioners

• Define agent identity binding rules Bind every agent run to three runtime fields: the agent instance, the sponsoring human or workflow, and the tenant boundary. Use those fields consistently in authorization decisions, logs, and audit records so delegated action can be attributed later.
• Move policy checks before execution Require pre-action authorization for tool use, data access, and external calls. Post-generation filtering is useful for safety review, but it does not stop unauthorized actions from starting.
• Separate retrieval from governed state Do not rely on a vector store as a substitute for memory. Split retrieved context, durable state, and evidentiary records into distinct services with lifecycle rules and explicit access controls.
• Design an evidentiary audit fabric Capture policy version, input context, tool calls, approvals, and resulting actions in a reconstructable evidence trail. Treat the record as something an auditor can replay, not just something an engineer can search.
• Map harness controls to identity governance Review where existing IAM, PAM, and tenant controls already cover agent actions, and where new runtime guardrails are needed for delegated execution, recovery, and exception handling.

Key takeaways

• The article shows that the real control surface in LLM systems has shifted from prompt quality to the agent runtime.
• Identity, authorization, and evidence are becoming core design constraints for agent governance, not secondary implementation details.
• Teams that cannot bind agent action to policy and audit evidence will struggle to govern production use at scale.

Key terms

• Agent Harness: The agent harness is the runtime environment around an LLM or AI agent. It determines which tools the agent can use, how context is assembled, how policy is enforced, how state is preserved, and how actions are traced for review. In practice, it is the control layer that turns model output into governed execution.
• 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.
• Evidentiary Record: An evidentiary record is a trace built for accountability, not just troubleshooting. It captures who or what acted, which policy version applied, what evidence supported the action, and what the resulting decision was. Unlike ordinary logs, it is designed to withstand audit, dispute, and incident reconstruction.
• Agent Identity Binding: Agent identity binding is the practice of tying an agent run to the acting agent, the sponsoring human or workflow, and the tenant boundary. It makes delegated action attributable and reduces ambiguity when systems need to decide whether a request is authorised. Without it, access review and incident analysis become unreliable.

What's in the full article

Drata's full article covers the operational detail this post intentionally leaves for the source:

• How the harness layers map to actual implementation choices across orchestration, policy, memory, and observability.
• The specific examples and references behind the eight-layer harness model discussed in the article.
• The GRC-native design patterns Drata uses to think about evidence, authorization, and reversibility in agent workflows.

👉 Drata's full article expands the harness model, the GRC-specific design choices, and the unresolved engineering gaps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern access control. It is designed for practitioners who need to bring identity discipline to emerging runtime and delegation models.