NIS2 reaches AI systems through governance, data and telemetry

At a glance

What this is: NHI Mgmt Group's analysis, drawing on DeepKeep's blog post: NIS2 can apply to enterprise AI without naming AI explicitly, and the directive pushes governance, technical controls, and incident evidence across the full AI stack.

Why it matters: IAM, NHI, and security teams need a governance model that ties AI usage, tool permissions, data access, and telemetry to regulated service scope, not to the AI label.

Context

NIS2 is a system-level cyber law, not a technology-specific label. If an AI capability supports a covered service, reaches operational systems, or processes company data, the compliance question becomes whether that capability changes the entity’s cyber risk posture and control evidence. For organisations running AI in production, the practical issue is scope, not branding.

That matters because AI introduces governance gaps that classic service inventories often miss. Browser assistants, embedded copilots, agentic workflows, and external AI services can all reach regulated information or trigger actions without being tracked as standard application assets. In a NIS2 context, those blind spots turn into evidence gaps as well as control gaps. Identity Security Regulatory Map

Key questions

Q: How should teams determine whether an AI service falls under NIS2?

A: Teams should classify an AI service under NIS2 by checking whether it is part of the essential or important entity’s network and information systems, supports a covered business function, and is operated or materially controlled by the organisation. The NIS2 control and evidence model should capture service ownership, data flows, admin access, supplier responsibility, logging, and incident reporting obligations so the classification is defensible.

Q: Why do AI agents create new governance risk for GRC programs?

A: AI agents can request access, process data, and generate trust artefacts faster than human review cycles can keep up. That creates risk when organisations treat them as tools rather than as governed machine actors with their own lifecycle, privilege, and accountability requirements. Without that model, assurance becomes vulnerable to blind spots and fabricated confidence.

Q: How do runtime controls reduce AI tool abuse?

A: Runtime controls reduce AI tool abuse by limiting what an agent or model can do at the moment of use. Tool allowlists, per-request authorisation, scoped API tokens, approval gates for high-risk actions, and session logging stop prompt injection, overbroad data access, and unauthorised actions even when the model is exposed to untrusted input.

Q: What evidence should teams preserve after an AI security incident?

A: Teams should preserve prompts, model inputs and outputs, tool calls, system messages, access logs, API token use, policy decisions, and the affected model or agent configuration. That evidence shows what the AI system saw and did, which permissions it had, whether data was exposed, and whether the incident came from misuse, compromise, or control failure.

Technical breakdown

NIS2 scope for AI services and agents

NIS2 scope follows the service and the entity, not the software label. When an AI capability supports a covered business function, handles company data, or connects to operational systems, it becomes part of the risk surface that must be assessed and governed. That includes managed AI applications, employee use of external AI services, retrieval-augmented workflows, and agentic tools that can invoke actions. The key technical point is that risk emerges from the AI system’s access path, data flow, and integration points, not from whether the model itself is internal or third-party. See the Identity Security Regulatory Map.

Practical implication: Inventory AI services by business function, data reach, and tool access before deciding whether they fall into the compliance scope.

Why AI supply chains expand the attack surface

AI supply chains are not limited to model files. They include provenance of models and artifacts, third-party services, retrieval sources, serialization formats, and the behaviour of any wrapper that can turn model output into tool execution. A poisoned document, unsafe artifact, or compromised retrieval source can redirect an approved workflow without breaking the surrounding application. In practical terms, the security problem is not just model compromise. It is the chain from content ingestion to model inference to downstream action, which creates new failure modes for trust and integrity.

Practical implication: Treat model provenance, retrieval sources, and tool-triggering workflows as governed supply-chain dependencies, not optional add-ons.

Access control and telemetry for AI tool use

AI agents and assistants need policy at the moment of action, not just at deployment. Runtime controls have to inspect the user or application context, the prompt, the retrieved material, the response, and the intended tool call before a risky interaction completes. That is different from conventional application review, which often sees only static permissions and post-hoc logs. For regulated environments, the technical requirement is traceability across identity, data, and execution layers so that investigators can reconstruct what happened and whether the control actually interrupted the action path.

Practical implication: Enforce tool permissions and logging at runtime so every AI action can be attributed, reviewed, and, if needed, blocked.

Threat narrative

Attacker objective: The attacker’s objective is to use trusted AI workflow execution to move sensitive data or trigger unintended actions without tripping conventional application controls.

1. Entry occurs when an approved agent or employee-facing AI workflow ingests a poisoned document or external prompt content.
2. Credential or authority is then abused when the injected instruction causes the workflow to call an approved tool or reach regulated data.
3. Impact follows when the resulting action moves sensitive information outside the intended workflow and creates a reporting obligation under NIS2.

Breaches seen in the wild

• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NIS2 makes AI governance an enterprise cyber control issue, not a model-management side topic. The directive does not need an AI-specific chapter to matter here, because it already captures the business service, the data path, and the operational dependency. That means AI inventories, access decisions, and exception handling now sit inside a regulated governance model. Practitioners should treat AI use as part of the covered service stack, not as an innovation exception.

The named failure mode is scope blindness. Organisations often govern the headline AI platform while leaving browser assistants, embedded copilots, departmental deployments, and external services outside the same control frame. That creates an oversight gap between declared policy and actual data exposure. NIS2 pressure exposes that mismatch quickly, so governance has to follow where AI is used, not where the procurement team bought it.

AI supply-chain risk is now a compliance problem because integrity failures can become reportable incidents. Model artifacts, retrieval sources, and unsafe serialization paths can all influence the behaviour of an approved workflow. When those dependencies are not inventoried and tested, the organisation cannot show how a risky action was prevented or contained. Practitioners should link AI supply-chain assurance to incident evidence, not leave it in a separate technical queue.

Runtime control is the dividing line between policy and proof. A one-time approval of an AI use case does not satisfy a regime that cares about proportionate, tested measures and incident reconstruction. The useful control point is the moment the system decides whether a prompt, retrieval result, or tool invocation is allowed to continue. Teams that cannot demonstrate that control at execution time will struggle to defend both security and compliance outcomes.

From our research library:

• Enterprise AI use rose from 55% of organisations in 2023 to 88% in 2025, according to McKinsey’s Global Surveys on the State of AI.

What this signals

Scope blindness: AI programmes fail when governance only tracks the flagship platform and ignores the browser assistants, copilots, and external services employees actually use. That blind spot is where regulated data exposure and unverifiable actions accumulate, so the next governance step is to align inventories with real usage patterns rather than procurement labels.

NIS2 will push more organisations to prove that AI-related decisions are governed at the same level as other production services. The practical shift is toward evidence-first control design, where access boundaries, tool permissions, and telemetry are created for investigation as much as for prevention.

For practitioners

• Map AI services to NIS2 scope Classify each AI capability by the covered service it supports, the data it reaches, and the systems it can influence, then record the national scope decision for each operating jurisdiction.
• Extend asset inventories to AI workflows Include browser assistants, embedded copilots, coding agents, retrieval sources, and external AI services in the same inventory process used for other production applications.
• Test prompt-injection and tool-abuse paths Run repeatable tests that show whether an AI workflow can be steered into calling tools, exposing data, or crossing intended data boundaries under realistic input conditions.
• Build evidence for incident classification Ensure telemetry joins identity, prompt, retrieval, response, tool call, and timestamp data so the organisation can prove what happened, when it happened, and what was contained.

Key takeaways

• NIS2 can already cover enterprise AI when the system supports a regulated service, reaches operational systems, or processes company data.
• The hardest governance gap is not model quality but scope blindness, because unmanaged assistants and agents can sit outside ordinary inventories and oversight.
• Teams need runtime controls and joined telemetry so they can constrain risky AI actions and reconstruct incidents with enough evidence to meet reporting duties.

Related NHI Mgmt Group resources: NIS2 Directive Guide · Identity Security Regulatory Map · NIS2 Readiness Checklist · Agentic AI Compliance Guide

Key terms

• NIS2 Directive: The NIS2 Directive is the European Union's cybersecurity framework for risk management, reporting, and governance across critical sectors. It raises the bar on demonstrable controls, especially where access management, supplier oversight, and incident evidence must be shown under regulatory scrutiny.
• AI Attack Surface: The AI attack surface is the full set of places where an AI system can be influenced, misused, or broken. It includes models, prompts, tools, connectors, data pipelines, training data, APIs, agents, and human workflows. Security teams assess it to find paths for prompt injection, data leakage, model abuse, and unauthorized actions.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Runtime control: Controls that enforce policy while an AI system is operating, rather than after the fact. For healthcare chatbots, runtime control includes data masking, output filtering, access scoping, and immutable logging so the organisation can defend the interaction itself.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme.Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.