NIS2 Meets AI Agents: Supply Chain, Incidents and Management Liability
How NIS2 duties on management, supply chain and incident reporting apply when your organization runs AI agents.
NIS2 does not mention AI agents, and it does not need to. It is an all-hazards cybersecurity directive, and an agent with credentials, tool access and the ability to act inside your systems is simply a new kind of actor that your risk analysis, access control, supply chain and incident handling now have to cover. If your organization is in scope, the question is not whether NIS2 applies to agents but whether your existing evidence stretches to them.
Last verified 2026-10-06. The primary text is Directive (EU) 2022/2555 on EUR-Lex; our shorter reference is NIS2 for AI.
Who is in scope, and where the law stands
NIS2 applies to essential and important entities in the sectors listed in Annexes I and II, generally medium-size and above. If you are unsure whether you are one, that is a question for your national authority's guidance and your counsel, not for a blog post.
Transposition is uneven. The deadline was 17 October 2024, and on 8 July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify full transposition, according to Hunton. Trackers indicate most Member States now have a law in force, but national rules differ, so check the law of each country where you operate. In January 2026 the Commission also proposed targeted NIS2 amendments and a revised Cybersecurity Act; that package has not been adopted.
Article 20: the board owns this
Article 20 makes management bodies responsible for approving and overseeing the cybersecurity risk-management measures, and they can be held liable for infringements. They must also follow training. For AI agents this has a practical consequence: a decision to give an agent write access to production systems is a risk decision, and it needs an owner who can answer for it.
A workable pattern is to give every agent an accountable human owner, a documented risk level and an approval record for the permissions it holds. Our post on enterprise AI governance and risk covers the organizational side.
Article 21(2): the measures, read for agents
Article 21(2) lists the minimum measures. Several map directly onto agent deployments.
| Article 21(2) measure | What it means for an agent with tool access |
|---|---|
| Risk analysis and system security policies | Agents and their tools are in the asset inventory and the risk register |
| Incident handling | Playbooks exist for prompt injection, tool misuse and runaway actions |
| Security in acquisition, development and maintenance, including vulnerability handling | Prompts, tool definitions and agent code are versioned, reviewed and patched like software |
| Policies to assess effectiveness | Red-team and abuse testing of agents on a schedule |
| Access control, asset management, MFA | Each agent has its own identity and least-privilege scope; humans who administer agents use MFA |
| Cryptography and encryption | Secrets and tokens held by agents are stored and rotated properly |
| Supply chain security | See below |
Agent identity and least privilege
The most common failure is an agent running under a shared service account or a developer's personal token. Give each agent its own identity, scope its tools to the minimum needed, separate read from write, and require human approval for high-impact actions. The point is that when something goes wrong, the log shows which agent acted, under whose authority, with which permission.
Prompt injection and tool abuse as incident scenarios
Treat these as scenarios in your incident-handling policy, not as exotic AI problems. Typical cases:
- an agent reads a document or web page containing hostile instructions and calls a tool it should not;
- a compromised or over-permissioned tool lets an agent exfiltrate data;
- a loop or misconfiguration causes an agent to take a large number of unintended actions.
For each, decide in advance how you would detect it, who can suspend the agent, how you would revoke its credentials, and what evidence you would need. Our post on shadow AI is a reminder that the agents you have not inventoried are the hardest to cover.
Article 21(3): the model and vendor supply chain
Article 21(3) asks entities to consider the vulnerabilities specific to each direct supplier and the supplier's secure development practices. For an agent stack the suppliers include more than the model provider:
- the model provider or gateway;
- the hosting layer and any sub-processors;
- orchestration frameworks, plugins and tool servers;
- retrieval and vector storage;
- observability and logging vendors.
A short supplier questionnaire for each, plus a record of what you asked and what they answered, is the minimum evidence. Also plan the exit: if a model or tool vendor has an incident or disappears, how quickly can you swap it? Our model exit cost audit and vendor lock-in guide cover this. Financial entities face a parallel regime under DORA; see DORA for AI.
Article 23: the 24 hour, 72 hour and one-month clock
For significant incidents, Article 23 sets a three-stage clock:
- an early warning within 24 hours of becoming aware;
- an incident notification within 72 hours;
- a final report within one month of the notification.
What counts as a significant incident is applied through the Directive and the national law that transposes it, so the threshold and the reporting channel depend on your Member State. The practical point for agents is that you cannot meet a 24 hour clock if you cannot tell within hours what an agent did. That depends on logging, covered in our observability guide.
A concrete example: an agent incident in 72 hours
The scenario: a support agent with access to a ticketing system and a customer database is manipulated through hostile text in an inbound ticket and starts sending records to an external address. The timeline below is an illustration of the evidence you would want at each stage, not a legal template.
| Time | Action | Evidence to hold |
|---|---|---|
| T+0 | Anomaly alert fires, or someone reports it. Record the moment of awareness | Alert record, who noticed, timestamp |
| T+1h | Suspend the agent, revoke its credentials and tool tokens, preserve logs | Suspension record, credential revocation log |
| T+4h | Reconstruct the action trace: inputs, model version, tools called, data accessed, outputs | Agent action trace, prompt and tool-call logs |
| T+12h | Assess whether the incident meets your national significance criteria; brief the accountable executive | Written assessment, decision record |
| T+24h | Submit the early warning if the incident is significant | Copy of submission |
| T+48h | Scope affected data and systems; identify the root cause path, for example the injection source | Scoping notes, affected-record list |
| T+72h | Submit the incident notification with initial assessment | Copy of submission, mitigation actions |
| T+1 month after notification | Final report: root cause, mitigations, lessons, control changes | Final report, change tickets |
If personal data is involved, a separate GDPR analysis runs alongside this one; see GDPR and LLMs. The two regimes have their own clocks and tests, so do not assume one notification serves both.
Logging for incident reconstruction
The logs that make the table above possible are the ones you decide on before the incident: agent identity, the policy that applied, the model and version used, tool calls with parameters, data sources accessed, approvals requested and granted, and the outcome. Protect them from tampering, and retain them long enough to support a one-month final report. Be careful that logs do not become a second uncontrolled store of sensitive data.
Article 34: what is at stake
For essential entities, fines can reach at least EUR 10 million or 2% of worldwide annual turnover; for important entities, at least EUR 7 million or 1.4%. Member States set the ceilings, and they cannot be lower than these figures. Combined with Article 20 liability for management bodies, the cost of an unprepared agent incident is not only technical.
How Swfte supports this
Swfte is built for Europe as a sovereign-by-design platform, and it is designed to let you give each agent a Trust Profile with an owner, risk level, approved models, permitted and restricted actions and a human approval rule. That maps onto the identity, least-privilege and accountability points above, and governance policy is designed to act at runtime on what an agent can actually do. Swfte provides the technical controls, governance mechanisms and evidence to support deployment within applicable requirements; the exact posture depends on use case, jurisdiction, deployment and configuration. See the trust page for current detail before you rely on a specific control. The EU hub, governance, sovereignty and Trust Profile pages explain the rest.
This is not legal advice. Confirm whether NIS2 applies to you, and how your Member State has implemented it, with qualified counsel.