Illustrated by Jeff Prymowicz
Your agent framework is a security boundary
Most teams pick an agent framework the way they pick any library. How fast can we ship? Is tool calling easy? Does it do multi-agent? Can it stream? Those are fair questions. They are just not the ones that will hurt you in production.
The question that will hurt you is quieter. What does this framework make easy by default, security-wise? An agent sits between a model that guesses and systems that do real damage when they are wrong. Databases. SaaS APIs. Internal tools. A shell. A browser. Customer records. The framework you pick decides how tool calls are represented, where state lives, whether secrets ever touch the runtime, how a human approves a risky action, and whether the agent runs in a sandbox or straight inside your web process. None of that is ergonomics. It is architecture, and most of it is security architecture.
The spectrum is more vertical than horizontal. Managed platforms sit at the top because the provider handles more of the runtime work. Identity, isolation, scaling, and observability sit closer to the platform. Batteries-included SDKs sit in the middle. Custom orchestration sits at the bottom, where the control is better and the security work is yours.
Managed platforms such as Amazon Bedrock AgentCore, Google Vertex AI Agent Builder, and Microsoft Foundry take more of the runtime off your plate. Identity, scaling, observability, and often isolation move into the provider's layer. AgentCore is the awkward case in this comparison, in a useful way. It is not just another agent framework box. A LangGraph graph, a CrewAI crew, a Strands agent, or custom agent code can run inside AgentCore Runtime. The framework still decides how the agent thinks and routes work. AgentCore decides where that code runs and which managed controls wrap it. That layer distinction matters.
Batteries-included SDKs such as CrewAI and the OpenAI Agents SDK still get an agent into production-shaped code faster. Put no managed runtime or external sandbox around them, and the application team owns the boundary. LangGraph and other customizable orchestration stacks give teams the state machine and routing, then leave the same team holding the boundaries, auth, storage, and execution work.
This is not a hunt for the one secure framework and two insecure ones. It is about where each one draws its trust boundaries. The dangerous design is one loop with private data on one side, hostile instructions on the other, and an outbound channel waiting at the end.
Why the framework is a security decision, not just an ergonomics one
A web framework shapes how requests become responses. It gives the application a place for routing, middleware, templates, and database access. An agent framework shapes runtime authority. It decides what the model can touch, who checks the arguments, where memory lives, whether tool output feeds the next prompt, and when a person has to approve an irreversible action. That is a different kind of decision, and it rewrites your threat model.
Simon Willison's "lethal trifecta" is private data plus untrusted instructions plus an outbound channel. Put all three in one agent, and you have a problem waiting for a prompt. The framework decides how close to that arrangement you start. Run tools in the same memory space as the host app, and one good injection can turn into code execution or stolen credentials. Serialize untrusted objects into a local database without checking them, and you have an insecure-deserialization bug. Neither of those is theoretical. Both have shown up as real, patched CVEs in frameworks people use every day.1
I use a one-page rubric for the rest of this piece. It asks what the framework makes easy, what it leaves to the team, and where the trust boundary actually sits.
Bedrock AgentCore: managed posture, IAM, Gateway, Identity
Think of Amazon Bedrock AgentCore less as “the framework” and more as the managed layer under whatever framework the team already chose. AWS describes Runtime as framework-agnostic. The examples are not subtle: LangGraph, CrewAI, Strands, Google ADK, the OpenAI Agents SDK, and custom agents all use the same basic entrypoint pattern. That means a team can keep a LangGraph or CrewAI implementation and put AgentCore underneath it. The security payoff is boring in the good way. Isolation, identity, gateway-mediated tool access, memory, and observability become platform concerns instead of scattered app code.
What AWS gives you
Every AgentCore runtime session is stateful and runs in its own Firecracker microVM, with a dedicated filesystem and shell, so one user's session cannot bleed into another's.2 The runtime assumes an IAM role you control. Inbound requests can require JWTs from your identity provider. VPC networking can reach private resources. And Cedar policies on the Gateway can gate a tool call by who is asking, which tool, under what condition, and with which arguments. That is a real difference from an agent loop running inside your Flask app.
Gateway is the part to watch. It turns your APIs, Lambda functions, and existing services into MCP-compatible tools, and it moves the ugly authentication work to the boundary. Ingress auth, egress auth, OAuth flows, token refresh, secure storage, and credential injection stop being code every agent team has to rebuild.3 When an agent needs a SaaS token, AgentCore can run the three-legged OAuth dance, drop the result into an encrypted Token Vault, bind it to that specific user-and-agent pair, and slip it into the outbound call. The raw secret never lands in the prompt or the model's context. That alone closes off a whole category of "prompt-injection steals the API key" attacks, which is not nothing.
What is still yours to own
AgentCore is managed, not magical, and AWS is blunt about the split. AWS runs the substrate. You still own the agent code, dependency chain, IAM scope, session-to-user mapping, command policy, input validation, prompt-injection defenses, trusted skills, and network configuration.4 One line should stay on a sticky note. AgentCore treats invocation input as trusted. It does not sanitize, filter content blocks, or enforce behavioral limits. Point it at users you do not fully trust and that validation is on you, in your application layer. AgentCore raises the floor on infrastructure. It does not do your application security for you.
CrewAI: multi-agent orchestration, role and tool exposure, self-hosted footprint
CrewAI is the batteries-included one. You assemble "crews" of role-playing agents that take on tasks, make calls, use tools, share memory, and hand work to each other.5 People reach for it because the abstractions read like an org chart, which makes a workflow easy to sketch. The security question is blunter than the marketing. Where does the process run, and what can it touch?
Tool exposure and code execution
By default a CrewAI agent inherits everything the host process can do. That puts the local filesystem in scope. Same for environment variables and the network. That flat model is fine until you hand the agent something powerful. CrewAI's own docs draw the right line on code execution. Safe mode runs code in Docker and is the one meant for production. Unsafe mode runs it directly and belongs only in trusted environments.6 Getting that wrong has bitten people. A 2026 CERT advisory (VU#221883) catalogued sandbox-escape, SSRF, and local-file-read bugs in CrewAI's code-execution path, and the project responded by ripping out its built-in interpreter and telling users to bring a dedicated external sandbox instead.7 The lasting lesson is simple. CrewAI gives you the orchestration, but production isolation is still a deployment job you have to do yourself.
Memory, state, and MCP trust
CrewAI's memory runs content through an LLM on the way in and recalls it later by similarity, recency, and importance. By default, it sits in LanceDB under ./.crewai/memory, and because that content gets sent to the configured model for analysis, the docs suggest a local or compliant provider when the data is sensitive.8 For security review, do not treat this as chat history. It is a layer that quietly shapes what the agent does next. Put customer data, credentials, or a poisoned instruction in there, and it can steer future runs. So it needs real file permissions on the host, not whatever the directory defaulted to.
CrewAI's MCP guidance is unusually honest. Only connect to servers you fully trust. An MCP server can execute code, inspect data, reshape the agent's behavior, make calls it should not, or hide instructions in tool metadata.9 That last one catches people. MCP expands the tool surface and the injection surface at the same time. The metadata itself becomes context the model reads.
CrewAI is good to build with. Production safety comes from the runtime around it. Tool allowlists, memory backend, secrets handling, and MCP review are not optional plumbing; they are the boundary.
LangGraph: graph and state control, checkpointing, explicit approval
LangGraph is the one you pick when you want control. LangChain pitches it as a low-level orchestration framework for long-running, stateful agents, built around durable execution, streaming, human review, and persistence rather than a tidy high-level agent object.10 Security teams like that, because the control flow is explicit. You decide when the model sees a tool, when state changes, when the graph pauses, and which node does the checking. The catch is that explicit control means you are responsible for all of it.
State and persistence
LangGraph splits persistence into checkpointers and stores. Checkpointers save a thread's graph state. Stores keep long-term data across threads.11 That is what powers conversation continuity, time travel, fault tolerance, and human review. It also makes the checkpointer something you have to treat as integrity-critical. Tamper with graph state and you can steer the next run. Persist a sensitive tool output and the checkpointer is now sensitive storage. Drop a secret into state by accident and it lingers there longer than you think. This moved from theory to incident in 2026, when a disclosure chained a SQL-injection flaw in the SQLite checkpointer to an unsafe msgpack deserialization bug and got remote code execution out of it. The issue has since been patched and hardened with a strict deserialization allowlist.12 Treat the checkpoint database like production data. Patch it, and keep untrusted writes away from it.
Human-in-the-loop and tool execution
Human review is where LangGraph genuinely shines. An interrupt can pause the graph at a specific point, save state through the persistence layer, and wait as long as it needs for input. With a durable checkpointer and a stable thread ID, the run picks up exactly where it stopped.13 For AppSec, the value is the hard stop before a node sends an email, edits a ticket, issues a refund, deploys, or deletes something.
LangGraph is not a sandbox, though. Tool nodes run wherever you put them.14 That is the design talking, not a defect. The explicit routing helps. A graph wired only to tightly scoped, allowlisted functions may not need a full OS-level sandbox, as long as you validate what goes in and comes out. The moment you hand it a general-purpose or powerful tool, push that execution into an external microVM-backed sandbox, and put an auth proxy in front so secrets get injected only after traffic has left the untrusted box. Keep the keys out of the agent's reach entirely.
LangGraph is strongest when a team needs precise state and reviewable control flow. It is weakest when that team mistakes control of the graph for isolation of the tools running inside it.
Side-by-side security scorecard
How to choose, given your risk profile
No framework is secure in the abstract. These choices are not perfectly exclusive either. A team can build in LangGraph or CrewAI first, then move the working agent to AgentCore Runtime once hosting becomes the harder problem. The real question is less “which logo wins?” and more “which boundary does this team want to own?” Data sensitivity, infrastructure appetite, and agent security experience decide the answer. I would choose this way.
Pick AgentCore when the runtime boundary should be AWS-native infrastructure, not a pattern every product team invents on its own. It also fits the migration case. A LangGraph or CrewAI agent already works locally; now production hosting is the real problem. Move isolation, identity, observability, and tool access into the managed layer. The cost is coupling to AWS and actually learning the shared-responsibility model. You still owe scoped IAM, validated inputs, trusted skills, prompt-injection defenses, and careful downstream authorization. Managed does not mean done.
Pick CrewAI when speed matters and the work is genuinely multi-agent. Research-and-review loops fit it. So do business-process automations where the role-and-crew model reads cleanly. Go in clear-eyed. OSS CrewAI is an application framework, not a security boundary. Code execution, MCP servers, memory, credentials, and network access are all infrastructure you have to secure yourself, ideally inside a hardened, policy-driven host.
Pick LangGraph when a non-deterministic agent needs deterministic rails. It is the better fit for explicit routing, inspectable state, resumability, approval gates, and long-running jobs. The cost is that the security architecture is entirely yours. LangGraph hands you the state machine. You bring the sandbox, policy engine, storage controls, identity propagation, and secret handling. You also keep the persistence layer patched and walled off from untrusted writes.
Practical hardening, whichever one you pick
The same controls show up across all three. Six carry most of the weight.
- Split reasoning from authority. Let the model decide what it wants to do. Let a deterministic layer decide whether it is allowed to. IAM, Cedar, OPA, an internal policy service, or just a narrow API wrapper will do.
- Give narrow tools, not broad ones. "Run Python," "query the database," "send an HTTP request" are loaded guns. Prefer get_invoice_status(customer_id) or request_refund_approval(order_id).
- Keep secrets out of prompts, memory, checkpoints, traces, and serialized state. Use brokers or vaults, issue short-lived tokens, and inject credentials outside the model path. Anywhere the model can read a key, assume it eventually will.
- Treat memory as production data. Put tenant isolation, retention rules, access control, encryption, poisoning defenses, and audit trails around it. The works.
- Make irreversible actions wait for a human. LangGraph interrupts, CrewAI Flow persistence, and AgentCore policy gates can all do this. None of them will unless you design it in on purpose.
- Watch tool calls, not just model output. The event you care about is rarely "what did the model say." It is "what did the agent just try to do."
Where this leaves you
The framework sets security defaults whether anyone meant it to or not. AgentCore gives the most managed posture because AWS owns more of the runtime boundary, and it can be the place where a LangGraph or CrewAI agent runs. CrewAI is still the fastest path to a working multi-agent system; just do not confuse that with a hardened host. LangGraph is still the control pick for state, routing, and review. That control only pays off if the team keeps the graph from turning into an over-privileged local process.
The safest pick is not always the most managed one. It is the one whose trust boundaries match the risk, the team, the deployment model, and the authority sitting downstream of the agent. Get that match right and the framework stops being a silent liability.
Reviewing an agent framework choice? Cloud Security Partners does framework security reviews.
About the Author
Peter Karman is an AI Security Engineer at DryRun Security. He builds agentic, LLM-powered code-review systems that review PRs, ground findings in evidence, and alert of potential security issues. With 17+ years across infrastructure, networking, and software engineering, he designs dependable review pipelines, grounds findings in evidence, and instruments the process so performance meets real-world cost and latency constraints. He previously led engineering and AppSec initiatives as a Principal Engineer at companies like Leafly and AnyRoad.
Cloud Security Partners partnered with DryRun Security for this blog. DryRun Security is the industry’s first AI-native, agentic code security intelligence solution. Powered by their proprietary Contextual Security Analysis engine, they secure software built for the future by helping security and developer teams quiet noise, gain insights, and surface risks that pattern-based scanning tools inherently miss.
References
1CERT/CC VU#221883 and Check Point Research on LangGraph, cited per-framework below: https://kb.cert.org/vuls/id/221883
2AgentCore harness documentation: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness.html
3AgentCore Gateway documentation: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html
4AgentCore security and access controls: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-security.html
5CrewAI Agents documentation (tools, safe/unsafe code execution): https://docs.crewai.com/concepts/agents
6CrewAI Agents documentation (tools, safe/unsafe code execution): https://docs.crewai.com/concepts/agents
7CERT/CC Vulnerability Note VU#221883 (CrewAI SSRF, RCE, local file read): https://kb.cert.org/vuls/id/221883
8CrewAI Memory documentation (LanceDB default, LLM analysis): https://docs.crewai.com/concepts/memory
9CrewAI MCP Security Considerations: https://docs.crewai.com/mcp/security
10LangGraph overview (LangChain docs): https://docs.langchain.com/oss/python/langgraph/overview
11LangGraph persistence (checkpointers and stores): https://docs.langchain.com/oss/python/langgraph/persistence
12Check Point Research, From SQLi to RCE: Exploiting LangGraph's Checkpointer (CVE-2026-28277, CVE-2025-67644): https://research.checkpoint.com/2026/from-sqli-to-rce-exploiting-langgraphs-checkpointer/
13LangGraph interrupts (human-in-the-loop): https://docs.langchain.com/oss/python/langgraph/interrupts
14LangGraph quickstart (tool nodes): https://docs.langchain.com/oss/python/langgraph/quickstart
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
