Is an AI Agent Incident a Reportable Cybersecurity Event Under NYDFS Part 500?

What the regulation says, and what it does not say about agents

Part 500 defines a cybersecurity event as any act or attempt, successful or unsuccessful, to gain unauthorized access to, disrupt or misuse an information system or information stored on such a system. Because unsuccessful attempts are included, the event definition is broad.

A cybersecurity incident is narrower. It is a cybersecurity event that has occurred at the covered entity, its affiliates or a third-party service provider and that meets the listed criteria. Those criteria include a reasonable likelihood of materially harming any material part of the normal operation(s) of the covered entity, and deployment of ransomware within a material part of the covered entity's information systems.

Section 500.17(a)(1) requires electronic notice to the superintendent, in the form on the DFS website, as promptly as possible and no later than 72 hours after determining that a cybersecurity incident has occurred. The second amendment changed the 500.17(a) heading from notice of a cybersecurity event to notice of a cybersecurity incident, which ties the trigger to the incident definition. Under 500.17(a)(2), the covered entity must also promptly provide any information the superintendent requests about the incident. This describes the text as of November 2026.

The regulation does not mention AI agents, prompt injection, tool calls or MCP servers. The October 2024 DFS industry letter on AI-related cybersecurity risk says it imposes no new requirements beyond Part 500. It explains how covered entities should use the Part 500 framework to assess AI-related risks, which include social engineering, theft of nonpublic information and supply chain vulnerabilities. Agent obligations are therefore applications of existing duties, not a separate AI regime.

Testing common agent failure scenarios against the text

The mapping below is analysis, not regulatory text or legal advice. It shows where each scenario is likely to land on the two gates and where the answer turns on facts or interpretation.

• Blocked prompt injection attempt: Likely a cybersecurity event, since attempts count. Whether it is an incident depends on the criteria, and DFS FAQs state that most unsuccessful attacks need no notice. DFS encourages notice of significant unsuccessful attacks.
• Prompt injection that exfiltrates nonpublic information: Likely an event. It needs a full incident analysis against the listed criteria, including the likelihood of material harm to normal operations. Exposure of nonpublic information does not by itself settle the question.
• Unauthorized tool or MCP server action: Whether an out-of-scope action is an act or attempt to misuse an information system is interpretive. The permitted scope recorded for the agent and what it actually did drive the answer.
• Compromised delegated credentials: Use of credentials by an unauthorized party is likely an event. The incident question is the same as for exfiltration. Whether an AI agent counts as an agent within the authorized user definition is an open point.
• Event at a third-party AI provider: The incident definition covers third-party service providers. Per DFS FAQs, an affected covered entity must notify under 500.17(a) whether or not the provider also notifies DFS.

Where interpretation is required

Three points cannot be resolved from the text alone. First, whether a given agent behavior is an act or attempt to gain unauthorized access or misuse a system. An agent acting with valid delegated credentials but outside its intended scope sits in that gray area. Second, how to apply the material-harm criterion to a data exposure that does not interrupt operations. Third, what makes an unsuccessful attack significant enough to merit voluntary notice. DFS has not defined that threshold in the FAQ language.

These are judgment calls, and the defensible course is to make them in advance. Write down how the organization reads each point, who decides, and what facts it considers. A determination that follows a documented method is easier to explain to an examiner than one reconstructed after the fact. Reportability is a legal determination on ambiguous facts, so counsel should review edge cases.

The evidence a determination depends on

Each step above depends on facts about the agent: what it was permitted to do, what it did, and what controls applied at the time. Without those facts, a team cannot show whether an act or attempt occurred, what information was reached, or when the entity knew enough to determine an incident.

The records that bear on the criteria are the agent's identity and the delegated credentials it held, each tool call and its parameters, the data accessed, the policy decision applied to each action, any human approval, and timestamps throughout. This is a recommendation based on how the tests work. The regulation itself confirms only that DFS can request information about an incident under 500.17(a)(2). Part 500 also expects programs designed to detect cybersecurity events and an incident response plan that enables prompt response, so agent-specific playbooks should feed that plan.

Governance follows from the same facts. The CISO must timely report material cybersecurity issues, such as significant events, to the senior governing body or senior officers, so define whether agent events can reach that level. Contracts with AI and tool vendors should also require timely notice of events affecting the covered entity's information systems or nonpublic information, as the October 2024 letter advises.

How runtime policy enforcement supports the process

DFS stresses layered controls with overlapping protections, so that if one fails others prevent or mitigate impact. Runtime policy enforcement is one such layer. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit or escalate for human approval to individual interactions and tool calls. Enforcement happens at runtime, not through review after the fact.

That placement matters for reportability. When a policy decision is made at the moment of each action, the same step produces audit-ready evidence of what the agent was allowed to do and what it did. Trussed generates that evidence continuously and maps it to NYDFS, among other frameworks. A blocked tool call is recorded as a blocked attempt, which helps establish the event and incident gates quickly. An escalated action carries its approval record. The scope is individual interactions and tool calls, so this evidence complements, and does not replace, your broader incident response records.

For examiner scrutiny and model risk management, the value is the ability to show the permitted scope and actual behavior for a past interaction. Trussed is self-managed in the customer cloud with configurable retention and data residency. It has run continuously in a regulated enterprise for 18+ months, with 100+ models under one policy plane. Insurance, a regulated financial sector, is where Trussed is deepest. Evidence supports a determination but does not make it. The determination remains a decision for your compliance, security and legal teams.