LangGraph Checkpointer Data as Audit Evidence: What It Captures and What Examiners Still Need

What a checkpointer is for

A LangGraph checkpointer persists the state of a graph as it executes. Savers such as the in-memory, SQLite and Postgres options store snapshots per step, typically including the values held in state channels, metadata about the step, and writes that are still pending. Snapshots are grouped by thread, so a run can be resumed, inspected at an earlier point, or paused for a human to review.

That design purpose matters for how you describe the data. The checkpointer answers the question: what was the state of this agent at this step? It was not designed to answer: what was this agent permitted to do, and what did the control layer decide? Treating the first as the second is where teams over-claim.

The checkpoint store does have incidental evidentiary value. If a tool's input and output are written into state, a snapshot can corroborate what the agent saw and produced. It is useful supporting material in an examination. It is not a purpose-built audit record, and the architecture should say so plainly.

What examiners and auditors ask for

NIST describes logs as useful for auditing and forensic analysis and lists auditors among the users of log data. Its draft Cybersecurity Framework Profile for AI states that AI audits are designed to demonstrate compliance with legal, regulatory and contractual requirements while addressing AI-specific needs such as explainability. NIST AI RMF text also advises using real-time auditing tools where they can be shown to help track and validate the lineage and authenticity of AI-generated data. The EU Commission describes the AI Act as the first-ever legal framework on AI, and as of November 2026 teams should confirm which of its record-keeping provisions apply to their systems.

Across these expectations, the common thread is a record that can be relied on by someone who did not build the system. That reader will ask what rule applied, what happened as a result, who was involved, and whether the record could have been altered. Snapshot data answers only part of that.

Mapping examiner questions to checkpoint data

The table below compares common examiner questions with what a typical checkpoint store can support. Verify each row against your own saver configuration and what your application writes into state.

• What did the agent do at this step?: Largely supported. State values and thread history show inputs, outputs and step order, to the extent the application writes them to state.
• Which policy applied to this tool call?: Not recorded by default. A snapshot has no policy version or rule identifier unless the application adds one, and a self-reported field is weak evidence.
• Was the policy enforced, and what was the outcome?: Not captured as an outcome. State may show that a call ran, but not that an allow, redact, block or escalate decision was made and applied.
• Who approved the escalation?: Partial at best. A human-in-the-loop pause and resume can appear in state, but verified approver identity and approval time need their own record.
• Is the record tamper-resistant?: Depends on the store, not the checkpointer. A database that administrators or the application can update gives no integrity assurance by itself.
• Is it retained and held in the right location?: Determined by how you operate the store. Pruning, overwrites and storage region are operational choices, not evidence controls.

Integrity, retention, access and residency

Even where checkpoint content is relevant, the storage properties decide whether it is defensible. Operational stores are optimized for read and write speed and for resuming work. They are usually writable by the application, may be compacted or cleaned to control size, and sit in whatever region the application database sits in. None of that is wrong for state persistence. All of it is a problem for evidence.

Integrity means you can show a record was not altered after the fact. That usually requires write-once or append-only storage, hashing or signing, and separation between the system that produces the record and the people who administer the application. Retention means a defined schedule tied to your regulatory obligations, with deletion that is deliberate and documented. Access control means you know who can read, and who can change, records that may contain sensitive prompts and outputs. Residency means the evidence is stored where your obligations require.

There is also a security reason to separate the two. OWASP describes agent memory as an attack surface that can become part of the model's control plane. Persisted agent state belongs in your threat model, and a store that an attacker could influence is a poor foundation for evidence.

Evaluating the combined design

Keep the two layers distinct, in line with NIST's distinction between monitoring and auditing. The checkpointer supports operation. The evidence record supports review. Linking them by thread and checkpoint identifiers lets an examiner move from a decision to the state around it.

• Inventory exactly what your configured saver persists, and what your application writes into state.
• List the examiner questions you must answer and mark each as answered, partial or unanswered.
• Generate evidence where the decision is made, not from application self-reports after the fact.
• Define integrity, retention, access and residency for the evidence store separately from the checkpoint store.
• Assign an owner for evidence, distinct from the owner of agent runtime operations.
• Test by sampling a tool call and reconstructing policy, outcome and approver without the engineering team.

Where runtime policy enforcement fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions that include allow, redact, block, rate limit and escalate for human approval. Enforcement is applied at runtime, not reviewed after the fact, and its scope is individual interactions and tool calls. Because the decision is made in the path, the audit-ready evidence is generated by the enforcement itself: the policy applied, the action taken and, for escalations, the human approval.

This maps to the gaps above. Checkpointer data continues to hold agent state for resumption and replay, and the enforcement evidence supplies the policy decision, the outcome and the approver for each call. Trussed evidence is mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It is deployed self-managed in the customer cloud, with configurable retention and data residency, so the evidence store can follow your own schedule and location requirements.

Trussed has run continuously in production in a regulated enterprise for more than 18 months, with 99.95% uptime on live production traffic and more than 30 GB of audit evidence generated per day. Trussed does not trace complete agentic workflows end to end. It provides evidence for the individual interactions and tool calls it enforces, alongside the state your checkpointer already holds.