An agent-related event becomes reportable under NIS2 when it is a significant incident: one that causes, or could cause, severe operational disruption or financial loss, or considerable damage to others. A manipulated agent that leaks data, corrupts records or takes down a service can qualify. Reporting then follows staged deadlines, so the evidence must be ready before anything happens.
What does NIS2 require?
The NIS2 Directive requires essential and important entities to notify their national CSIRT or competent authority of significant incidents without undue delay. In substance, an incident is significant if it:
- has caused or can cause severe operational disruption of services or financial loss for the entity; or
- has affected or can affect other natural or legal persons by causing considerable material or non-material damage.
Reporting is staged, with short, fixed deadlines set by the directive and transposed into national law: an early warning, saying whether the incident is suspected to be caused by unlawful or malicious acts or could have cross-border impact; an incident notification updating the early warning with an initial assessment of severity, impact and indicators of compromise; intermediate reports on request; and a final report with a detailed description, the likely root cause, mitigation applied and any cross-border impact. Where appropriate, entities must also inform recipients of their services who may be affected.
Who does it apply to?
Essential and important entities under NIS2, including, where they fall within scope, managed ICT service providers that may run agent platforms; see does NIS2 apply to AI agent platforms. Financial entities report major ICT-related incidents under DORA instead; see DORA incident reporting when an AI agent fails. The wider security duties are set out in NIS2 and AI agents: cybersecurity duties for essential entities.
When does an agent event become a significant incident?
Agent incidents come in shapes that security teams may not recognise at first.
| Agent event | Could be significant if |
|---|---|
| Injected instruction leads an agent to disclose data | Personal or confidential data of many people or clients is exposed |
| Agent writes wrong values into an operational system | Service is disrupted or safety is affected |
| Agent's credentials are stolen and used | Attacker gains access to systems through the agent's identity |
| Model provider outage stops agent-run processes | Essential service is severely disrupted with no fall-back |
| Agent sends large volumes of messages or requests | Causes disruption to the entity or others |
| Agent behaviour changes after an unannounced model update | Errors spread before detection and cause loss or damage |
Two features of agent incidents make classification harder. First, cause is often unclear early: was the wrong action a bug, a model change or an attack? NIS2's early warning asks whether malicious action is suspected, so you need a fast way to tell. Second, impact spreads at machine speed. An agent can process thousands of cases before anyone looks, so assessing how many people were affected requires a complete action record.
What should you have ready?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Detect quickly | Alerts on abnormal agent activity: volume, scope, refusals, destinations | Alert records |
| Decide significance | Classification criteria that include agent-specific scenarios | Classification procedure; decisions |
| Early warning: malicious or not | Provenance of inputs recorded, so injected content can be identified | Decision records with provenance |
| Incident notification: severity and impact | Complete, append-only log of agent actions to count affected cases | Action log; impact analysis |
| Indicators of compromise | Agent identities, inputs and destinations captured | Incident evidence pack |
| Contain | Ability to stop a capability or an agent at once | Stop records |
| Final report: root cause | Versioned briefs, sources, model versions and change history | Configuration history |
| Inform affected recipients | Templates and routes for telling customers or partners | Communications log |
| Learn | Post-incident review feeding risk analysis | Review reports |
The provenance row is the one most firms lack. If you can see that the instruction that triggered a disclosure arrived in an external email, you can say early that malicious action is suspected, and your root cause is half written. Our guide on how to handle an AI agent incident covers the response, and the AI agent incident report template gives a structure for the reports.
What will the CSIRT or authority ask?
- When did you detect the incident, and how?
- Is malicious action suspected? On what evidence?
- How many people or services were affected, and how do you know?
- What did the agent do, step by step?
- What is the root cause: configuration, model, supplier or attacker?
- What have you changed to prevent a repeat?
What does NIS2 reporting not cover?
It does not replace GDPR breach notification, which may also be required if personal data is involved and has its own deadline. It does not cover incidents with no significant impact, though those should still be logged. It does not apply to financial entities' ICT incidents, which go under DORA. Exact timings and forms come from national transposition. For the full map, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Every fact reaching a Pryme agent carries its provenance class, and every verdict is filed in an append-only record that names the bound that decided. In an incident, that record shows what each agent did, on which facts, from where, which is what the early warning, the impact assessment and the root cause analysis all need.
Questions people ask
Is a model provider outage our incident to report?
If it severely disrupts your services, the incident is yours, whatever its cause. Your supplier may also have reporting duties of its own.
Does an attempted injection that was blocked need reporting?
Usually not, if it had no significant impact. Log it, review it and consider whether it signals a wider campaign, which may change the assessment.
Who decides whether an agent incident is significant?
Your incident management process, using defined criteria. Make sure agent scenarios are written into those criteria so the decision is quick.