Making LangGraph agents ready for NYDFS Part 500: tool-call audit trails

What Part 500 asks of an agent audit trail

Start with the text, not the framework. Under 23 NYCRR 500.6, each covered entity must securely maintain systems that, to the extent applicable and based on its risk assessment, include audit trails designed to detect and respond to cybersecurity events with a reasonable likelihood of materially harming any material part of the entity's normal operations. As of November 2026, that is the current in-force text.

Part 500 does not prescribe a tool-call schema. DFS's industry letter on AI cybersecurity risk states that it adds no new requirements and explains how covered entities should apply the existing Part 500 framework to AI risk. The practical task is therefore mapping: show that an agent calling a database, an API or an MCP server falls inside controls you already operate.

Two other expectations bear directly on agents. The DFS checklist calls for limiting and reviewing user access privileges, including those of third-party service providers, at least annually, and for assessing the continued adequacy of third-party providers' cybersecurity practices. A tool or MCP server operated by an outside party can fall into that scope, subject to your own scoping. Whether agent identities count as users for the access review is an interpretation to settle with your compliance team. Finally, the annual certification of material compliance, or acknowledgment of noncompliance, depends on holding evidence. The quality of the audit trail is what makes that submission defensible.

Where LangGraph's native constructs fall short as evidence

LangGraph's nodes, tool execution, checkpointers and interrupts are execution features. Checkpointers persist graph state so a run can resume. Interrupts pause a graph so a person can supply input. These serve reliability and control flow. They were not designed to answer an examiner's question about what an agent was permitted to do and what it did.

Test each construct against the same questions, using the version you run. Does the record include the policy decision, or only the tool call? Does it show the permitted action as well as the actual one? Does it capture the approver's identity and the threshold that triggered review, or only that the graph resumed? Is it written outside the agent process, or can application code modify or delete it? Does it cover calls made to MCP servers from inside a tool, and calls that were blocked before they ran?

Graph state snapshots are organized around what the graph needs to continue, not around the fields above. Application logs depend on each developer remembering to emit them and are usually free text. Neither is typically a protected, structured record. A trail built from by-products of execution can show that something happened. It is weak at showing that a control was applied before it happened.

Enforcing policy in the execution path

There are two broad patterns. In-application instrumentation wraps tool calls inside the LangGraph code, for example in a tool node or wrapper function. An external enforcement layer sits between the agent and its tools or MCP servers and evaluates every call before it executes.

Instrumentation is quick to start and has full context on graph state. Its limits are structural: it shares a trust boundary with the agent, coverage depends on every graph and tool being wrapped correctly, and policy changes mean code changes. An external layer applies one policy uniformly across agents and tools and can write evidence to a separate store. The tradeoffs are another component to operate, added latency on each call, and the work of authoring and maintaining policy.

Whichever pattern you choose, the four decision types matter. Allow records that the call met policy. Redact releases the call or result with nonpublic information removed, and the record should show that redaction occurred. Block stops the call and records why. Escalate holds the call for human approval, and the record should capture the risk threshold that fired, the approver and the outcome. Short-lived, revocable authorization fits this model, because each approval then applies to a specific call.

Trussed is one in-the-path approach. It enforces policy at runtime, not after the fact, across agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval. The audit-ready evidence it produces is generated by that enforcement and mapped to frameworks including NYDFS. Its scope is individual interactions and tool calls. Insurance is the regulated financial sector where it is deepest.

Retention, tamper resistance and data residency

Evidence is only useful if it survives and can be trusted. NIST guidance says audit information and tools should be protected from unauthorized access, modification and deletion, and describes off-loading records to a secondary system in a way that preserves integrity and confidentiality. It also notes that write-once, hardware-enforced media applies to initial audit trail generation and to backups. Use that as a reference point when evaluating how a store resists tampering. The practical test is whether the team operating the agent can alter its own record.

Retention is an organization-defined period in NIST controls, not a fixed figure. Set it explicitly from your own policy and risk assessment, and confirm that the evidence store can be configured to it rather than to a vendor default.

Data residency deserves equal attention. Tool-call arguments and results can contain nonpublic information, so the evidence store holds sensitive data itself and needs the same access controls as the systems it describes. Decide where records may live and who can read them. Trussed supports self-managed deployment in the customer cloud with configurable retention and data residency, which keeps evidence within boundaries the entity sets.