Securing AI Agent Frameworks: The Complete Guide for Security Teams (2026)

The decision in front of most security teams in 2026 is not whether to allow AI agent frameworks - a data team already pip installed LangChain, a developer already spun up a Langflow flow, an ML group already stood up MLflow - but how to govern an orchestration layer that reads every prompt, holds database and provider credentials, and runs generated code, after it appeared with no security review. Securing AI agent frameworks is the problem of bringing a fleet of LangChain, LangGraph, LangSmith, LlamaIndex, Langflow, Flowise, Gradio, and MLflow instances under the same controls as the rest of your infrastructure. The dynamic is the same shadow-IT pattern the AI artifact layer creates everywhere: high-capability software adopted bottom-up, faster than any review can keep up. This guide maps that attack surface, the vulnerability classes that define it, and the decision framework for governing it.

Treat this as the hub for a cluster of specific cases. Each vulnerability class below links to a worked advisory on a real CVE, and the framework inventory problem is the thread that connects them. An agent almost never runs a framework alone: it routes model calls through a gateway and tool calls through MCP servers, so read this alongside the sibling securing LLM gateways guide, which covers the model-routing layer, and the MCP server security guide, which covers the tool-and-data layer.

One framing matters before the details. Almost none of the headline framework bugs in 2026 are prompt injection. They are classic web and application flaws - unauthenticated RCE, unsafe deserialization, command injection, SSRF, SQL injection, path traversal, secret exfiltration - living in AI-specific code paths. That is both reassuring and awkward: the bug classes are familiar, but the surface they live on reports to no security tool you already run. The fix is the same as for any unmanaged surface: inventory it, govern its calls, and keep a record. If you are building a program from scratch, anchor it in the Anomity AI security framework.

What is an AI agent framework, and what is the orchestration layer?

An AI agent framework is the code an agent is built on and served through - the layer that sits between the model and the tools and decides what the agent actually does. It splits into a few shapes. Libraries such as LangChain, LangGraph, and LlamaIndex give an agent its chain, graph, retrieval, and tool-calling logic in code that runs inside your application. Low-code builders such as Langflow and Flowise turn a visual canvas of nodes into a running flow, so a non-engineer can wire an agent together and execute it. Gradio serves the interface an agent or model is reached through. MLflow tracks experiments, gates models through its AI Gateway, and serves them for inference. LangSmith adds tracing and observability across the LangChain stack.

Whatever the shape, this is the orchestration layer, and it is where an agent's power is concentrated. The framework reads the prompt and the retrieved context, so it sees source code, customer records, and secrets in flight. It holds the credentials the agent needs - provider keys, database passwords, API tokens - to do its job. It executes: a chain runs generated code, a builder node calls a tool, a serving endpoint loads a model and shells out. And it reaches internal services and external URLs on the agent's behalf. Everything an attacker wants from an agent runs through this layer.

The framework is not the model-routing layer or the tool-and-data layer, though it calls both. When a security review looks at AI risk, it often stops at the model provider and the MCP servers and misses the orchestration code entirely, because that code lives inside an application the team already owns. That blind spot is why the framework layer needs its own inventory and its own runtime governance.

Why does the orchestration layer concentrate so much risk?

Three properties of the framework layer turn an ordinary bug into an agent-wide problem. It is trusted, it is capable, and it is unmanaged. Each amplifies the others.

It is trusted because it runs inside a process your tools already allow. A LangChain deserialization flaw or an MLflow command injection executes as the application, from an IP and a binary EDR has no reason to flag, which is exactly why existing controls cannot see it. It is capable because the framework's whole job is to execute, fetch, and connect: a code node in a builder, a load() that deserializes, a model-serving path that shells out, a component that fetches a URL. The features that make a framework useful are the same features that become RCE, SSRF, and injection when input is not constrained.

It is unmanaged because it arrives bottom-up. A data team pip installs LangChain and langchain-core into a service; a developer runs a Langflow or Flowise builder to prototype and wires in real credentials; an ML group deploys MLflow to track and serve models. None of these pass procurement or a security review, which is the shadow-IT dynamic at the heart of the AI artifact layer. The result is a fleet of high-capability, credential-holding software that nobody has a full list of - and you cannot govern what you have not inventoried.

What are the main vulnerability classes in AI agent frameworks?

The serious framework CVEs of 2025-2026 fall into a handful of familiar classes. Knowing the class tells you what to look for across products, because the same bug recurs in a builder, a library, and a serving runtime for the same reasons. The table maps each class to its mechanism, impact, and a worked advisory.

Unauthenticated RCE is the most severe and, in the builders, the most direct. The Langflow Shareable Playground RCE (CVE-2026-48519) let an unauthenticated caller reach a code path that executes on the server through the Shareable Playground endpoint, and the Flowise Airtable_Agent code injection (CVE-2026-41265) turned an agent node's input into executed code. Both are cases of a builder feature running code the operator never intended.

Unsafe deserialization and command injection are the library-and-serving equivalents. The LangChain unsafe deserialization flaw (CVE-2026-44843) came from broad load() allowlists in langchain-core reconstructing attacker-supplied objects, a textbook CWE-502. The MLflow model-serving command injection (CVE-2026-0596) passed a model_uri into a bash -c invocation, a CWE-78 that runs commands on the serving host.

SSRF and SQL injection round out the loud classes. The Gradio proxy_url SSRF (CVE-2026-28416) let an untrusted proxy_url in gr.load() steer the app's own outbound requests, a CWE-918 that reaches internal services and metadata. The LlamaIndex vector-store SQL injection (CVE-2025-1793) let unsanitized input reach a store query, the CWE-89 that has haunted web apps for two decades, now in a retrieval path.

The quieter classes are easy to underrate. The LangChain prompt-template injection (CVE-2026-40087) used f-string template handling to leak internal state into prompts and logs, a moderate-severity flaw that widens every downstream attack. The LangSmith SDK arbitrary file read (GHSA-f4xh-w4cj-qxq8) let a TracingMiddleware read files off the host, and the MLflow AI Gateway secret exfiltration (CVE-2026-4035) leaked environment-variable secrets, a CWE-201 that hands over the very credentials the gateway was meant to guard. These classes overlap directly with the secrets management for AI agents problem and, where an f-string template is fed by retrieved content, with indirect prompt injection.

Why can't my existing controls see the framework layer?

Because the exposure lives in the AI artifact layer, and the malicious step almost always looks ordinary. When langchain-core deserializes an attacker's object in CVE-2026-44843, EDR sees a legitimate Python process doing legitimate Python things. When MLflow shells out in CVE-2026-0596, the network sees traffic to a service you deployed on purpose. When Gradio makes a caller-steered request in CVE-2026-28416, egress monitoring sees the application making outbound calls, which is its entire job. DLP sees nothing leave the perimeter until an exfiltration is already underway. The controls are working as designed; the surface is simply outside their model.

The gap is concrete. Network and EDR can tell you a process is running and a port is open, but not that the process imports a vulnerable langchain-core, or that a Langflow builder is bound to an interface it should not be, or that three agents and two MCP servers depend on the same framework. Those facts require an inventory of frameworks as artifacts, with versions and relationships - the same gap covered in how Anomity compares to Network, EDR, DLP, and GRC tooling. And because so many of these frameworks are installed as packages, the framework layer overlaps the AI supply-chain problem: a compromised or typosquatted dependency lands in the same import graph.

There is a second reason the framework layer is easy to miss: it is often reached through a coding agent or CLI. A developer's assistant edits a chain, installs a package, or runs a flow, so the framework's risk and the agent's risk are entangled. The securing AI coding agents and CLIs guide covers that entry point; here the point is that the framework the agent touches is itself an artifact worth governing.

How do low-code builders change the exposure?

Langflow and Flowise deserve their own treatment because they collapse the distance between a diagram and running code. A builder is a full web application: it has an HTTP server, an authentication story, a set of nodes that fetch, transform, and execute, and a store of the credentials wired into each flow. When a developer stands one up to prototype, all of that ships at once, usually without anyone reviewing the auth model or the exposure.

The nodes that make builders useful are the risky ones. A code node executes arbitrary logic by design. An agent node that generates and runs Python is an RCE waiting for unconstrained input, which is exactly what the Flowise Airtable_Agent code injection (CVE-2026-41265) turned out to be. A sharing or preview feature meant to let a colleague try a flow can expose an execution path to anyone who can reach it, as the Langflow Shareable Playground RCE (CVE-2026-48519) showed by reaching an unauthenticated code path. The builder is doing what it advertises; the problem is that no one scoped who could drive it.

The credential angle compounds it. A flow that queries a database or calls an API stores those secrets so the flow can run unattended, so a builder compromise is often a credential compromise as well. That is the same overlap with secrets management the loud RCE classes create, and it is why inventorying the builder as an artifact - and knowing which secrets it holds - matters as much as patching it.

How do I select and configure an AI agent framework securely?

Selection should weigh the security posture, not only the developer experience and feature list. The questions below separate a framework you can defend from one you cannot.

• No unsafe deserialization on untrusted input. Confirm the framework does not reconstruct arbitrary objects from data an attacker can supply, and that any load() path uses a tight allowlist - the failure mode behind CVE-2026-44843.
• No untrusted value reaching a shell or a code executor. Model-serving and agent nodes must not pass caller input into bash -c or an eval, the class behind CVE-2026-0596 and CVE-2026-41265.
• Authentication in front of every builder and serving endpoint. A builder's execution, sharing, and preview routes must require auth and must not be exposed by default, as the Langflow Shareable Playground path (CVE-2026-48519) was.
• SSRF egress controls. Caller-supplied URLs, proxy_url values, and registry endpoints must be allowlisted so the framework cannot reach internal services or cloud metadata, the core of CVE-2026-28416.
• Parameterized queries in retrieval paths. Vector-store and metadata queries must not concatenate untrusted input, the failure in CVE-2025-1793.
• Careful template and logging handling. Prompt templates must not interpolate untrusted content into internal state or logs, as CVE-2026-40087 did, and middleware must not read arbitrary paths, as GHSA-f4xh-w4cj-qxq8 did.
• Secrets kept out of reachable environment. Gateway and serving processes must not expose provider secrets through their own paths, the class behind CVE-2026-4035.
• Inventory and audit hooks, so the framework and every agent built on it can be governed at the call and recorded in a 90-day audit trail.

On configuration, the highest-leverage hardening is consistent across products: require authentication in front of every builder, serving, and admin route; take any instance meant for localhost off shared networks; allowlist the URLs and registries the framework may fetch; deny it egress to internal segments and metadata endpoints; and keep the framework and its dependencies on a fast patch cadence. The Anomity docs cover wiring the inventory and hook enforcement that make these enforceable rather than aspirational.

How do the major frameworks compare on attack surface?

No framework is uniquely unsafe; each concentrates a different risk because of what it does. The matrix below is a decision aid for where to focus controls per product, grounded in the 2025-2026 CVE record. It is not a ranking - it is a map of where each one has been bitten.

Two patterns cut across the matrix. First, the builders (Langflow, Flowise) concentrate unauthenticated RCE because their core job is to execute the flow a user draws, so exposure plus a code-capable node is a direct path to the host. Second, the libraries and serving runtimes (LangChain, LlamaIndex, MLflow, Gradio) concentrate the classic web classes - deserialization, injection, SSRF, secret leakage - because they parse, query, fetch, and serve attacker-influenced input in code that runs with the application's trust. Map your fleet against this matrix and you know where the next bug is likely to land, which presupposes you have the fleet inventory to map against.

What about edge cases - ephemeral flows and embedded frameworks?

Two edge cases break the "just review the app" instinct. The first is the embedded library. LangChain, langchain-core, LlamaIndex, and Gradio are usually not standalone services but imports inside another application, so they never appear on a network scan or a service catalog - they are a line in a requirements file. A vulnerable langchain-core reaches production inside a dozen unrelated apps, and patching one does nothing for the others. The unit of risk is the artifact in the process, not a host on a diagram.

The second is the ephemeral builder. A Langflow instance a developer starts for an afternoon, a Flowise container in CI, an MLflow serving job that lives for one experiment - these never make it into a static asset list but are live long enough to be reached and exploited. Point-in-time scans miss them; continuous endpoint inventory does not. The same applies to a framework bound to localhost that an agent reaches but no external scan ever sees.

Both cases share a root cause: the framework is an artifact on the endpoint, whether it is a long-lived service, an imported package, or a container that lived for an hour. Governing the agent's call - the allow/deny/log decision at the hook - covers the embedded and the ephemeral case alike, because it does not depend on the framework being a reachable service or surviving long enough to land in an asset database.

How Anomity governs the AI agent framework layer

Anomity treats an AI agent framework as an agentic endpoint artifact and governs it in three concrete steps. The structure matters because the framework's own guardrails can fail - a broad load() allowlist, an exposed builder route, an untrusted value reaching a shell - so the reliable place to enforce policy is the agent's call, not a check the framework has been tricked into passing.

First, inventory. Anomity inventories every AI agent framework on every managed endpoint as one of eight AI artifact types - alongside AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. It records the exact version of LangChain, LangGraph, LangSmith, LlamaIndex, Langflow, Flowise, Gradio, or MLflow, so finding every install below the fixed release named in an advisory is a single query rather than a fleet sweep. It captures the relationships - which agents, CLIs, and MCP servers build on each framework - and classifies each by the capability it exposes. Metadata only: secret values are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example the PreToolUse event in Claude Code - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. An agent triggering a code node, a load() that would deserialize untrusted data, a model-serving command, or an outbound fetch to a target outside your allowlist is checked at the call boundary. That means the path that leads to CVE-2026-41265, CVE-2026-44843, CVE-2026-0596, or CVE-2026-28416 is governed by your policy even when the framework's own check is the thing that failed - and even when there is no vendor patch yet. This is the enforcement point runtime governance provides.

Third, keep the record. Every install, version change, and decision lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira so the right team sees them where they already work. When responders ask which frameworks ran a vulnerable build, which agents depended on them, and what code paths or URLs were reached, you answer from a record rather than a reconstruction. Anomity is SOC 2 Type II and complements - does not replace - your Network, EDR, DLP, and GRC tooling; it adds the agentic-endpoint layer those tools were never built to inventory. See how it works for the end-to-end flow.

You can't govern what you can't see.The Anomity principle

What should security teams do next?

Start with the inventory question, because every other control depends on it. Work through the list below in order; the first three items close the largest share of the exposure described in this guide.

1. Inventory every endpoint, container image, and CI runner for LangChain, langchain-core, LangGraph, LangSmith, LlamaIndex, Langflow, Flowise, Gradio, and MLflow, and record the version of each - including frameworks imported inside apps or bound to localhost.
2. Patch each framework to the fixed release named in its advisory (CVE-2026-48519, CVE-2026-41265, CVE-2026-44843, CVE-2026-40087, GHSA-f4xh-w4cj-qxq8, CVE-2025-1793, CVE-2026-28416, CVE-2026-4035, CVE-2026-0596), and treat any build below that release as live-vulnerable until confirmed.
3. Remove accidental exposure: require authentication in front of every builder and serving endpoint, and take any Langflow, Flowise, Gradio, or MLflow instance meant for localhost off shared networks.
4. Constrain the dangerous nodes and paths: no untrusted input into code nodes, load(), or a shell; parameterize retrieval queries; allowlist the URLs and registries a framework may fetch.
5. Audit the secrets each framework and flow holds, and rotate any provider or database credential reachable from a framework that ran a vulnerable build.
6. Govern agent calls to code nodes, deserialization paths, model-serving commands, and outbound fetches with allow/deny/log at the hook, and write every framework change and governed call to a 90-day audit trail routed to your SIEM.

If you are formalizing this into a program, the agentic AI governance guide puts the framework layer in the context of the wider AI artifact estate, and the AI security framework gives the control structure to map it to.

The decision framework for securing AI agent frameworks comes down to three moves applied in order: inventory every framework and its version as an artifact on the endpoint, patch fast but assume some builds are unmanaged and some flaws have no fix yet, and govern the agent's call at the hook with a 90-day record so policy holds even when the framework's own guardrail is bypassed. The orchestration layer is where an agent's logic, credentials, and reach all live, which is exactly why it cannot stay a blind spot. To see Anomity inventory your frameworks, govern tool calls at the hook, and keep the audit trail across your fleet, request early access.