Behavior specs for long-horizon agents expose the supervision gap

At a glance

What this is: This is a Braintrust analysis of behavior specs, an open standard for supervising long-horizon AI agents by evaluating the process across a trajectory, not just the final outcome.

Why it matters: It matters to IAM and AI security teams because long-running agents create governance gaps around decision scope, evidence quality, and controlled tool use that outcome-only checks will miss.

👉 Read Braintrust's blog on behavior specs for supervising long-horizon agents

Context

Long-horizon agents create a governance problem that looks familiar to identity teams: access and actions unfold over time, but approval is often judged only at the end. In this case, the gap is not authentication but supervision. If an agent can take hundreds of steps, use tools, and make intermediate judgments, final-result checks alone cannot prove that the work stayed inside policy or used the right evidence.

Braintrust's discussion is especially relevant to AI governance because it treats agent behaviour as something that can be specified, tested, and audited like a control. That makes behaviour specs analogous to identity and privilege standards in mature IAM programmes: the goal is not only to see whether the task succeeded, but whether the route taken was acceptable. The starting position described here is increasingly typical for teams shipping long-horizon agents.

For practitioners looking to anchor this in established guidance, the governance pattern aligns with the NIST AI Risk Management Framework and with the OWASP Agentic AI Top 10, especially where tool use, prompt injection, and agent goal drift create security and assurance risk.

Key questions

Q: How should teams govern long-horizon AI agents without over-relying on outcome checks?

A: Teams should evaluate both the result and the path the agent took to reach it. That means defining expected behaviour, testing trajectories with standing evals, and reviewing evidence such as tool calls, source grounding, recovery steps, and decision sequences. Outcome checks remain useful, but they are not enough for agents that make many intermediate decisions.

Q: Why do long-horizon agents create governance risk for IAM teams?

A: Because the agent behaves like a runtime subject with access to tools and data, but its policy memory can decay over time. IAM teams cannot assume a prompt will reliably preserve access boundaries, approval rules, or data restrictions across a long task. That turns lifecycle control into an enforcement problem.

Q: What do security teams get wrong about evaluator design for agents?

A: They often treat evaluators as fixed infrastructure instead of versioned instruments that can drift. If evaluator scores do not correlate with real user outcomes, the programme is optimising for the wrong signal and may miss slow degradation, false confidence, or miscalibrated quality thresholds.

Q: How do organisations know if agent security controls are actually working?

A: Look for evidence that the platform can inspect traces, classify risky actions, and stop unsafe tool use before completion. Effective controls leave an audit trail that shows why the action was allowed or denied, and they reduce false positives enough that teams can trust them in production.

Technical breakdown

Why outcome evals miss trajectory risk in long-horizon agents

Outcome evals answer whether the final output was acceptable, but they do not reveal how the agent got there. For long-horizon work, the meaningful unit of assurance is the trajectory: the sequence of tool calls, intermediate judgments, recoveries, and evidence checks that led to the result. A correct answer can still be produced through weak grounding, poor source selection, or unsafe tool use. That is why process supervision matters. It turns hidden execution choices into observable governance evidence and reduces overfitting to a narrow eval set.

Practical implication: evaluate both the result and the path, or you will certify behaviours you never actually intended.

What a behavior spec changes in agent governance

A behavior spec is a structured description of expected agent conduct in a specific situation. It defines intent, evidence, decision, execution, recovery, and failure modes so a human judge can compare an observed trajectory with the standard. In practice, this is closer to policy-as-evidence than prompt engineering. The important shift is that the spec is not telling the model what to think in the moment. It is defining the measurable control objective that the runtime should satisfy, even when the model, tools, or prompts change over time.

Practical implication: write specs for recurring high-risk behaviours, not for every prompt, and treat them as controls that can be tested continuously.

Why standing evals matter for autonomous decision loops

Standing evals turn a one-off review into an ongoing governance mechanism. Once a behavior spec exists, teams can replay trajectories, assign a verdict, and detect whether a runtime change introduced drift. That is important because long-horizon agents are not static systems. Tooling, model versions, context windows, and policies all change the behaviour surface. In identity terms, the risk is comparable to privilege creep: a control that was adequate at release may no longer bound actual runtime behaviour after a few iterations or integrations.

Practical implication: bind every critical agent workflow to a repeatable eval loop so policy drift becomes visible before production use expands.

NHI Mgmt Group analysis

Behavior specs are the right abstraction for governing long-horizon agent risk. The article correctly shifts the control question from outcome accuracy to process assurance. That matters because long-running agents can take hundreds of steps, and each step can expand risk even when the final output looks acceptable. In governance terms, behavior specs create a testable standard for agent conduct that is closer to policy enforcement than prompt advice. For practitioners, the lesson is to govern trajectories, not just outputs.

Long-horizon agent control is becoming an identity problem as much as a model problem. Once an agent can choose tools, timing, and intermediate actions, it starts behaving like a software identity with delegated authority. That creates a genuine bridge into NHI governance, because the central question becomes how much standing authority the agent should retain between decisions. The discipline here is analogous to least privilege and JIT thinking, but applied to runtime behaviour rather than human sessions. Practitioners should treat agent authority as a governed identity surface.

Process supervision creates the missing control plane for AI governance. Outcome metrics are useful, but they are too coarse for high-variance trajectories where the correctness of the path matters. Behavior specs, judge prompts, and standing evals form a control plane that can detect drift, unsafe shortcuts, and weak evidence handling. This aligns with NIST AI RMF GOVERN and MEASURE functions and with the OWASP Agentic AI Top 10 emphasis on tool misuse and agent goal drift. Practitioners should build measurement into the operating model, not bolt it on after incidents.

Spec-driven governance will become a standard for teams that want to scale agent trust. The article's sparse-file approach is important because it avoids turning policy into a bloated document nobody can maintain. That is a practical insight for security and compliance leaders: keep the number of required behaviours small, make them measurable, and retire controls once the model reliably exhibits them. For practitioners, the implication is clear. Durable agent governance will look like a maintained control library, not a static prompt repository.

What this signals

Long-horizon agents should be treated as a governed execution surface, not a one-time prompt problem. The practical signal for IAM and AI security teams is that approval, evidence, and runtime behaviour now need the same kind of discipline historically applied to privileged access. The closer an agent gets to tool use and autonomous sequencing, the more it resembles a software identity with delegated authority.

Trajectory supervision: the next control boundary for agent governance is not the model output but the sequence of decisions, tool calls, and recoveries that produce it. That boundary will matter most where agents operate with access to sensitive data or privileged systems. Teams that build evaluable behaviour standards now will be better positioned to absorb future agent scale without losing control.

For programmes already investing in AI governance, the immediate next step is to map critical agent workflows to measurable standards and link those standards to review cycles. The question is no longer whether agents can answer correctly. It is whether they can be trusted to behave within policy when the task is long, ambiguous, and operationally consequential.

For practitioners

• Define trajectory-based controls for critical agent workflows Identify the few agent behaviours that carry the most risk, then write explicit specs for intent, evidence, execution, recovery, and failure modes so they can be judged consistently.
• Bind agent evaluations to standing review cycles Create repeatable evals that replay real trajectories after model, prompt, or tool changes, and require a pass before expanding production scope.
• Treat tool-using agents as governed software identities Limit standing authority, constrain tool access to the minimum required for each task, and review whether the agent retains privileges longer than the workflow needs.
• Separate outcome scoring from process assurance Keep final-answer checks, but add evidence checks that examine whether the agent used primary sources, correct tools, and approved decision paths.

Key takeaways

• Long-horizon agents need trajectory supervision because outcome-only evaluation cannot prove safe or policy-compliant behaviour.
• Behavior specs make agent conduct measurable by defining intent, evidence, decision, execution, recovery, and failure modes.
• Security and IAM teams should treat tool-using agents as governed identities and attach standing evals before production scale increases.

Key terms

• Behavior Spec: A behavior spec is a written standard that defines how an AI agent should act across a task, not just what result it should produce. It describes intent, evidence, decision points, execution steps, recovery, and failure modes so the behaviour can be judged consistently from a trajectory.
• Runtime Supervision: Continuous observation of what an identity or agent actually does while it is operating. For NHI governance, runtime supervision helps detect scope creep, unusual tool chaining, and behaviour that is technically permitted but operationally unsafe.
• Standing Eval: A standing eval is a repeatable test that remains active after deployment and is rerun whenever the system changes. In agent governance, it helps teams detect drift in model behaviour, prompt behaviour, or tool usage before the changes expand into production risk.
• Trajectory: A trajectory is the full sequence of actions, tool calls, intermediate decisions, and recoveries an agent takes to complete a task. It is the right unit of analysis for long-horizon agents because the final output alone does not reveal whether the work followed an acceptable path.

What's in the full article

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

• The exact behavior spec structure used to define intent, evidence, decision, execution, recovery, and failure modes
• The judgeable verdict model for production trajectories, including true, false, and NA outcomes
• The open-source workflow for writing and testing behavior specs on your own traces
• The collaboration details between Braintrust and Basis on agentbehavior.dev

👉 The full Braintrust post covers the spec format, judge model, and open-source workflow in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It helps practitioners build the control thinking needed for modern identity and access programmes.