LangChain Security: LangChain Agent Security and LangGraph Security Best Practices

The Cloud Security Alliance published a research note on LangChain and LangGraph vulnerabilities on March 29, 2026, collecting the significant disclosures in one place. These are the ones worth checking against your lockfile today. Versions listed are the first fixed release, so anything below is affected.

Two of those deserve a second look, because they are not really dependency bugs. CVE-2025-68664 is a code execution flaw whose trigger is prompt injection, which means patching removes the escalation path but leaves the injection itself. CVE-2025-46059 has no clean patch at all, because the vulnerability is that an agent read an email and believed it. The fix the disclosure recommends is architectural: treat external content as hostile input. That is a runtime control, not a version number.

One more thing worth knowing about the ecosystem. LangChain's own bug bounty explicitly excludes langchain-experimental. Several of the nastiest historical issues lived there, including CVE-2024-21513, where database values reached a Python eval call unsanitized. If langchain-experimental appears anywhere in a production lockfile, that is worth an afternoon. The full patch matrix and the reasoning behind each one is in our guide to LangChain security vulnerabilities.

LangChain's official security policy is short and unusually honest, and it is the right starting point because it comes from the maintainers rather than from a vendor. It names three principles: limit permissions, anticipate misuse, and defense in depth. The policy states plainly that "no security technique is perfect," and recommends combining approaches rather than trusting any single one.

Worth reading closely is what it says about anticipating misuse. If credentials permit deletion, assume the model might delete. That is not a warning about malice, it is a statement about how the system works. The practices below start from the framework's own guidance and then say where the gap is.

The pattern in the right-hand column is consistent. Every practice LangChain recommends is enforced inside the process that the agent controls, configured by the developer who wrote that agent, and invisible to anyone auditing later. That is fine for one agent built by one team. It stops working at the point where a security owner has to answer for twelve agents built by five teams.

LangChain 1.0 introduced agent middleware, a composable interception layer inside the agent execution loop. Middleware runs before the model is called, after the model responds, and after the agent finishes, which makes it a genuinely good place to put content checks. Guardrails in LangChain are implemented as middleware, and they stack, so you can layer several in order. The human-in-the-loop middleware uses the after-model hook to interrupt tool calls for approval. This is a real improvement over the callback patterns it replaced, and if you are building on LangChain you should use it.

It is also worth being precise about what it is. Middleware is application code running inside the agent process, in the same trust boundary as the agent, configured in the same repository, by the same developer, and deployed on the same release cycle. That has four consequences.

• It is opt-in per agent. An agent that was built without the guardrail middleware simply does not have it. There is no way to require it across a fleet, and no way to discover which agents skipped it except by reading every repository.
• It shares the blast radius. A vulnerability in the agent process, such as the code execution path in CVE-2025-68664, sits inside the same boundary as the middleware meant to constrain it. A control that an attacker can reach is not a control.
• It is changed by whoever ships the agent. Loosening a guardrail is a normal-looking code change in an application repository, reviewed by application reviewers. Nothing about it looks like a policy change.
• Its record is application logs. Useful for debugging, and not what an auditor means by an audit trail. There is no independent, append-only record that the gate existed and held.

None of that makes middleware the wrong choice. It makes it the inner layer. LangChain's own policy asks for defense in depth, and defense in depth means at least one layer outside the thing being defended. Middleware handles the fast, in-loop checks with full application context. A control point in front of the agent handles the policy that must apply whether or not a developer remembered, and produces the record that proves it. That outer layer is what we build, and it is described further on AI runtime security.

LangGraph adds durable state to the picture, and durable state is a security surface that stateless chains never had. A LangGraph agent checkpoints its progress so it can pause, resume, wait for a human, and survive a restart. Those checkpoints contain conversation history, intermediate reasoning, and often credentials or session tokens picked up along the way, and they are written somewhere: SQLite, Postgres, or Redis.

Two of the CVEs above are checkpoint bugs specifically. CVE-2025-64439 is remote code execution through deserialized checkpoint data, because the serializer could fall back to dynamic import. CVE-2025-67644 is SQL injection reachable through metadata filter keys in the SQLite backend, which exposes exactly the conversation histories and session tokens the checkpoint holds. Both are patched, and both illustrate the same structural point: the checkpoint store is now part of your attack surface, and it deserves the access controls you would give any database holding session data.

The behavioral risk with LangGraph is different from the one with a simple chain, and it is easy to miss. A graph agent runs for a long time across many steps. Injected instructions persist in state, so an instruction absorbed at step three is still in context at step forty, long after the document that carried it has scrolled out of anyone's attention. A control that only inspects the initial user prompt will not see it. Inspection has to happen on every hop where untrusted content enters, which is the entire point of putting the check on the action path rather than at the front door. That is covered on prompt injection detection.

Multi-agent LangGraph topologies compound it further, because one agent's output becomes another agent's input, and the second agent has no way to know the first one was reading a hostile document. We treat that as its own problem on multi-agent security.

This is the order we recommend, and it is deliberately front-loaded with the cheap work. Steps one and two take an afternoon and remove the largest single category of risk.

1. Audit the lockfile, package by package. LangChain's packages version independently, so check langchain-core, langchain, langgraph, langgraph-checkpoint, langgraph-checkpoint-sqlite, langchain-community, and every provider integration separately. Upgrading the top-level package does not necessarily move langchain-core.
2. Remove langchain-experimental from anything production-facing. It is outside LangChain's own bug bounty scope, which is the maintainers telling you where the line is.
3. Write down what each agent is actually allowed to do. Not what its prompt says, what its credentials and tool list permit. This is usually the moment a team discovers an agent has broader database access than anyone intended.
4. Give each agent its own identity. Shared service accounts make every later control weaker, because you cannot scope by caller and you cannot attribute in the trail.
5. Route agent traffic through a control point, in observe mode. Change the endpoint, not the policy. Nothing breaks because nothing is denied yet, and you spend two weeks learning what your agents genuinely do rather than what the design doc claims.
6. Scope tool permissions from observed behavior. Build the allowlist from the traffic you recorded. See tool permissions.
7. Inspect untrusted content on every hop. Retrieved documents, tool results, emails, and third-party tool descriptions all reach the model as text. If your agents also connect to Model Context Protocol servers, that path needs its own inspection, covered on MCP gateway.
8. Gate the irreversible calls behind a human. Deletes, transfers, external sends, bulk writes. Keep the routine majority automatic so the gate stays meaningful rather than becoming a button people click without reading.
9. Switch to enforce, and keep the trail. Observe mode already told you what denying would break. The audit trail is what makes the arrangement provable rather than merely true.

If the agent in question writes or executes code, the risk profile shifts again and the sandboxing question comes first rather than sixth. We cover that on coding agents. If it reads from a vector store, the index itself is an injection vector worth its own treatment, on RAG security.

Stated plainly, because a pilot judged against the wrong expectation fails for reasons that have nothing to do with the product.

The honest summary: patching fixes the framework, and a control point in front of the agent fixes the part patching cannot reach, which is an agent using its legitimate access on an instruction it should not have trusted. Neither substitutes for the other, and LangChain's own security policy is the clearest statement of why. No single technique is perfect, so run more than one. Teams weighing LangChain against the alternatives should read OpenAI agent security, which ships guardrail primitives LangChain leaves to you, alongside the security comparison between the two frameworks.