To answer what data does LangGraph store in memory state and checkpoints: it persists the agent runtime record, including conversation history, tool call inputs and outputs, application scratch fields, thread context, and serialized state blobs written to a checkpoint backend. For enterprises, the main risk is that sensitive data lands in durable storage before anyone inspects it. Security teams need inline control at the interaction and tool-call layer. Aurascape classifies and governs that data in real time before state is stored.

Last updated: September 2026.

The thesis is simple: LangGraph’s memory and checkpoint architecture accumulates everything an agent writes into state across every node, so governance has to act inline at the interaction layer before that record is written, not after it lands in durable storage. This guide walks through what each part of the persistence model holds, where the exposure sits, and how to apply controls across identity, data, intentions, conversations, tools, actions, and audit evidence. LangGraph agents sit in the human-to-agent and agent-to-agent phases of enterprise AI, where employees delegate work to reasoning systems that hold tool permissions across sessions. That makes runtime interaction governance matter as much as deployment configuration.

What LangGraph state and checkpoints store

LangGraph state means the structured, shared object that every node in an agent graph reads from and writes to as execution proceeds. Developers define it as a typed schema, typically a Python TypedDict or a Pydantic model, so the fields are known in advance. A checkpoint is a serialized snapshot of that state at one super-step, plus the identifiers needed to resume. LangGraph’s persistence documentation describes checkpointed state as built to survive process restarts and support long-running workflows (LangGraph Persistence Concepts, 2026). The table below maps each storage layer to what it holds and where it lives.

State is not ephemeral scratch space. Whatever a field can hold, the checkpoint will hold. A message list that grows with every turn becomes a durable transcript. When the graph writes tool arguments or tool results into message state, those values join the checkpointed record. Two properties drive the risk. First, the serialized blob crosses node boundaries: a value written at one node is persisted and read by a later node before any content inspection applies. Second, raw checkpoint metadata shows which node ran and when, but it does not classify the data, evaluate the tool permission, or record a policy decision. LangGraph’s memory documentation lists the exact record fields against its checkpoint schema, so read the current schema before hard-coding field assumptions (LangGraph Memory Concepts, 2026).

Does LangGraph store secrets, source code, or sensitive data?

LangGraph stores whatever the application writes into state. Paste source code into a turn, or let a tool return a secret and the graph write it into state, and that content becomes part of the checkpoint unless an inline control filters it first. Message accumulation is the primary surface: every user turn appended to the message list joins the thread record, so PII, proprietary code, and authentication tokens in that turn persist with it.

Tool activity is the second surface. Query a customer database and write the result to state, and those rows serialize into the checkpoint. A chained sequence that reads sensitive records through one tool and writes them out through another leaves both payloads in the blob once the graph stores them. Coding-assistant workflows built on LangGraph route source code and environment variables through state, a direct exposure path given how heavily developers now lean on AI coding tools (Stack Overflow, 2025). For related coverage, see our guides on Cursor source-code retention, Claude Code with company source code, and whether Roo Code can expose secrets.

OWASP ranks Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), and Excessive Agency (LLM06) among the top risks for AI model applications (OWASP, 2025). All three map onto a persistence layer that stores tool outputs and grants agents persistent tool access across sessions. The Cloud Security Alliance found that 65% of organizations had agent-related incidents and 61% reported data exposure (Cloud Security Alliance, 2026). A model that captures tool inputs and results across memory tiers is exactly where that exposure accumulates.

Short-term checkpoints, long-term memory, and LangSmith traces

LangGraph separates two kinds of memory, and the distinction sets the control boundary. Short-term memory is thread-scoped: a checkpointer persists the state of one conversation so it can pause and resume. Long-term memory uses the Store API, which holds data across threads as JSON documents scoped by namespace. A namespace for saved preferences can hold user-scoped facts, behavioral history, and other sensitive data whenever the application writes those fields into long-term memory (LangGraph Memory Concepts, 2026).

For compliance, the split matters. Thread-scoped data has a natural boundary and a natural deletion point. Cross-thread Store API memory has neither, so a subject-access or deletion request has to reach into named namespaces that may not index by user in any obvious way. Document namespace design, user scoping, tenant scoping, and deletion lookup procedures before a production deployment, not after a regulator asks. Confirm whether tenant isolation runs at the namespace or query level, or only by application convention, because that choice decides whether one tenant’s data can ever surface in another’s context window.

LangSmith, LangChain’s observability platform, adds a third data layer that developers often underestimate. Every traced run captures inputs and outputs at each node as a span: prompt content sent to the model, model responses, tool call arguments, tool outputs, and feedback annotations (LangSmith Tracing Concepts, 2026). Background and asynchronous runs persist their run inputs, streaming outputs, and error traces in the same observability layer, so a production deployment accumulates all of it in the LangSmith workspace. Workspace-level settings govern retention, so teams evaluating LangSmith for sensitive workloads should confirm them against the current retention documentation (LangSmith Data Retention, 2026). The practical point: a team can delete checkpoints on the LangGraph side and still retain full run inputs, model responses, and tool payloads in LangSmith traces, because trace retention is configured separately from the checkpointer.

Checkpointer backends and their persistence trade-offs

Where the checkpoint lands depends on the checkpointer you configure, and each option carries different durability and exposure characteristics. MemorySaver keeps state in process memory only. It is volatile: state disappears when the process exits, which suits development and testing where persistence is unnecessary and sensitive data should not touch disk. SqliteSaver writes checkpoints to a local SQLite database file, so state survives restarts and anyone with filesystem access to that file can read the serialized blobs. PostgresSaver writes to a shared Postgres database that multiple services can reach, which shifts the control to network exposure and database access policy and makes query-level tenant isolation mandatory in multi-tenant deployments.

Retention follows the backend and the deletion policy you configure. Checkpoints persist until records are deleted, so without a defined retention window checkpoint tables grow, which is both a storage-cost problem and a data-minimization compliance problem. Treat the following as standard persistence-layer review items rather than confirmed LangGraph defects. SQL injection belongs on the review checklist for any SQL-backed checkpointer whose application code builds checkpoint queries without parameterization. Serializer choice, schema versioning, and migration tests matter because old checkpoint blobs may not resume cleanly after a breaking state-schema change. None of these is a claimed LangGraph vulnerability; they are the questions a security review should ask of any durable agent-state store. OWASP’s LLM06 (Excessive Agency) ties them together: durable state plus persistent tool access widens what a compromised or misdirected agent can reach (OWASP, 2025).

Production risks: state growth, schema drift, and human review

Unbounded message accumulation is the most common production failure mode. Conversation history grows with every turn, and without pruning or summarization the context window fills, inference cost rises, and checkpoint size becomes a storage concern. LangGraph ships utilities that prune older messages and summarize accumulated context before it overflows (LangGraph Manage Conversation History, 2026). The trade-off is fidelity: summarization decides what to keep and what to compress, and if it compresses the wrong exchange the audit record for that turn loses its original content. Test pruning and summarization against compliance requirements before relying on them in regulated environments.

Schema drift is the second operational failure mode. Change a state TypedDict or Pydantic schema after checkpoints exist, and older blobs may not deserialize cleanly against the new schema. Fields added or removed without a migration plan cause silent data loss or runtime errors on resume. Version the schema explicitly, write migration scripts before any breaking change, and test resumption from old checkpoints in staging before production.

LangGraph’s human-in-the-loop model pauses at a checkpoint so a reviewer inspects and edits state before approving the next step (LangGraph Human-in-the-Loop Concepts, 2026). It is a real control, worth using for high-risk operations such as write and delete tool calls. Automated inline classification of every field, applied before the checkpoint is written, handles the volume manual review cannot reach. Gartner predicted that over 40% of agentic AI projects will be cancelled by end of 2027 due to escalating costs, unclear business value, or inadequate risk controls (Gartner, 2025). Weak persistence-layer controls, specifically the absence of data classification before state is stored, are one concrete reason production agent deployments stall.

Governing what LangGraph stores at the interaction layer

In a checkpoint-first architecture, governance arrives after the data is already durable. Aurascape moves the control point forward to the interaction itself. It decodes the bidirectional exchange between an agent, its model, and its tools, classifies the content in real time with 600+ real-time data classifiers (Aurascape, 2026), and applies policy before a payload serializes into state. When a tool result carries customer records, real-time data classification redacts or blocks them before they enter the blob rather than logging them after. Policy applies inline across the full exchange: allow, coach, warn, block, or redact based on content, account type, entitlement, and tool-call context.

Aurascape discovers and secures local AI agents and their interactions, and adds a Zero-Bypass MCP Gateway that marks approved tool calls and blocks unapproved ones on governed execution paths (Aurascape, 2026). Model Context Protocol (MCP) is one common tool-execution pattern, not the whole agent access-control problem. In a governed workflow, an unapproved tool call is blocked on the agent-to-tool execution path before the action runs. Discovery matters here because checkpoint-level logging only sees agents you already know about; proactive discovery of AI apps, accounts, and agents finds the unregistered sessions that never routed through your logging in the first place (Aurascape, 2026).

Checkpoint metadata helps reconstruct execution order, but it is not an interaction record that ties a tool call to data category, policy action, and reviewer evidence. Aurascape creates interaction records for audit and effectiveness, governed by role-based access control for privacy, which is what compliance frameworks actually ask for. The World Economic Forum reported that assessing AI-tool security before deployment has become a mainstream practice, roughly doubling year over year (World Economic Forum, 2026). Evaluating what LangGraph stores and adding a control layer that acts before the store is written is that assessment done concretely.

LangGraph persistence vs. inline interaction governance

The side-by-side comparison below sets the common LangGraph persistence choices against inline interaction governance. LangGraph provides durable, resumable state; it is not an inline security product. Security teams still need a separate control point that classifies sensitive data, evaluates tool actions, and records the policy decision before state is stored. The recommended evaluation sequence follows the table.

This sequence applies to AI platform engineers, developers, and AppSec teams preparing a LangGraph agent for production:

1. Map every state field in your TypedDict or Pydantic schema to a data classification and mark which fields can carry PII, secrets, source code, or regulated data.
2. Choose a checkpointer backend, document its access controls, encryption at rest, and network exposure, and set a retention window and deletion procedure for each thread and each Store API namespace.
3. Confirm that tenant isolation runs at the query or namespace level, not only by application convention, and validate that deletion requests for cross-thread Store API memory reach all affected namespaces.
4. Version your state schema explicitly and write migration scripts before any breaking change; test resumption from old checkpoints in staging before deploying to production.
5. Apply inline classification and policy on tool call arguments and results before they serialize, with defined allow, coach, warn, block, and redact outcomes for each data category.
6. Audit LangSmith trace retention settings separately from checkpointer retention, and confirm sensitive run inputs, model responses, and tool outputs fall under the same deletion procedures.
7. Capture interaction-level audit evidence tied to each tool call rather than node-level checkpoint metadata, queryable by user, tool, data category, and policy action.

Frequently asked questions

What data does LangGraph store in memory state and checkpoints?

It stores the agent runtime record written into state: conversation history, tool arguments and results, planner outputs, and custom schema fields, serialized into a checkpoint blob with thread and checkpoint identifiers and a timestamp. Long-term memory adds user-scoped JSON documents that persist across threads.

Does LangGraph store secrets or source code?

Only if the graph writes them into state. A pasted secret or a tool result containing source code becomes part of the checkpoint unless an inline control filters it first. Enforce secret and source-code hygiene before data reaches state.

What does LangSmith store in traces and background runs?

Traces capture per-node inputs and outputs as spans: prompt content, model responses, tool arguments and outputs, and feedback. Background runs persist run inputs, streaming outputs, and error traces. Workspace settings set trace retention, separately from checkpoint retention.

How long does LangGraph retain checkpoint data?

It depends on the backend and your deletion policy. MemorySaver loses state on process exit; SqliteSaver and PostgresSaver persist until records are deleted. Set an explicit retention window per backend.

How are threads and tenants isolated?

Checkpoints are thread-keyed, giving session-level isolation. The Store API crosses that boundary, scoping long-term memory by namespace, so tenant isolation there depends on namespace design and query-level enforcement.

What are the main LangGraph security review items in production?

Sensitive data entering checkpoints without inspection, query parameterization for SQL-backed checkpointers, schema-migration testing so old blobs resume cleanly, unbounded state growth, and broad tool permissions that let an authenticated agent issue arbitrary tool calls within a thread. These are standard persistence-layer review items, not confirmed defects.

Can I delete data for a subject-access request?

Thread-scoped checkpoint deletion is straightforward if the backend supports record-level deletes. Store API deletion has to reach every namespace holding that user’s data, and LangSmith trace deletion follows a separate workspace procedure. Document all three paths.

How does Aurascape help with LangGraph data exposure?

It classifies and governs the interaction before serialization, applying allow, coach, warn, block, or redact; marks approved tool calls and blocks unapproved ones on governed paths; discovers unregistered agents; and records audit evidence tying each tool call to a data category and policy decision.

Aurascape governs LangGraph risk before data reaches a checkpoint or LangSmith trace. It classifies and controls the interaction, the tool call, and the agent action in real time, so sensitive content is caught and audited across identity, data, intentions, conversations, tools, actions, and evidence rather than logged after the fact.

See how Aurascape governs agentic AI across LangGraph state, memory, and traces →