LangGraph has quickly become the framework of choice for building stateful, multi-step AI agents. Its graph model — nodes, edges, conditional routing, and persistent state — gives you the control flow that simple ReAct loops lack. But that same expressiveness widens the attack surface. A LangGraph agent doesn't make one tool call; it makes dozens across cycling nodes, accumulating state that can carry an injected instruction from one turn into a destructive action three nodes later.
This guide is for platform and security engineers shipping LangGraph agents to production. We'll cover the framework-specific risks, the hardening you should do inside your graph, and — critically — the network-layer enforcement that catches what in-process guardrails miss. That last layer is where Agent G lives: an egress proxy that inspects and gates every outbound call your agent makes, regardless of which node initiated it.
Why LangGraph agents are harder to secure
A stateless chain is easy to reason about: input goes in, output comes out, you validate both. LangGraph deliberately breaks that model. Three properties make it riskier in production.
Persistent, mutable state
LangGraph's StateGraph threads a shared state object through every node. That state is the agent's working memory — and it's mutable. If an untrusted document retrieved in a tool node injects an instruction into state, that instruction persists. A node executed much later may read it and act on it, long after the original prompt-filtering pass approved the turn. The classifier that vetted the user's message never sees the poisoned intermediate state.
Cycles and conditional edges
Graphs loop. An agent can revisit a tool-calling node repeatedly, refining its approach until a condition is met. This is powerful for tasks like iterative code generation or research, but it means a single compromised reasoning step can drive many outbound calls. Without per-call limits, a runaway loop becomes a denial-of-wallet event or a slow exfiltration channel. See our guide on runaway-agent throttling for the egress-layer controls that cap this.
Node-level tool autonomy
In LangGraph, tools are bound at the node level and the model decides which to invoke with which arguments. Your graph topology constrains when a tool can run, but not what the model asks it to do. The model can pass any URL to an HTTP tool, any command to a shell tool, any recipient to an email tool. Topology is not a security boundary — the arguments are where the danger lives, and they're chosen by an LLM influenced by untrusted content.
Hardening inside your graph
Start with the controls you own directly in code. These reduce risk but, as we'll see, cannot be your only line of defense.
Scope tool binding per node
Don't bind your full tool registry to every node. A research node needs read-only retrieval; it has no business holding a database-write tool. Use distinct tool sets per node so the graph's structure enforces least privilege. This limits which capabilities are reachable at each step and shrinks the set of actions any single compromised node can trigger.
Validate state transitions
Treat your state object as untrusted between nodes. Add reducer functions that validate and sanitize fields rather than blindly appending. If a node is only supposed to set a numeric score, enforce that type. Never let free-text fields silently become control instructions for downstream routing logic.
Use checkpointers deliberately
LangGraph checkpointers persist state for durability and resumption. That's a feature for reliability and a liability for security — checkpointed state can carry poisoned content across sessions, a form of memory poisoning. Encrypt checkpoint stores, scope access tightly, and consider expiring or sanitizing checkpoints that contain externally sourced content.
Add interrupts for risky nodes
LangGraph supports interrupts that pause execution and wait for human input before proceeding. Use them. Any node that performs an irreversible or high-impact action — sending money, deleting data, posting publicly — should be gated behind an interrupt. This is the framework-native version of human-in-the-loop approval.
Why in-process guardrails aren't enough
Everything above runs inside your Python process, in the same trust boundary as the agent. That's the fundamental problem. If the model is manipulated into emitting a malicious tool call, your in-graph validation is only as good as the code paths the model chooses to traverse. Worse, libraries that wrap tool calls can be bypassed when the agent constructs a network request through a path your wrapper doesn't cover — a raw httpx client, a transitive dependency, a subprocess.
LangGraph interrupts depend on the graph reaching the interrupt node. A prompt-injected agent that routes around that node — or a tool that makes a side-effecting call before the interrupt fires — defeats the gate. In-process controls and the thing they're trying to control share the same memory, the same credentials, and the same network stack. This is the core argument for moving enforcement to the network boundary: a control plane the agent cannot reason its way around because it lives outside the agent's process entirely.
Enforcing egress on node-level tool calls
Agent G sits on the wire between your LangGraph agent and everything it talks to. Every outbound HTTP request, DNS lookup, and API call — no matter which node generated it — passes through the proxy, where policy is evaluated and the call is allowed, blocked, redacted, or escalated for approval.
Default-deny allowlisting
The foundation is a default-deny egress allowlist. Your LangGraph agent can reach the model provider, your approved internal APIs, and the specific SaaS endpoints its tools require — and nothing else. A poisoned retrieval node that tries to POST your customer data to an attacker domain gets a connection refused at the proxy, even though the in-graph tool wrapper happily constructed the request. Topology didn't stop it; egress policy did.
Tool-argument inspection
Because Agent G inspects the actual request payload, it sees the arguments the model chose. If an HTTP tool is invoked with a URL pointing at the cloud metadata endpoint, that's a classic SSRF attempt — blocked regardless of which node fired it. If an email tool's body contains what looks like an API key or a block of PHI, outbound DLP normalization catches it. This is enforcement at the layer where intent becomes action.
Out-of-band human approval
Rather than relying solely on graph interrupts, Agent G can escalate a matching call for approval out-of-band. A node attempting a wire transfer or a DROP TABLE against production triggers an approval request to your reviewers; the call is held at the proxy until someone approves or denies it. Because this runs outside the agent process, an injected prompt can't skip it. Pair this with our pattern for requiring approval on risky actions.
Complete, tamper-evident logging
Every call your LangGraph agent makes is logged at egress with full request context — node origin, destination, arguments, decision. When something goes wrong, you can reconstruct exactly what the agent did from logs that live outside its trust boundary, the kind of verifiable audit evidence auditors and incident responders actually trust.
Wiring Agent G into a LangGraph deployment
Deployment is a configuration change, not a code rewrite. Route your agent's outbound traffic through the Agent G proxy by pointing standard HTTP_PROXY and HTTPS_PROXY environment variables at it, or by deploying it as the egress gateway in your Kubernetes namespace or VPC. The proxy terminates and inspects TLS without breaking your tool calls, then forwards allowed traffic. Your LangGraph nodes don't need to know it's there — they just make their calls as usual, and policy is enforced transparently.
Define policy as code: which domains each agent identity may reach, which argument patterns trigger a block, which actions require approval. Version it in Git alongside your graph definition so security review tracks application changes. The full integration walkthrough lives in our documentation, and platform teams operationalizing this across many agents should read the platform engineer's guide to agent egress.
A layered model for production LangGraph
Secure LangGraph agents are defended in depth. Inside the graph: scoped tool binding, validated state transitions, deliberate checkpointer hygiene, and interrupts on risky nodes. Outside the graph: a default-deny egress proxy that inspects every call's arguments, blocks unauthorized destinations, redacts sensitive data, escalates high-risk actions for human approval, and logs everything to a place the agent cannot tamper with.
The in-graph controls make your agent well-behaved. The egress layer makes it containable even when it isn't. For stateful agents that loop, accumulate memory, and call tools across many nodes, that containment is the difference between a contained incident and a breach. See pricing or request access to put Agent G in front of your LangGraph agents before they ship.