They should review orchestration style, state persistence, recovery behaviour, observability, portability, and how governance will be enforced outside the framework. A good prototype can still be a poor production choice if it makes audit, control, or provider flexibility harder later.
Why This Matters for Security Teams
Choosing an agent framework is not just a developer preference. It shapes how an organisation governs autonomous behaviour, inspects decisions, constrains tool use, and recovers when an agent acts outside intent. The wrong choice can turn a manageable AI pilot into a system that is hard to audit, hard to contain, and expensive to replace later. That risk is now part of mainstream AI governance thinking in sources such as the NIST AI Risk Management Framework.
Security teams often overvalue feature breadth and undervalue control boundaries. A framework that makes orchestration easy may also hide state transitions, blur responsibility between application and model logic, or limit how well logs can support incident response. Current guidance suggests assessing the framework as part of the wider control environment, not as a stand-alone engineering decision. That means understanding where policy enforcement lives, how secrets are handled, and whether the framework can support evidence collection for review, testing, and assurance. In practice, many security teams encounter the limitations only after an agent has already been promoted into a business workflow, rather than through intentional design review.
How It Works in Practice
Most frameworks sit between the application, the model, tools, and the data sources the agent can reach. The practical question is how much of the agent lifecycle the framework controls versus how much is left to surrounding infrastructure. That includes task routing, memory, retries, tool calling, sandboxing, policy checks, and tracing. If governance is only partly supported inside the framework, organisations need compensating controls elsewhere, such as approval workflows, external policy engines, and security monitoring aligned to the NIST Cybersecurity Framework 2.0.
Before selection, teams usually evaluate a few practical areas:
- Orchestration style: single-agent, multi-agent, event-driven, or graph-based.
- State handling: whether memory is ephemeral, persistent, or externally stored.
- Recovery behaviour: what happens after timeouts, tool failure, partial completion, or model refusal.
- Observability: whether prompts, tool calls, state changes, and outputs are traceable for review.
- Portability: whether business logic can move across models or cloud providers without a redesign.
- Governance hooks: whether approvals, constraints, and redaction can be enforced outside the framework.
For threat modelling, the question is not only whether the framework is “secure”, but whether it creates blind spots for prompt injection, tool abuse, or unsafe autonomy. That is why many teams cross-check designs against the OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix, especially where agents can browse, call APIs, or trigger downstream actions. These controls tend to break down when a framework’s internal abstractions hide execution state and make external policy enforcement brittle across distributed, long-lived workflows.
Common Variations and Edge Cases
Tighter governance often increases engineering overhead, requiring organisations to balance speed of experimentation against auditability, portability, and operational control. That tradeoff is acceptable for prototypes in isolated environments, but best practice is evolving quickly for production systems that touch customer data, privileged actions, or regulated processes.
Some frameworks are optimised for rapid demos and assume the application will add security later. Others offer stronger lifecycle controls but can be harder to adapt if the team changes model providers, execution patterns, or tool ecosystems. There is no universal standard for this yet, so teams should judge whether the framework can sustain policy enforcement outside the agent runtime, not just inside it. That matters particularly when the agent will interact with secrets, approvals, or privileged workflows, where framework-level convenience can conflict with Zero Trust principles and least privilege expectations.
Where agentic systems support high-impact decisions, current guidance also points toward deeper governance mapping against OWASP Top 10 for Agentic Applications 2026, and where the system is part of a broader assurance programme, the NIST AI Risk Management Framework helps structure ownership, testing, and monitoring. Best practice is evolving, but the operational lesson is consistent: choose the framework that makes control enforcement visible, portable, and reviewable, not merely one that makes the first build faster.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | LLM02 | Agent frameworks must resist prompt injection and unsafe tool execution paths. |
| NIST AI RMF | GOVERN | Framework choice affects AI governance, accountability, and control ownership. |
| NIST CSF 2.0 | GV.OV-01 | Selection should support oversight, risk review, and measurable control assurance. |
| MITRE ATLAS | AML.TA0001 | Adversarial AI techniques help assess abuse paths in agent execution and tooling. |
| NIST AI 600-1 | GenAI systems need controls for logging, evaluation, and safe deployment patterns. |
Test agent workflows against agentic abuse cases before approving the framework for production use.
