Framework Security Comparison
AI Agent Framework Security Comparison: OpenAI Agents SDK vs LangGraph vs Strands
OpenAI Agents SDK, LangGraph, and Strands each provide different native controls: guardrails and tracing in OpenAI Agents SDK, explicit graph control and checkpointing in LangGraph, and model-driven MCP tool integration in Strands. None of them include a built-in enterprise identity, role-based access control, or least-privilege authorization layer. Security teams evaluating these frameworks must plan to add agent identity, tool-call authorization, and compliance-grade audit logging externally, regardless of which framework they select.
Security-Relevant Capabilities by Framework
Each framework ships with a distinct set of native, security-relevant mechanisms. None of these are enforcement systems on their own; they are the building blocks each vendor provides for developers to construct governance around.
| Framework | Native capability highlights |
|---|---|
| OpenAI Agents SDK | Configurable guardrails on inputs and outputs, native tracing of runs and tool calls, and handoffs that delegate tasks to agents scoped to their own instructions and tools |
| LangGraph | Explicit graph-based control flow, checkpointers that persist graph state at each step, and human-in-the-loop interrupts that can pause execution before a designated node |
| Strands | A model-driven reasoning loop governed by declared tool specifications, with Model Context Protocol (MCP) support for integrating external tools |
How the Three Frameworks Approach Agent Security
OpenAI Agents SDK, LangGraph, and Strands solve the same problem, orchestrating agent reasoning and tool use, with structurally different designs. OpenAI Agents SDK provides a Guardrails feature that runs configurable validation checks on inputs and outputs, built-in tracing that records agent runs and tool calls for inspection, and Handoffs that let one agent delegate a task to another agent scoped to its own instructions and tool set. LangGraph takes a more explicit approach, modeling workflows as graphs of nodes and edges rather than an implicit agent loop. This gives developers direct control over state transitions, persistence through checkpointers that save graph state at each step, and human-in-the-loop interrupts that can pause execution before a designated node, such as a tool call, pending manual approval. Strands, AWS's open-source agent SDK, is model-driven: agent behavior is primarily governed by the model's own reasoning loop combined with declared tool specifications, and it supports the Model Context Protocol (MCP) as its mechanism for integrating external tools. None of these architectures were designed around a centralized enterprise identity or access control model; each optimizes for developer control flow and observability rather than governance.
What Is Native Versus What Enterprises Must Build
Each framework's native features reduce boilerplate but stop short of enforcement. OpenAI Agents SDK guardrails must be explicitly configured per agent; an agent with no guardrail configuration has no automatic restriction on inputs or outputs. LangGraph's interrupt capability is a building block for approval gates, not a default behavior, so whether a high-risk tool call actually pauses for review depends entirely on how the graph is designed. Strands' model-driven loop reduces the amount of explicit control-flow code required, but it places correspondingly more trust in the underlying model's tool-selection behavior compared to LangGraph's explicit graph model. In all three cases, the framework provides the mechanism (tracing, interrupts, or handoffs), while the enterprise implementation team is responsible for the policy: what gets blocked, what requires approval, and what gets logged for later review.
Common Governance Gaps Across All Three Frameworks
Three gaps appear consistently regardless of which framework is selected. First, none of the three frameworks' documentation describes a built-in enterprise identity, authentication, or role-based access control system for agents or tools; this responsibility falls to the surrounding application, IAM system, or API gateway. Second, least-privilege tool access is not enforced by framework configuration alone. A tool function exposed to an agent in any of the three frameworks is technically callable unless the surrounding code, secrets scoping, or IAM role restricts it, meaning least privilege must be enforced externally in every case. Third, audit trails are framework-native but not compliance-ready by default. OpenAI Agents SDK tracing, LangSmith for LangGraph, and Strands' SDK logs each capture execution detail in a different format, and consolidating them into a single, retention-controlled audit trail for regulatory or incident review requires additional integration work.
Frequently Asked Questions
Does any of these frameworks enforce least privilege by default?
No. OpenAI Agents SDK, LangGraph, and Strands all leave least-privilege enforcement to the surrounding application, IAM configuration, or API gateway. Framework configuration alone does not restrict what an agent can technically call; teams must scope credentials and tool access independently of the framework.
Which framework provides the strongest built-in audit trail?
OpenAI Agents SDK includes native tracing for runs, tool calls, and handoffs. LangGraph typically relies on the separate LangSmith product for tracing. Strands provides basic native logging. None of the three produce a compliance-ready audit trail without additional integration.
Can LangGraph's interrupts replace a formal tool approval workflow?
LangGraph's interrupts provide a mechanism to pause execution before a node, which can be used to implement approval gates. However, this requires deliberate design per graph; it is not enabled by default and does not by itself constitute a governed approval workflow.
Evaluation Criteria for Security Engineers
Teams assessing OpenAI Agents SDK, LangGraph, or Strands for production use should work through the following questions before adopting a framework.
- Does the framework require custom authorization logic around every tool call, or does it offer any native scoping of agent-to-tool permissions?
- How is agent identity represented