NIS2 Meets AI Agents: Securing Agent Deployments Under Germany’s Now-Binding Cybersecurity Law

On 6 December 2025, NIS2 stopped being a directive somewhere in Brussels and became binding German law. The NIS2-Umsetzungsgesetz took effect with no transition period, and the number of companies under BSI supervision jumped from roughly 4,500 to around 29,500 across 18 sectors¹. Many of those companies are mid-sized manufacturers, suppliers, and service providers that never thought of themselves as critical infrastructure.

At the same time, AI agents are moving from pilot to production on the shop floor and in the back office. Gartner expects 40 percent of enterprise applications to feature task-specific AI agents by the end of 2026, up from less than 5 percent in 2025¹⁸. An agent is not a chatbot. It reads from your ERP, writes to your systems, holds credentials, and takes actions. That makes it the fastest-growing attack surface in enterprise IT and, at the same time, an asset that now sits squarely inside a BSI-regulated ISMS.

This guide is for the CISO, CTO, or Geschaeftsfuehrer who has to do both things at once: deploy AI agents that create real value, and keep them inside the lines of a cybersecurity law that carries personal liability. No fear, no hype. Just what NIS2 actually asks, where agents change the picture, and how to build a deployment that is compliant from the first pilot.

The Double Exposure: Attack Surface and Regulated Asset

Most articles treat AI agents and NIS2 as two separate projects. They are not. An AI agent deployment changes your cyber risk and your regulatory position in the same move, which is why it needs a single, joined-up plan.

• Agents expand the attack surface - 48 percent of cybersecurity professionals name agentic AI and autonomous systems as the top attack vector for 2026, ahead of deepfakes and other risks¹⁷.
• Agents act with real permissions - unlike a read-only chatbot, an agent authenticates, holds credentials, and takes actions across systems, so a compromise is not a leaked answer but an executed transaction²².
• Shadow AI is already inside - an estimated 68 percent of employees use AI tools without IT approval, creating agents and integrations that no ISMS currently covers²¹.
• Agents misbehave in the wild - 80 percent of IT professionals report having seen AI agents take unauthorised or unexpected actions²¹.
• The same agent is now regulated - if your company is in scope, that agent is part of the network and information systems the BSI supervises under Section 30 BSIG³.
• The cost is measurable - the average AI-agent-related data breach is estimated at 4.7 million dollars in 2026, before any regulatory fine is added¹⁷.

What NIS2 Now Requires (In Plain Terms)

NIS2 in Germany lives in the amended BSIG. Five paragraphs carry most of the weight, and it helps to know them by number because the BSI and your auditors will refer to them directly.

• Section 28 - Scope - defines who counts as a besonders wichtige (essential) or wichtige (important) Einrichtung, based on sector, headcount, and revenue⁵.
• Section 30 - Risk management - the ten minimum technical and organisational measures every in-scope entity must implement⁴.
• Section 32 - Reporting - the 24-hour, 72-hour, and one-month reporting duties for significant incidents⁸.
• Section 38 - Management duties - directors must approve and supervise measures and attend training, with personal liability attached⁷.
• Section 65 - Fines - up to 10 million euros or 2 percent of global turnover for essential entities, up to 7 million euros or 1.4 percent for important entities¹.

The dates are already behind us, which is the point people miss. There was no grace period.

Are You In Scope? Essential vs Important Entities

The first question is not about agents at all. It is whether your company is regulated. NIS2 sorts in-scope organisations into two tiers, and the tier decides how hard the supervision bites.

The two tiers

How to run the scope check

1. Match your sector - check whether your activity falls in one of the 18 sectors, from energy, transport, and manufacturing to digital services, waste, food, and chemicals⁵.
2. Apply the size thresholds - combine headcount and revenue against the tier definitions in Section 28. Group structures can pull a small subsidiary into scope⁵.
3. Check for special cases - some entities are in scope regardless of size, such as certain digital infrastructure and public administration providers³.
4. Register on the BSI portal - if in scope, register the company. The deadline was 6 March 2026 and late registration is still possible¹⁰.
5. Document the determination - even a company that concludes it is out of scope should keep a dated record of the reasoning. Scope can change with the next acquisition or revenue year.

Why AI Agents Widen the Attack Surface

An agent earns its value by acting on your behalf. The same property is what makes it dangerous when it is compromised or confused. These are the failure modes NIS2 expects you to manage.

• Prompt injection - a malicious instruction hidden in an email, document, or web page hijacks the agent’s goal, turning a helpful assistant into an exfiltration tool. OWASP ranks goal hijacking as the top risk for agentic applications in 2026²¹.
• Excessive permissions - agents are often granted broad, standing access so they “just work”. A single compromised agent then reaches far more than any one employee could²².
• Identity sprawl - agents spawn service accounts, tokens, and secrets faster than IAM tools can track. Gartner warns that agent sprawl without a registry becomes ungovernable¹⁹.
• The confused deputy - an agent with legitimate access is tricked into using it for an attacker’s purpose, and the logs show the agent, not the attacker.
• Data leakage through context - an agent that pulls sensitive records into a prompt can echo them into a downstream tool, a log, or a third-party model.
• Supply chain compromise - the model, the tool integrations, and the data connectors are all third-party components that can be poisoned or breached²².
• Shadow agents - business teams stand up agents on personal accounts, outside IT’s view, with no logging and no owner²¹.

Bringing Agents Into Your Section 30 Risk Management

You do not need a separate “AI ISMS”. You extend the one you already run so that an agent is treated like any other high-privilege system - just with a few agent-specific twists. If you hold ISO 27001, industry estimates put the overlap with Section 30 at roughly 70 to 80 percent, so most of this is extension, not invention¹³.

Mapping the ten measures to an agent

1. Risk analysis - assess each agent as its own asset: what it can read, write, and trigger, and what the worst plausible action is. Add agents to the risk register.
2. Incident handling - define an agent incident class with detection signals, a kill switch, and an owner who can pause the agent within minutes.
3. Business continuity - plan for the agent being wrong or offline. Keep the manual process runnable and back up the agent’s configuration and memory.
4. Supply chain security - assess the model provider, tool integrations, connectors, and host. Put security terms and data location in the contract¹².
5. Security in acquisition and development - review prompts, tools, and connectors like code. Test against prompt injection before go-live.
6. Effectiveness testing - red-team the agent regularly. Replay adversarial inputs and confirm guardrails still hold after model or prompt changes.
7. Cyber hygiene and training - train the people who supervise agents to recognise abnormal behaviour and to escalate.
8. Cryptography - encrypt the agent’s data in transit and at rest, and manage its secrets in a vault, not in a prompt or a config file.
9. Access control and asset management - give the agent its own identity, least-privilege and time-boxed access, and an entry in the asset inventory.
10. Multi-factor authentication and secured communications - protect the human and machine accounts around the agent, and route its actions over authenticated channels⁴.

When an Agent Causes an Incident: The 24/72/30 Clock

Section 32 BSIG sets a three-stage reporting duty for significant incidents, and the clock starts the moment you become aware⁸. An agent that leaks data or takes a harmful action can be exactly such an incident. The reportability test looks at impact on your service, not at whether a human or a machine caused it.

The three stages

An agent incident runbook

1. Detect - alert on abnormal agent behaviour: permission escalation, unusual data volumes, actions outside the agent’s defined scope.
2. Contain - hit the kill switch. Pause the agent, revoke its tokens, and isolate the systems it touched.
3. Assess - use the action log to reconstruct exactly what the agent did and whether the service impact is significant.
4. Report - if significant, file the 24-hour early warning to the BSI, then the 72-hour notification, then the one-month final report⁸.
5. Recover - restore from backups, fix the root cause (a prompt, a tool, a permission), and re-test before the agent goes back online.
6. Learn - feed the incident into the risk register and the effectiveness testing so the same failure cannot recur silently.

Supply Chain, Vendors, and Management Liability

Two of the most under-appreciated parts of NIS2 land hardest on AI agent projects: the duty to secure your supply chain, and the personal duty on management. An agent is built from third-party parts and approved by named directors, so both apply directly.

The agent supply chain

• Assess every layer - the foundation model, the orchestration framework, the tool and connector integrations, and the hosting environment are all suppliers under Section 30¹².
• A vendor certificate is evidence, not a discharge - a supplier’s own ISO 27001 helps, but it does not by itself meet your duty; you still assess the risk to your service¹⁴.
• Fix data location and processing - know where prompts and outputs go, which sub-processors are involved, and whether data leaves the EU.
• Get contractual security terms - reporting duties, audit rights, breach notification, and secure development commitments belong in the contract, not in a slide.
• Keep an exit path - you must be able to switch off or replace a compromised supplier without halting your service.

Management liability under Section 38

• Approve the measures - the management body must formally approve the Section 30 risk management measures, in writing⁷.
• Supervise implementation - approval is not enough; directors must oversee that the measures are actually in place and working⁷.
• Attend training - managers must take part in cybersecurity training regularly, and it must be documented⁷.
• Cannot be delegated - these duties cannot be outsourced to a third party; they sit with the leadership personally⁷.
• Personal liability - managers can be held personally liable for damage caused by a breach of these duties, which is what elevates NIS2 to a board topic⁷.

The 90-Day NIS2-Ready Agent Deployment

A NIS2-ready deployment is not slower than a normal one - it is a normal one done properly. Here is a week-by-week path that produces both a working agent and the evidence the BSI expects.

Phase 1: Scope and design (Weeks 1-4)

1. Week 1: Confirm regulatory scope - determine your NIS2 tier and register with the BSI if you have not already. Document the determination either way.
2. Week 2: Map the use case and data flows - define exactly what the agent will read, write, and trigger, and which systems and data it touches.
3. Week 3: Design the agent identity - assign a dedicated identity, least-privilege scopes, secret storage, and the kill switch before any build starts.
4. Week 4: Threat model and supplier check - run a prompt-injection and abuse threat model, and complete the supply chain assessment for model, tools, and host.

Phase 2: Build and test (Weeks 5-8)

5. Week 5-6: Build with guardrails - implement the agent with scoped tools, input validation, and full action logging from the first line, not as an afterthought.
6. Week 7: Red-team - attack your own agent with injection, confused-deputy, and data-exfiltration scenarios. Fix what breaks.
7. Week 8: Write the runbook - finalise the agent incident class, detection signals, and the 24/72/30 reporting steps. Rehearse the kill switch.

Phase 3: Deploy and evidence (Weeks 9-12)

9. Week 9: Controlled rollout - deploy to a limited scope with a human-in-the-loop on high-impact actions. Monitor closely.
10. Week 10-11: Expand and monitor - widen scope as confidence grows, keeping logging and alerting live. Train the supervising team.
11. Week 12: Produce the evidence - management approves the measures under Section 38, records the training, and files the documentation that supports a Section 39 proof later.

How Superkind Fits

Superkind builds custom AI agents for SMEs and enterprises, and it builds them to sit inside a regulated environment from the start. The approach is process-first and control-first: your workflows and your ISMS shape the agent, not the other way around.

• Dedicated agent identity - every agent gets its own identity, scoped credentials, and secret storage, so access control and asset management map cleanly to Section 30.
• Least-privilege by design - agents receive the narrowest access that makes the use case work, and access is reviewed rather than granted once and forgotten.
• Full action logging - every read, write, and trigger is recorded in a queryable, tamper-evident store, so an incident can be reconstructed and evidenced.
• Kill switch and human-in-the-loop - high-impact actions pause for human approval, and any agent can be stopped within minutes.
• Prompt-injection hardening - agents are built and red-teamed against goal hijacking and confused-deputy attacks before they go live.
• Runs on EU infrastructure - data stays within your infrastructure or EU-hosted environments, with clear data location and encrypted connections.
• Supplier transparency - clear documentation of the model, tools, and connectors so the agent fits your supply chain assessment.
• Audit-ready documentation - the deployment produces the records management needs to approve measures and support a Section 39 proof.

Decision Framework: Deploy, Harden, or Wait

NIS2 is not a reason to stop deploying agents. It is a reason to deploy them well. This framework helps you decide what to do with each agent idea on your list.

Frequently Asked Questions

Related Articles

• AI Agent Security: Prompt Injection, Data Leakage, and the OWASP LLM Top 10 for the Mittelstand
• Agent Identity: How Mittelstand IT Teams Govern Authentication and Access for AI Agents
• DPIA for AI Agents: How the German Mittelstand Implements GDPR Article 35 for Agent Rollouts
• AI as a Compliance Assistant: How the Mittelstand Automates Audit Trails, Policies, and Reporting
• Sovereign Company Brain: Running Your Knowledge Layer on EU Soil Without Sending It to the US

Henri Jung

Co-founder of Superkind, where he helps SMEs and enterprises deploy custom AI agents that actually fit how their teams work. Henri is passionate about closing the gap between what AI can do and the value it creates in real companies. He believes the Mittelstand has everything it needs to lead in AI - it just needs the right approach, and that approach now has to be secure and compliant by design.