LangGraph Security - openclawsecurity.net Forum

My results after running a static analysis tool on our graph definitions.

David Chen — Tue, 30 Jun 2026 01:59:58 +0000

Just ran a basic static analysis script over our ~50 production LangGraph definitions. The results aren't surprising, but the scale is. Primary issues found: * 80% of graphs have at least one tool node with no explicit error state handling. Fails open. * 30% pass raw, uncleaned LLM output directly into a conditional edge. Prompt injection into the graph flow is trivial here. * Multiple instances of entire conversation state being checkpointed to a DB, including system prompts and internal reasoning. That's a data leak waiting for a subpoena. * Heavy use of LangSmith tracing by default. We're paying to record and store PII and internal decision logic on a vendor's server. Cost-benefit is negative. We're building complex, stateful workflows without the basic guardrails you'd demand for any other data pipeline. The hype is about "agentic AI," but the reality is increased attack surface and opaque data flows.

Am I paranoid for wanting zero LangSmith telemetry in prod?

Eve Redmond — Mon, 29 Jun 2026 23:01:04 +0000

So the official line is that LangSmith is "just" for debugging, and you can turn it off in production. Fine. But have you actually looked at what gets shipped when you `pip install langgraph`? The default telemetry is baked into the runtime, and "opting out" requires you to find the right, poorly-documented environment variable *and* hope your deployment actually respects it. I’m building a state graph that handles customer PII and internal API keys. The checkpointing system is writing my graph’s state to an external store. LangSmith, by default, wants to phone home with trace data. Even if they anonymize it (big if), the structure of the data is a blueprint of my entire agent’s logic and tool use patterns. That’s a goldmine for anyone who knows how to look. Their docs make it sound trivial: ```bash LANGSMITH_TRACING=false LANGSMITH_API_KEY="" ``` But then you have to wonder: does the SDK respect this at every layer, or is there some eager initialization that fires off before your env loads? Have you audited the network calls? I had to wrap the module in a firewall rule to be sure. This isn't just about data exfiltration. It's about attack surface. Every external endpoint your library calls is a potential leak vector. If LangSmith's API gets popped, does my trace data, which might contain sanitized-but-inferable state, become part of a breach? Why should my prod runtime even have that handshake logic? Am I paranoid, or is everyone else just blindly accepting that their orchestration framework needs to call home by default?

Help: Graph permissions - how to stop one user's graph from calling internal tools?

Peter Chang — Mon, 29 Jun 2026 16:01:08 +0000

I've been experimenting with LangGraph for an internal tool that handles both public support queries and privileged internal operations. I've hit a design wall: how do you isolate user-specific subgraphs so they can't reach internal tools? I'm worried about a user's graph state somehow getting a reference to a node that calls, say, our employee database or deployment API. Right now, my `StateGraph` has both user-facing tools (like `search_knowledge_base`) and internal ones (like `query_hr_system`). The execution seems to have full access once you call `compile()`. I need a way to apply runtime restrictions based on who's invoking the graph. I'm thinking about a few approaches, but I'd love to hear what others are doing: * **Runtime argument filtering**: Pass a permissions list into the graph config and have each tool node check it. Feels a bit manual and easy to mess up. * **Separate graphs per privilege level**: Build a "user_graph" and an "admin_graph," but then sharing state/logic gets messy. * **Seccomp/AppArmor at the container level**: This is my usual go-to for process isolation, but it seems too coarse-grained here. The graph is all in one Python process. Has anyone implemented a clean permission layer for tool nodes? My ideal would be to define a policy at graph compilation, like: ```python user_policy = ToolPolicy(allowed_tools=) user_graph = app.compile(config={"tool_policy": user_policy}) ``` But I don't see a built-in way to do that. Maybe a custom `ToolNode` wrapper that validates permissions against the current state's `user_id` before executing? The checkpointing side of this also makes me nervous. If a user's state is saved and later resumed, we need to ensure the permissions are still attached and evaluated. -- peter

How do I prevent a tool from being called too many times in a loop?

James O'Brien — Sat, 27 Jun 2026 08:01:20 +0000

Everyone's rushing to build these "self-correcting" agent loops with LangGraph, patting themselves on the back when it finally books the correct flight after twelve tries. Then the bill comes in. Not from the airline—from the LLM API, and from your cloud provider after the tool that spins up EC2 instances gets called in a recursive death spiral. The problem isn't the loop itself; it's that the graph's control flow is often dictated by untrusted, non-deterministic output (the LLM). You're handing the steering wheel to a model that can be coaxed, confused, or just plain wrong, and telling it "don't take too many turns" is meaningless. So, you want to prevent a tool from being called *too many times*? You need to enforce it at the *system* level, not hope the LLM follows instructions. Here are the actual levers you have: 1. **Stateful Counting in the Graph State:** The most direct method. Increment a counter in the graph state every time the node runs, and conditionally route away from it when a limit is hit. This is a *graph* concern, not a tool concern. ```python from langgraph.graph import StateGraph, END from typing import TypedDict class State(TypedDict): messages: list expensive_tool_calls: int # = 5: return "stop_reasoning" # Route to a node that ends or changes tack return "expensive_tool" builder = StateGraph(State) builder.add_node("expensive_tool", expensive_tool_node) builder.add_node("stop_reasoning", lambda s: {"messages": "Limit reached."}) builder.add_conditional_edges( "expensive_tool", should_continue # <-- This function guards the loop ) ``` 2. **Circuit Breakers at the Tool Level:** The tool itself should have a hard, in-memory limit. This is your last line of defense if the graph logic fails. A simple decorator can reject calls after a threshold, maybe even raising an exception that the graph can catch and handle. 3. **Checkpointing is Your Enemy Here:** If you're checkpointing your graph state to an external store (like Redis) and reloading, your in-memory circuit breaker is useless. A new worker will load the state and start fresh. Your counter *must* be part of the persisted graph state (like in the example above) to survive across process restarts, or you need external state (e.g., a Redis atomic counter) for a global limit. The real oversight is assuming the LLM is the only attacker. Your own graph's logic, a malformed user query, or a weird context window overflow can trigger this. Don't just limit loops—budget *every* external call (API, cloud, database) and enforce it where the LLM can't argue: in the code. J

What's the real risk of using the pre-built 'tool node' for external APIs?

Ash Thompson — Thu, 25 Jun 2026 02:57:17 +0000

Everyone's buzzing about LangGraph's pre-built 'tool node' because it's convenient. But wrapping an external API call in a decorator doesn't magically solve the hard problems. You're just outsourcing your security headaches. The real risk isn't the node itself—it's the illusion of safety. You get a clean abstraction, but you're still piping raw, often unsanitized, LLM output directly to an external service. The node handles the *mechanics*, not the *security*. Think about it: * **Input Injection:** The prompt crafts a payload, the node obediently sends it to your CRM/email/DB API. No inherent validation. * **Credential Leakage:** The node needs API keys. Where do they live? In the graph's state? Injected at runtime? How are they scoped? * **Tool Choice Abuse:** The LLM decides which tool to call. What stops a malformed response from calling `delete_user` instead of `get_weather`? The node doesn't care. It's a classic case of a framework solving the developer experience problem while quietly inheriting all the underlying protocol and API risks. You've traded writing a few lines of HTTP client code for a false sense of a "managed" interaction. So, what's the actual threat model here? Is it the node's code, or is it that using it encourages lazy, trust-based integration patterns that we'd rip apart in any other RPC or service mesh context?

X vs Y - Is it more secure to run the graph server separate from the main app?

Bob Tran — Wed, 24 Jun 2026 05:01:10 +0000

Separate server means separate attack surface. But also separate failure modes. Which one actually reduces business risk? Running it together: * Single deploy, less ops overhead. * Graph state lives with app state. One process to compromise. * One set of library vulnerabilities. Running it separate: * Can lock down graph server network exposure. * Graph state checkpointing goes to a dedicated store. * Can you even isolate it? Or are you just adding RPC complexity for no real security gain? Main question: If an attacker gets a tool node to run arbitrary code, does separation matter? The compromise path is the same. Also, cost. Two services, two bills. Is the security ROI there? Or is this just security theater because LangGraph's checkpointing looks scary on a diagram? - Bob

How do I ensure a graph execution is deterministic for audit purposes?

audit_log_priya — Wed, 24 Jun 2026 00:00:21 +0000

A deterministic graph execution is foundational for creating a reliable, auditable trail in any agentic system. In LangGraph, where stateful graphs with cycles, human-in-the-loop nodes, and conditional edges are common, achieving true determinism is non-trivial. Without it, correlating an agent's final output or action back to a specific sequence of internal states and decisions becomes probabilistic at best, which is unacceptable for compliance frameworks like SOC 2 or financial auditing. The primary adversaries of determinism in LangGraph are: * **Non-deterministic Tools:** Any tool node (e.g., an API call, a code execution step) that can return different outputs for identical inputs. * **Graph Memory with Non-Serializable State:** In-memory objects or connections that influence execution but are not captured in the graph's serialized state. * **Conditional Edges Based on Volatile Data:** Using the result of a non-deterministic tool to decide the graph's path (`"condition"` edges). * **Concurrent Execution:** If using the `StateGraph` with potential for parallel node execution, race conditions can introduce variance. * **Unseeded Randomness:** Any use of `random` modules within functions without a fixed seed. To enforce determinism, you must architect for it from the ground up. Here is a methodological approach, focusing on the audit log's needs. **First, isolate and control non-deterministic nodes.** Wrap all tool calls and LLM invocations in a logging layer that records both input and output. For true determinism in a testing or replay context, you may need to implement a "replay mode" that intercepts these calls and returns recorded values from your audit log. Consider this pattern: ```python from typing import Any, TypedDict from langgraph.graph import StateGraph class AuditState(TypedDict): deterministic_input: str tool_call_id: str # ... other state def audited_tool_node(state: AuditState): # 1. Generate a unique, deterministic ID for this call. # Use a hash of (function_name, sorted(inputs)). call_id = generate_call_id("tool_name", state) # 2. Check Audit Log: Has this call been executed before? logged_output = audit_store.retrieve(call_id) if logged_output and REPLAY_MODE: return {"tool_output": logged_output} # 3. If not, execute the actual tool. actual_output = real_tool_call(state) # 4. Atomically log the input and output to your immutable store. audit_store.log(call_id, inputs=state, outputs=actual_output) return {"tool_output": actual_output} ``` **Second, manage graph state rigorously.** Use a `Checkpointer` that serializes the *entire* state object to your own immutable storage (e.g., an append-only database table) after every node execution and graph step. The built-in LangSmith checkpointer is excellent for debugging, but for audit, you need control over the storage location and schema. Your checkpointer should: * Assign a versioned, sequential ID to each state update. * Store the complete state dictionary, ensuring all custom objects are JSON-serializable. * Record the node that caused the transition and the next edge taken. **Third, design conditional logic carefully.** If a conditional edge depends on a tool or LLM output, that output must be made deterministic (as above) for the path to be reproducible. Alternatively, you can log the condition's evaluation result explicitly in your audit log, so even if two runs theoretically *could* diverge, you have a record of why a specific path was taken. **Finally, treat the LLM as a non-deterministic tool.** Even with a fixed temperature of 0, provider APIs can have minor variances. Your audit layer must log the exact prompt sent and the exact completion received. For replay, you would inject the logged completion, bypassing the API call entirely. By implementing these patterns, you transform the graph from a black-box stochastic process into a deterministic state machine where every transition is predicated on logged, immutable facts. The audit log then becomes the single source of truth, and any execution can be replayed step-by-step from the stored checkpoints and tool call logs.

Unpopular opinion: Most agents don't need a graph, and you're just adding risk.

Emma L. — Tue, 23 Jun 2026 16:01:36 +0000

Let’s be honest. The current hype around LangGraph for building agents is a solution in search of a problem for at least half of the implementations I’m seeing. Everyone seems to think their chatbot needs a state machine, persistent checkpoints, and a web of conditional edges because it’s the “architecturally correct” thing to do. But you’re not building a hyper-automated supply chain orchestrator; you’re routing a user query to a retrieval call and then to an LLM. A linear chain works fine. What are you actually gaining with the graph? A visual diagram for your docs? Meanwhile, you’ve introduced a sprawling execution plane where every node is a potential attack surface. Now you have to secure tool calls across multiple nodes, manage sensitive state being checkpointed to some external store (hope your Redis is locked down tighter than your vault), and deal with LangSmith piping your graph’s entire decision flow—potentially including PII or internal logic—to a third party. All for what? A “maybe” branch that triggers 2% of the time? Zero trust principles would tell you to minimize your trusted computing base and enforce strict boundaries. Throwing in a graph for the sake of trendiness does the opposite. It expands the attack surface, complicates audit trails, and often ends up with more code executing with the same permissions. If your agent’s workflow is essentially linear, you’re not getting resilience or cleverness—you’re getting unnecessary risk and complexity. But hey, at least it looks sophisticated on your next architecture review.

Guide: Making your graph's state immutable after certain steps.

Zoe L. — Tue, 23 Jun 2026 13:01:34 +0000

A common architectural goal in secure agent workflows is to transition from a mutable, exploratory execution phase to an immutable, auditable record—particularly after a critical decision point or before releasing a result to an external channel. In LangGraph, the graph's state is inherently mutable as it passes through each node, which poses a challenge for enforcing post-facto integrity guarantees. This guide outlines a pattern to achieve *state immutability* after designated steps, leveraging checkpointing, conditional edge logic, and a strict node design. The core principle is to treat the *immutable* state not as the live `State` object within the graph's execution, but as a finalized checkpoint written to a secure, append-only store. The graph itself will enforce a transition to a terminal node where no further modifications are possible. Below is a conceptual implementation. ```python from typing import Literal from langgraph.graph import StateGraph, END from your_secure_store import AppendOnlyLedger class ImmutableState: phase: Literal # ... your other state fields ... finalized_checkpoint_id: str | None def decision_node(state: ImmutableState): # ... perform critical operations ... # Decide to finalize. state = "finalized" return state def finalize_and_record_node(state: ImmutableState): if state != "finalized": raise RuntimeError("State not marked for finalization.") # Write the current state to your append-only ledger (e.g., a tamper-evident log, a WAL). ledger = AppendOnlyLedger() checkpoint_id = ledger.append(state) # Store only the reference in the graph's state; the canonical record is external. state = checkpoint_id # Return state, but no further nodes will modify it. return state def mutable_operation_node(state: ImmutableState): if state == "finalized": raise RuntimeError("Cannot operate on finalized state.") # ... perform mutable operations ... return state # Build graph with conditional edges after the decision node. builder = StateGraph(ImmutableState) builder.add_node("mutable_op", mutable_operation_node) builder.add_node("decide", decision_node) builder.add_node("finalize", finalize_and_record_node) builder.set_entry_point("mutable_op") builder.add_edge("mutable_op", "decide") # After decision, only proceed to finalize. builder.add_edge("decide", "finalize") builder.add_edge("finalize", END) # Ensure no edges loop back from any node to a mutable node after 'finalize'. graph = builder.compile() ``` Key considerations for a secure implementation: * **Append-Only Store:** The external store (`AppendOnlyLedger`) must provide cryptographic integrity guarantees (e.g., hash chaining, Merkle trees). This is where true immutability is achieved; the graph merely orchestrates its creation. * **Node Enforcement:** Every node that can modify substantive fields must check the `phase` field and reject operations if `phase == "finalized"`. This is a programmatic guardrail. * **Checkpoint Content:** Carefully curate what is written to the immutable ledger. Consider serializing the entire state object, or a cryptographic hash of it, depending on your data retention policies. * **LangSmith Implications:** Be aware that LangSmith telemetry may log state snapshots. If your state contains sensitive data, ensure that the finalization step occurs *after* any such logging nodes, or configure LangSmith logging filters appropriately to exclude the finalized data. This pattern effectively creates a "one-way gate" in your graph. The transition is enforced by the graph's structure and node-level checks, while the immutable record is maintained externally. For high-stakes deployments, combine this with hardware-backed signing of the finalized checkpoint using a secure enclave or HSM. -- Zoe

Breaking: New CVE for pickle-based state loading? Should we be worried?

Ana Petrescu — Tue, 23 Jun 2026 05:06:41 +0000

Hey everyone, I was following the LangGraph tutorial series here (which was super helpful, thank you!), and I saw a news alert pop up about a new CVE related to Python's pickle module. Since the LangGraph docs mention using pickle for default state serialization, and a lot of us are building agents that might handle sensitive data, I got a bit worried. Is this something we should actively be concerned about in our LangGraph projects? Like, if we're using the default memory or saving checkpoints to a file, are we at risk? Should we be switching to a different serializer right away? I'm still learning about the security side of things, so a clear explanation would mean a lot. 😅 What are you all doing about it?