PHI Redaction in LangGraph State and Checkpoints

Checkpoints are a persistence boundary

A checkpointer saves graph state so that a run can resume, pause for human input, or be replayed. The practical consequence is simple: whatever is in state when a checkpoint is written is stored. If that includes PHI, the checkpoint database holds PHI.

NIST describes data at rest as information stored on a secondary storage device. A checkpoint database fits that description in practice, and it deserves the same scrutiny as any other PHI repository. In many deployments it was provisioned as application plumbing. Its access controls, retention settings, backup behavior, and deletion procedures were never scoped for PHI. Persisted state therefore extends the PHI footprint and complicates minimum-necessary handling, retention, and disposal.

This is why placement matters. Redacting only the prompt sent to a model leaves the original text in state. Scrubbing after storage means PHI has already been persisted, and possibly copied into backups and replay stores. Redaction has to happen before the write.

Redaction placement options and trade-offs

No single placement covers every path. The options below differ in what they protect and what they cost in fidelity. Most healthcare deployments combine more than one.

• Pre-model: Redacts prompts before the model call. Limits PHI exposure to the model, but does not by itself clean state or checkpoints.
• Pre-tool and post-tool: Applies policy to tool arguments and results. Covers a major route by which PHI enters state, and allows block decisions on tool calls that should not run.
• State reducer or write path: Redacts values as nodes merge them into state. Keeps PHI out of every downstream checkpoint, but requires that every state field passes through it.
• Checkpointer serialization: Redacts or rejects records as they are serialized for storage. A strong backstop, but redaction here can break resume if later nodes expect the original values.

Irreversible versus reversible redaction

NIST defines redaction as the removal of information for legal or security purposes. It is a suppression technique, so removed data cannot be recovered from the checkpoint. That is the property that makes it effective for data minimization, and it is also what limits replay fidelity and resumption. A node that needs the original value after a resume will not find it.

A reversible alternative replaces PHI with tokens in state and keeps the mapping in a separate, tightly controlled store. Resume and replay work with tokens, but the mapping store is now a PHI repository with its own access, retention, and deletion obligations. Choose based on whether any downstream step truly needs the original value.

For human-in-the-loop interrupts, consider passing opaque references instead of content, and have the review interface fetch PHI from the system of record at review time. Do not use identifiers that are themselves PHI as references.

Two cautions from NIST apply. Redaction alone does not provide formal privacy guarantees, so pair it with access, retention, and storage controls. Selective redaction can also reduce accuracy and introduce bias, so test whether redacted state degrades downstream node and tool behavior before release.

Audit evidence and enforcement in the execution path

Audit controls under 164.312(b) are about being able to show what happened. For persisted agent state, that means showing an auditor what was stored, what was redacted, and why. Useful evidence, proposed here as a design choice, includes the policy version in force, the decision taken (allow, redact, or block), the category of data affected, the interaction or tool call involved, a timestamp, and the retention applied to the evidence itself. Compliance partners should confirm the final evidence set against the current text of the Security Rule and the general rules on uses and disclosures in 45 CFR 164.502, as of November 2026.

The difference between runtime enforcement and log scrubbing is timing. Enforcement in the execution path decides before data is written, so PHI never reaches the checkpoint and the decision record is produced at the moment of the decision. Scrubbing after the fact leaves a window in which PHI is stored, and the evidence describes cleanup instead of prevention.

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, with allow, redact, block, rate limit, and escalate for human approval. Its scope is individual interactions and tool calls. It generates audit-ready evidence mapped to HIPAA, and it runs in production with healthcare and pharma organizations. It deploys self-managed in the customer cloud with configurable retention and data residency. State reducers and checkpointer serialization remain controls your team implements in the graph itself.