NYDFS Part 500 vs Reg S-P Incident Notification: Timelines and Evidence After an AI Agent Breach

Part 500 and Reg S-P side by side

The two regimes use different triggers, notify different parties and start their clocks at different moments. A firm subject to both needs to track each separately. This summary is for orientation and is not legal advice.

• Coverage: Part 500: covered entities. Which sections apply depends on the 500.19 exemptions and on whether the entity is a Class A Company under 500.1(e). Reg S-P: broker-dealers, investment companies, SEC-registered investment advisers, funding portals and transfer agents.
• Triggering event: Part 500: a cybersecurity incident that has occurred at the covered entity, its affiliates or a third-party service provider. Reg S-P: unauthorized access to or use of sensitive customer information, where access or use has occurred or is reasonably likely to have occurred. The incident response program itself covers incidents involving any customer information.
• Who is notified: Part 500: the superintendent, electronically, in the form on the DFS website. Reg S-P: affected individuals, by a clear and conspicuous notice delivered by a means designed to ensure each person can reasonably be expected to receive it.
• Deadline and clock start: Part 500: as promptly as possible and no later than 72 hours after the entity determines an incident has occurred. Reg S-P: as soon as reasonably practicable and no later than 30 days after the institution becomes aware. The adopting release describes limited exceptions.
• Third parties: Part 500: incidents at third-party service providers fall within the notice duty. Reg S-P: policies must be reasonably designed to ensure service providers notify the institution as soon as possible and no later than 72 hours after becoming aware of a breach affecting a customer information system they maintain.
• Records: Part 500: records and documentation supporting the compliance certification or acknowledgment, including remediation plans and timelines, kept five years for examination on request. Reg S-P: written records documenting compliance with the amended rules.

Where an AI agent incident touches each regime

Neither regime defines an AI agent, so agent behavior has to be mapped onto each regime's existing trigger concepts. That mapping is a judgment call and counsel should validate it. Three behaviors illustrate the problem: an unauthorized tool call, an over-broad data retrieval, and an action induced by prompt injection.

Under Part 500, the question is whether the behavior amounts to a cybersecurity incident that has occurred at the entity, an affiliate or a third-party service provider. An agent running in the firm's own environment is the simpler case. An agent inside an AI-enabled vendor's service brings the third-party provision into play. NYDFS's industry letter on AI-related cybersecurity risk says incident response plans should be reasonably designed to address all types of cybersecurity events, including those relating to AI, and that covered entities should require third-party providers to give timely notice, including of AI-related threats.

Under Reg S-P, the distinction between customer information and sensitive customer information matters. An over-broad retrieval may fall within the incident response program because customer information was involved, yet only trigger individual notice if sensitive customer information was accessed or used without authorization. Answering that requires knowing which data classes the agent actually touched, for which customers. Without that record, a firm cannot separate an internal handling event from a notifiable one.

Two clocks, one scoping problem

Part 500's 72 hours runs from the entity's determination that an incident has occurred. Reg S-P's 30 days runs from the institution's awareness that unauthorized access or use has occurred or is reasonably likely to have occurred. The Reg S-P 72-hour provision is a different obligation: it applies to service providers notifying the institution, not to notifying a regulator.

Because both clocks start on a firm's own knowledge, scoping evidence affects when each starts as well as who must be told. A practical approach is to run two clocks per incident, record the timestamp of each determination, and record who made it. Document ownership of the notification decision across compliance, security and legal before an incident, since a firm subject to both regimes will otherwise improvise under time pressure.

Part 500 also lets the superintendent request further information about an incident, which the entity must provide promptly. Pre-defining an evidence package makes that request manageable: policy in force, actions taken, data touched and escalations. Records of agent incidents should also feed the annual compliance notification due April 15, which depends on retained supporting documentation.

Which evidence has to be captured at runtime

No rule text lists the artifacts an examiner expects for an AI agent incident, so what follows is engineering judgment rather than a regulatory requirement. Some artifacts can be rebuilt after the fact from application logs and interviews. Others are far more reliable when captured at the moment of execution.

The second group includes the policy version in force when an action occurred, the decision made on each tool call (allowed, redacted, blocked or escalated), the data class and identity involved, and the human approval with timestamp and approver. Reconstructing these later usually means inferring what the policy must have been, which is a weak position when an examiner asks what the agent was permitted to do as distinct from what it did.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit, or escalate for human approval. Enforcement happens at runtime, not after the fact, and it produces audit-ready evidence mapped to NYDFS, among other frameworks. Scope is individual interactions and tool calls, so reconstructing a multi-step workflow still needs other records. Deployment is self-managed in the customer's cloud, with configurable retention and data residency. Trussed is not a notification or incident-response tool and does not decide whether an incident occurred or whether notice is required. Its relevance is the evidence base those decisions rest on, which is also what examiner scrutiny and model risk management reviews tend to ask for.