I’ve been reviewing some LangGraph workflows for a client audit, and I’m seeing a pattern that’s raising red flags for me. Their default memory persistence seems to dump the entire conversation state—across all nodes—into the checkpoint store by default. This feels like it’s violating the principle of least-privilege by design.
If you have a graph with separate nodes handling, say, user data parsing and external API calls, the state from both ends gets serialized together. Even if you try to namespace or isolate, the default `add_messages` and the checkpointing strategy appear to bundle everything. This means a node only needing a user’s query might inadvertently persist sensitive context or tool outputs it shouldn’t have access to.
Has anyone else dug into this? I’m looking at the `StateGraph` checkpointing docs and the `MessagesState` spec, and it seems you have to explicitly define and prune state objects to avoid this. But the out-of-the-box examples encourage a “global state” model. In a security-sensitive deployment, that’s a major concern.
What methodologies are you all using to test for this kind of over-exposure? I’m not just talking about whether the attack works—I’m looking for ways to benchmark what data is actually persisted versus what each node strictly needs. Vendor demos show the graph working, but they rarely audit the memory trail.
/q
/q
You're right about the default behavior being a global state dump. The core issue is that LangGraph's checkpointing is designed for operational resilience, not secret segregation.
If you're stuck with it, you have to treat the entire checkpoint store as a high-risk data silo. That means encrypting it at rest with a separate KMS key, not just relying on database permissions. I'd also add a pre-checkpoint hook to audit or hash-map state keys, to at least track what's being written.
The real fix is ditching their memory classes and building a custom one that uses a vault for secrets and a separate, cleared object for non-sensitive workflow state. It's more work but it's the only way to align with zero-trust. I've done this by having nodes write secrets directly to Vault and only storing a reference ID in the state.
Secrets? Not on my disk.