NYDFS Part 500 AI Agent Log Retention: What the Regulation States and What You Must Interpret

What Part 500 states explicitly

Three provisions bear most directly on AI agent records, and each is narrower than it first appears.

Section 500.6 is titled "Audit trail." Under 500.6(a)(2), covered entities must securely maintain systems that, to the extent applicable and based on their risk assessment, include audit trails designed to detect and respond to cybersecurity events that have a reasonable likelihood of materially harming any material part of normal operations. Section 500.6(a)(1) separately requires systems designed to reconstruct material financial transactions sufficient to support normal operations and obligations. Both are qualified by applicability, risk assessment and materiality. Neither names AI prompts or tool calls as a record type.

Section 500.13(b) requires policies and procedures for periodic secure disposal of nonpublic information that is no longer necessary for business operations or other legitimate business purposes. The exceptions are information that law or regulation requires to be retained, and cases where targeted disposal is not reasonably feasible because of how the information is maintained.

Finally, covered entities must maintain, for examination on request, the records, schedules and documentation supporting the annual certification or acknowledgment for five years. That includes identified areas needing material improvement and remediation plans and timelines. Which sections apply to a given entity also depends on its 500.19 exemption status and whether it is a Class A company under 500.1(e).

Where the regulation requires interpretation

Part 500 was not written for agentic AI, and the NYDFS AI materials do not close the gap. The October 2024 industry letter on AI cybersecurity risks stresses access privilege review: at least annually, each authorized user should have access only to the nonpublic information needed for the job, with unnecessary access removed and access terminated promptly after departures. The May 21, 2026 advisory on frontier AI models urges entities to review their programs for full Part 500 compliance. The companion guidance on measures for a heightened threat environment says its recommendations may go beyond the explicit minimum controls without altering Part 500, and lists enhanced monitoring and validation of expected behavior of third-party code, applications, permissions and practices. None of these sets or implies a retention period for prompt or tool-call records.

That leaves three open questions your policy must answer. First, which agent interactions fall within the audit trail scope after your risk assessment. Second, whether prompt and response content contains nonpublic information and so falls under 500.13(b). Third, which records support the annual certification and therefore carry the five-year period. The OCC has noted, in a different regulator's framework, that prompts, outputs and logs may warrant access controls and risk-based retention, and that agent identities may be governed like privileged users. The language is permissive and it is not NYDFS guidance, so treat it as comparative context rather than a requirement.

Handling sensitive content and the disposal tension

Prompts and outputs can contain nonpublic information, and a log store that holds them becomes a repository of sensitive data in its own right. Whether a given prompt meets the Part 500 definition of nonpublic information depends on its content and on the definition in 500.1(k)(2)-(3). Where it does, 500.13(b) applies to the log store as it does to source systems.

This creates a real tension. Disposal logic pushes toward deleting content once it is no longer needed. Audit and examination needs push toward keeping it. Resolve the tension in the policy rather than leaving it to default. Use the "required by law or regulation" exception only where you have identified a specific requirement. Otherwise, separate the retention of decision metadata (identity, tool, policy decision, approval event) from the retention of raw content. Metadata is usually what demonstrates control and can be kept longer. Raw content can be redacted before storage, restricted to a small set of roles, and disposed of on a shorter schedule.

Apply least-privilege access to the retained records themselves, and include the log store in the periodic access reviews the October 2024 letter describes. Record redaction decisions as events, so you can show what was removed and why.

Building a defensible retention policy

Start by confirming your 500.19 exemption or Class A status, then map each AI interaction record type to a Part 500 hook: audit trail under 500.6(a)(2), transaction reconstruction under 500.6(a)(1) where agents touch material financial transactions, disposal under 500.13(b), and certification support under the five-year requirement. In the policy, mark each mapping as explicit or interpretive.

Set retention by record class and risk assessment, and write down the rationale for each period. Separate what is required from what is recommended, since the 2026 DFS guidance does not alter Part 500. Name an owner and a review cadence, because the interpretation will need revisiting as guidance develops.

Expect examiners to ask for evidence rather than assertions. Likely requests include the retention policy and its rationale, a sample of records showing identity, tool, parameters and policy decision for a specific agent action, proof that disposal runs as written, the access list for the log store, and the records supporting the annual certification. Frame the program around that evidence, in the way model risk management reviews do, rather than around raw log volume. Retention is a property of evidence produced when policy is enforced, not of passive storage.

Evaluating runtime enforcement for retention

Records are only as useful as the control that produced them. If policy is enforced in the execution path, each allow, redact, block or escalate decision generates a record at the moment it happens, instead of being reconstructed from application logs later. When evaluating any runtime enforcement product, verify five things: retention configurable per record class and per field with automated disposal; where records are stored and who controls the storage and keys; how sensitive prompt content is redacted before storage; whether each record captures identity, tool, parameters, decision and approval event; and whether the retention configuration and records export in a durable, examiner-readable form.

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls, and generates audit-ready evidence mapped to NYDFS among other frameworks. It supports self-managed deployment in the customer cloud, with configurable retention and data residency, so storage stays under the regulated enterprise's control. It does not provide end-to-end tracing of agentic workflows. Mapping any product's capabilities to Part 500 remains your interpretation, and a vendor should be able to show which capabilities correspond to which provisions and where your judgment applies.