AI agent frameworks need portable evals before production scale

At a glance

What this is: This analysis argues that framework selection for AI agents matters less than many teams assume, because production safety depends on portable evaluation that survives orchestration changes.

Why it matters: For IAM, NHI, and AI governance teams, the key issue is that agent frameworks create distinct runtime behaviour and trace patterns, so oversight, approval, and regression controls must sit above the orchestration layer.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Braintrust's analysis of the best AI agent frameworks and evals for 2026

Context

AI agent frameworks are orchestration layers that decide how an agent thinks, routes work, calls tools, and persists state. The governance problem is that each framework produces different traces, different failure modes, and different assumptions about control, which makes evaluation and oversight harder than selecting a framework from a feature matrix. For identity programmes, the relevant question is not simply which framework can run an agent, but how its runtime behaviour will be audited, constrained, and tied back to accountable access decisions.

That becomes more important as agent usage scales into systems that touch sensitive data, tools, and delegated privileges. When agents act as non-human identities in production, traceability, approval gates, and regression testing become part of identity governance rather than just engineering hygiene. Teams that treat orchestration as a purely developer choice usually discover the control gap later, when production behaviour no longer matches the assumptions used during design.

Key questions

Q: How should security teams govern AI agents that reason across multiple data platforms?

A: Security teams should govern the meaning layer, not just the access layer. That means defining shared business terms, lineage, and quality signals centrally, then making sure agents retrieve that context at runtime across every platform they touch. Without that control, the same agent can reach different conclusions from the same data.

Q: Why do local AI agents complicate identity and access management?

A: They can retain legitimate permissions while changing timing, prioritisation, and action sequence outside human presence. That means the visible identity may remain stable even as the operational behaviour becomes autonomous. IAM teams then lose the simple link between user session, authorisation, and accountability.

Q: What breaks when evaluation is tied to a single AI agent framework?

A: Portability breaks first, then consistency. If evals depend on one framework’s trace format, teams cannot compare behaviour across stacks, preserve regression history during migrations, or validate that a new orchestration model still meets the same acceptance criteria.

Q: Who should own AI agent risk when an agent can use business tools?

A: Ownership should sit across AI security, IAM, and the business team that granted the tool access. The model team owns safety testing, IAM owns entitlement scope, and the system owner owns the business impact. If one group owns only the model, the organisation misses the access-control risk.

Technical breakdown

Orchestration models create different control surfaces for AI agents

AI agent frameworks are not interchangeable because they encode different control flows. Graph-based systems such as LangGraph emphasise explicit state, branching, retries, and checkpointing. Role-based systems such as CrewAI emphasise collaboration across named agents. Linear handoff systems and retrieval-first systems optimise for different runtime patterns. That matters because the control surface determines what can be observed, replayed, paused, or constrained before the agent reaches a sensitive action. In practice, framework choice shapes whether governance can attach to a durable state machine, a task chain, or a retrieval pipeline.

Practical implication: Choose the framework only after mapping the workflow shape, approval points, and replay requirements the business process actually needs.

Trace structure is the real reason evaluation portability matters

Each framework emits different traces, spans, and state transitions, so a single fixed eval approach will miss important failure signals. A retrieval-heavy framework exposes chunk selection and synthesis behaviour. A graph framework exposes node transitions and state checkpoints. A handoff framework exposes task routing and guardrail decisions. If evaluation lives inside one framework, migrations or mixed stacks break the evidence chain. Portable evaluation converts production traces into reusable datasets and scorers, which is what lets teams compare behaviour consistently as the orchestration stack changes.

Practical implication: Standardise on an eval layer that ingests framework-specific traces and scores the same outcome criteria across all agent stacks.

MCP support expands tool reach and therefore governance scope

MCP, or Model Context Protocol, gives agents a standard way to connect to tools and data sources. That increases utility, but it also broadens the attack and oversight surface because more tools can be reached through a common interface. In agent systems, tool access is effectively delegated access, so the governance question becomes whether every connected tool is scoped, logged, and reviewed with the same rigour as human or service-account access. The more modular the tool layer becomes, the more important it is to bind tool calls to identity, policy, and audit evidence.

Practical implication: Treat MCP-connected tools as governed access paths and require logging, authorization, and review for every delegated action.

Threat narrative

Attacker objective: The attacker objective is to turn agent orchestration and delegated tool access into a controllable path for data exposure, misuse, or decision corruption.

1. Entry occurs when an AI agent is granted access to internal tools, documents, or APIs through its orchestration framework and connected context layer.
2. Escalation follows when the agent chains tool calls or retrieves data beyond the intended task boundary, creating a wider effective permission set than the workflow designer expected.
3. Impact appears when the agent outputs incorrect decisions, exposes sensitive data, or performs unauthorized actions at production speed.

NHI Mgmt Group analysis

Portable evaluation is now a governance requirement, not an engineering nice-to-have. When agent frameworks generate different traces, the organisation loses consistent evidence unless the eval layer sits above the orchestration stack. That means governance teams need a control plane for outcomes, not just a framework decision for development convenience. For identity programmes, this is the same lesson as centralising audit for distributed access paths.

Agent frameworks are creating a new form of control fragmentation. The deeper risk is not that teams choose the wrong framework, but that they end up with different observability, replay, and approval semantics in each stack. That fragmentation weakens the ability to compare behaviour across environments, business units, or model upgrades. The field needs shared evaluation criteria because distributed agent control without shared evidence becomes ungovernable at scale.

MCP-connected agents expand delegated access faster than most identity controls are being updated. A common tool protocol is useful, but it also broadens the number of tool endpoints an agent can reach and the number of places where policy must be enforced. The governance gap is not tool connectivity itself, but the assumption that tool access can be managed separately from identity lifecycle and audit. Practitioner conclusion: bind tool access to the same lifecycle discipline used for privileged human access.

AI governance debt is accumulating in the evaluation layer. Teams are moving quickly on framework choice while leaving trace portability, regression datasets, and failure scoring underdefined. That creates a backlog of unseen risk because the organisation can no longer prove that agent behaviour stayed within acceptable bounds after each release. Practitioners should treat eval design as part of model risk management, not as a post-launch quality step.

Retrieval-heavy agents and workflow-heavy agents need different assurance models. A document-centric system lives or dies on citation fidelity and retrieval relevance, while a stateful orchestration system lives or dies on checkpoint integrity and branching correctness. Collapsing those into one generic assurance checklist hides the real failure mode. Practitioner conclusion: align assurance to the dominant control pattern, not the marketing category.

What this signals

AI agent programmes are shifting from prototype risk to governance scale risk, which means teams need controls that survive framework churn rather than optimise for a single orchestration choice. A portable eval layer is becoming the practical equivalent of a shared control plane for agent behaviour, especially where tools, retrieval, and delegated actions cross team boundaries.

AI governance debt: the backlog created when teams deploy agent capability faster than they build traceability, review, and regression controls. In identity terms, that debt appears when agent actions are visible only inside the application that created them, not inside the governance systems that own the risk. Readers should expect this debt to show up first in auditability and then in incident response readiness.

For practitioners

• Define the orchestration pattern before picking a framework Map whether the agent needs branching, retries, human approval gates, multi-agent task passing, or retrieval-heavy reasoning. Then select the framework that matches that workflow shape instead of forcing a favourite stack into an unsuitable control model.
• Build a framework-agnostic evaluation layer Capture framework-specific traces into a shared evaluation pipeline so retrieval quality, tool-call correctness, routing accuracy, and final output quality can be scored consistently across stacks.
• Tie agent tool access to identity governance Treat every connected tool, API, and data source as delegated access. Require authorisation, logging, and periodic review for MCP-connected tools, especially where the agent can reach regulated or sensitive systems.
• Turn production failures into regression datasets When an agent misroutes a task, retrieves the wrong evidence, or calls a tool incorrectly, preserve that trace as a test case before the next release. Use those cases to block repeated failures before users see them.

Key takeaways

• Choosing an AI agent framework solves orchestration fit, but it does not solve governance or evaluation consistency.
• Trace portability is becoming a control requirement because framework-specific telemetry fragments oversight as agent stacks diversify.
• Identity teams should treat agent tool access, evaluation, and regression testing as part of delegated access governance, not as separate engineering concerns.

Key terms

• AI Agent Runtime: The execution environment where an AI agent runs and takes actions. It is the practical trust boundary because it determines what the agent can reach, which identity evidence it can present, and which controls can be enforced around access and execution.
• Portable Evaluation: Portable evaluation is a scoring and testing approach that stays consistent even when the underlying orchestration framework changes. It relies on shared traces, datasets, and scorers so teams can compare agent behaviour across stacks, migrations, and model upgrades without losing evidence.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.

What's in the full article

Braintrust's full article covers the implementation detail this post intentionally leaves for the source:

• Framework-by-framework comparison of trace structures and integration patterns
• Code examples for capturing spans from LangGraph, CrewAI, OpenAI Agents SDK, Mastra, and LlamaIndex
• Practical eval scoring ideas for retrieval quality, handoff routing, and tool-call accuracy
• Migration guidance for teams running mixed agent stacks in production

👉 The full Braintrust article covers framework trade-offs, trace examples, and evaluation patterns 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 secrets management. It helps security practitioners connect delegated access, auditability, and lifecycle control across human and non-human identity programmes.