AI agent frameworks are exposing new governance gaps in 2026

At a glance

What this is: This guide compares five AI agent frameworks and shows that the real selection problem is governance, observability, and control over multi-step agent execution.

Why it matters: It matters to IAM, PAM, and AI security teams because agent frameworks create new identity, permission, and audit boundaries that conventional application controls do not fully cover.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Braintrust's analysis of the best AI agent tools to use in 2026

Context

AI agent frameworks are becoming the control plane for software that can plan, call tools, carry state, and continue across multiple steps. That makes the security question less about whether a model can respond and more about how the surrounding execution loop is governed, especially where the agent touches company data, APIs, or privileged workflows.

For IAM and NHI programmes, the boundary matters because agents are increasingly acting like non-human identities with delegated access, persistent state, and auditable actions. The article is really about framework selection under production constraints, and that starting position is typical for teams that have already moved from prototype to operational deployment.

The governance gap is already visible in broader AI adoption: teams are deploying agents faster than they are defining policy, visibility, and review. Braintrust's role in the article is tracing and evaluation, but the underlying issue is whether security teams can observe and constrain agent behaviour before it becomes a standing operational dependency.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What breaks when teams cannot trace what an AI agent did?

A: Governance breaks first, because teams lose the evidence needed to decide whether the issue was behavior, identity, or control. Without replayable logs of prompts, tool use, data access, and escalation, incident response becomes speculation and accountability becomes weak. For autonomous systems, traceability is the control that makes every other control defensible.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

State, memory, and retries: where agent risk actually lives

AI agents are not single prompts. They are execution loops that manage planning, tool calls, state, memory, retries, and completion across multiple turns. That architecture creates persistent context and repeated decision points, which is useful for task completion but also expands the attack surface. A malformed tool response, unsafe memory write, or bad retry policy can change later behaviour in ways that are hard to detect from the final output alone. Durable execution and checkpointing improve resilience, but they also make it more important to understand which state is stored, who can modify it, and how long it persists.

Practical implication: Treat state persistence and memory writes as governed assets, not implementation details.

Framework style changes the control model, not just the developer experience

Graph-based systems, role-based multi-agent systems, lightweight SDKs, and TypeScript-native workflows each impose different levels of control over orchestration. A graph runtime makes execution explicit, which helps when branching, approval, or resumption matters. A role-based crew model simplifies task delegation but can hide how privilege and responsibility move between agents. Lightweight SDKs reduce orchestration overhead, yet push more responsibility into application code. The practical security issue is that framework choice determines where policies live: in orchestration, in code, or in external controls such as tracing, guardrails, and approval gates.

Practical implication: Map each framework to a clear policy enforcement point before production use.

Agent tracing is the minimum viable control for auditability

Tracing is not just an engineering convenience. For agents that can call APIs, hand off work, and continue after interruption, trace data becomes the evidence trail for what was attempted, what was executed, and where a control failed. Without it, security teams cannot reconstruct tool misuse, unsafe delegation, or boundary violations with confidence. Observability also supports evaluation, which is critical because agent quality problems and security failures often look similar at runtime. The gap is especially serious when agents interact with credentials, secrets, or sensitive data, because the investigation question becomes who approved the action and whether the agent stayed within scope.

Practical implication: Require end-to-end tracing and evaluation before allowing agents to touch sensitive systems.

Threat narrative

Attacker objective: The attacker objective is to exploit agentic execution paths to obtain data, credentials, or downstream system access through trusted automation.

1. Entry begins when an agent is given access to tools, APIs, or data sources without tight scoping or explicit approval boundaries.
2. Escalation occurs when the agent can chain actions across multiple steps, reuse context, or delegate work in ways that expand effective privilege.
3. Impact follows when the agent reaches unauthorized systems, exposes sensitive data, or reveals credentials during an apparently legitimate workflow.

NHI Mgmt Group analysis

AI agent frameworks are becoming identity infrastructure by another name. Once an agent can hold state, call tools, and act across multiple steps, it behaves like a governed non-human identity rather than a simple application component. That means access scope, auditability, and lifecycle control matter as much as orchestration elegance. The security lesson is that teams must treat agent frameworks as part of IAM and PAM design, not only as developer tooling.

Tracing and evaluation are now governance controls, not optional diagnostics. The article places observability beside framework selection, which is the right framing for production use. Without traceability, teams cannot evidence what an agent accessed, which tool it used, or whether it stayed within policy. In identity terms, that is the difference between accountable delegation and blind trust.

Agent sprawl creates a new form of governance debt. The market is filling with frameworks that make it easier to build agents, but easier construction usually accelerates unmanaged deployment. That pattern mirrors early secrets sprawl, where convenience outpaced lifecycle discipline. The named concept here is agent governance debt: the accumulation of unmanaged permissions, state, and execution paths that future controls must unwind. Practitioners should assume this debt will compound unless ownership and policy are defined up front.

Role-based coordination does not remove privilege risk, it redistributes it. Crew-style systems can separate research, writing, and review, but each role still needs a clear permission boundary and a revocation path. The issue is not just what an agent can do, but what it can delegate or inherit from other agents. For identity teams, that means role design must be aligned to least privilege, approval, and offboarding discipline.

Type safety reduces application errors, but it does not solve authorisation risk. Pydantic-style validation and structured outputs can prevent malformed data from reaching downstream services, yet they do not prevent an agent from making an inappropriate request in the first place. This is a useful distinction for security architects: schema control is not access control. The practitioner implication is to pair output validation with policy enforcement at the tool and data layers.

What this signals

Agent governance debt: the longer teams leave agent permissions, tracing, and memory controls implicit, the harder it becomes to retrofit trustworthy oversight. In practice, that means the security programme will need a repeatable way to inventory agent identities, map their tool access, and prove revocation works when workflows change. The control objective is no longer just safe deployment, but safe persistence.

The next maturity step is to align agent governance with existing identity processes such as access review, privileged access, and secrets management. That is where the article intersects most clearly with IAM and NHI programmes, especially when agents operate alongside service accounts or delegated API tokens. Teams that already govern non-human identities will adapt faster than teams that still treat agents as mere application code.

For practitioners

• Define agent permission boundaries before framework selection Document which tools, datasets, and APIs each agent may access, and require explicit approval for any action that crosses those boundaries. Apply the same discipline to handoffs and delegated steps so privilege does not expand silently across an execution chain.
• Treat agent memory as governed state Classify persistent memory, checkpoints, and session data as security-relevant assets. Decide what can be stored, how long it can persist, and who can read or modify it, especially when the agent handles sensitive workflows or privileged context.
• Require end-to-end tracing before production release Make trace capture mandatory for tool calls, model turns, handoffs, retries, and human approvals. Use those traces to test failure paths, support investigations, and prove that the agent stayed within approved scope.
• Separate validation from authorisation Use typed outputs and schema checks to reduce runtime errors, but enforce access policy at the tool layer. Validation should stop bad data, while authorisation should stop the wrong action, even if the request is technically well formed.
• Build a revocation path for every agent identity Define how to suspend an agent, rotate its credentials, and disable its access when behaviour changes or a workflow is retired. Agent lifecycles need offboarding and incident containment steps just like human and service identities.

Key takeaways

• AI agent frameworks are not just orchestration choices. They define how identity, privilege, memory, and auditability are handled in production.
• The strongest warning signal in the source is the gap between rapid agent adoption and weak governance, which leaves organisations exposed to rogue behaviour and poor visibility.
• Security teams should pair framework selection with explicit permission boundaries, tracing, and lifecycle controls before agents are allowed into sensitive workflows.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Agent Orchestration: Agent orchestration is the coordination of multiple AI agents or workflows to complete a task set with limited human intervention. In identity terms, it creates delegated execution paths that need ownership, scope limits, and auditability because work is no longer performed only by a person in one session.
• Agent Memory: Agent memory is the stored context an AI agent uses across sessions or tasks. In governance terms, it is controlled state, because the memories an agent retains can influence future actions, permissions use, and the safety of subsequent decisions.
• Identity Handoff: The controlled transfer of access from one user to the next on a shared device or application session. In manufacturing, the handoff must close the prior session, preserve auditability, and prevent residual access from carrying into the next operator’s activity.

What's in the full article

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

• Language-by-language framework selection guidance for Python, TypeScript, and .NET teams
• Implementation trade-offs for graph-based orchestration versus role-based coordination
• Tracing, evaluation, and release-control mechanics across each framework
• Operational differences between durable state, handoffs, and multi-agent workflows

👉 Braintrust's full guide covers framework trade-offs, tracing patterns, and production evaluation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management in the context of real operational controls. It is designed for practitioners who need to connect identity discipline to the broader security programme.