NYDFS 72-Hour Notification When an n8n AI Agent Is Compromised: What to Log in Advance

What 500.17 asks, and where the clock starts

Section 500.17(a)(1) requires each covered entity to notify the superintendent electronically, 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 scope covers incidents at the covered entity, its affiliates and third-party service providers. Older DFS documents, including a 2026 consent order, use the wording "cybersecurity event". The current rule text says "cybersecurity incident", and internal procedures should follow the current text.

The period runs from the determination, not from the compromise itself. That makes the quality of evidence available at the time of the determination a practical constraint. A team that cannot tell whether an agent exfiltrated data or merely attempted a call will take longer to decide, and will have less to say if DFS asks follow-up questions. The DFS reporting instructions show the filer is asked for information about the incident, starting with the date or dates of the incident, so even that first field depends on reliable timestamps.

Two related points are easy to conflate. DFS lists a separate 24-hour notice for an extortion payment made in connection with a cybersecurity event on the entity's information systems. And the RAISE Act's 72-hour reporting of critical safety incidents applies to large frontier AI developers, not to covered entities deploying n8n agents. Neither changes the 500.17 analysis for your workflows.

This page does not give legal advice. Counsel should decide whether a given AI agent compromise meets the reportability threshold.

Why workflow records alone leave gaps

Workflow execution records are built to show how a workflow ran. Their retention depends on configuration set per environment, and they can be pruned over time. The questions raised during a notification decision are different: what was this agent permitted to do, what did it actually do, which data and credentials were involved, and which actions never completed because something stopped them.

Permission is a policy fact, not an execution fact. An execution record may show that a node called an API, but it will not necessarily show whether that call was within the agent's intended scope. Actions that were blocked or redacted may not appear at all if the record only reflects what completed. And if the n8n instance itself is the system under investigation, it should not be the only source of evidence about what happened.

Three practical consequences follow. Store policy decisions and tool-call records in a system separate from workflow execution data, so pruning or compromise of n8n does not remove them. Record the n8n version in force for each environment, since published vulnerabilities such as CVE-2026-25054, a cross-site scripting issue in markdown rendering fixed in versions 1.123.9 and 2.2.1, bear on scoping. And if n8n is vendor-hosted, third-party provider scope under 500.17 means you need a contractual or technical route to provider-side evidence before you need it.

Attack paths and the evidence needed to scope them

These are scenarios, not reportability findings. Each shows what a team would need to establish quickly, and the same evidence also serves later regulator questions.

• Prompt injection steering an agent: Input that triggered the behavior, the tool calls that followed, whether any were blocked or redacted, and which data left the boundary.
• Credential or API key exposure: Which credentials each agent could reach, every call made with them, the time window, and any approvals tied to their use.
• Malicious or unintended tool call: The call, its target and parameters, the policy decision applied, and whether a human approved it.
• Vulnerable platform version: The n8n version running at the time, the agents and credentials on that instance, and the activity across the exposure window.

Where runtime enforcement produces durable evidence

Evidence captured by a workflow after the fact records what happened. Policy enforced in the execution path records what was decided at the moment of each interaction. Trussed enforces policy in the execution path on individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Enforcement happens at runtime, not after the fact, and each decision generates audit-ready evidence mapped to NYDFS. Because blocked and redacted actions are decided in the path, they leave records that completed-execution data would not.

Two scope points matter for design. The evidence is per interaction and tool call. It is not a trace of an entire workflow, so keep n8n's own execution records for reconstructing sequence and retain them according to a documented setting. And where the evidence lives matters: Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency, which lets the entity keep evidence under its own control and outside the n8n instance.

This approach is useful only if the evidence is organized around the questions in the checklist above. Whatever tooling you use, test it against those questions.

Governance practices for the determination itself

The determination is the trigger for the 72-hour period, so treat it as a recorded decision, not an informal conclusion. The practices below keep the clock auditable and the response consistent.

• Name who makes the determination and who can act as backup, and record the timestamp and basis of the decision.
• Use the current rule terminology, "cybersecurity incident", in internal procedures and templates.
• Track the separate 24-hour extortion-payment notice so it is not missed during an agent investigation.
• Establish a route to evidence from affiliates and third-party providers, including any vendor hosting n8n.
• Run a tabletop exercise: pick one agent and try to answer the checklist questions from stored evidence alone.