Since February 2026, three German grid operators have been testing an AI agent in the control room. It was built by Fraunhofer IOSB-AST. The agent pulls data from the analysis and data-storage systems, runs the usual analysis steps and presents the result to the operating staff. A human still decides.
The reason for the project is mundane: there aren’t enough people. An operator in a control room has one to two years of training before running a shift alone. There simply aren’t that many people left.
The trial illustrates a useful deployment boundary: an agent can assist an operator while decision authority stays with a human. Security review should define that boundary before the agent receives access to operational systems.
TL;DR
- Fraunhofer describes a controlled trial with three grid operators, where staff retain decision authority.
- Regulatory scope depends on the operator and use case. Assess NIS2 duties and AI Act classification and application dates separately.
- Treat the identity behind each agent as an access-control subject, with an owner and limited permissions.
- Test discovery, ownership and decommissioning in your own environment instead of relying on a universal agent-adoption statistic.
#What sets an AI agent apart from ordinary software
An agent is not a tool you call. It plans, calls other systems and acts. To do that it holds credentials and permissions. It decides for itself which step to take next.
An agent still authenticates through accounts, workload identities or delegated credentials. Define who owns that identity, who approves new access and who can contain an incident. These responsibilities build on existing IAM controls.
The second problem is speed. A single error, a hallucination, a prompt injection, doesn’t stop with agents. Agents hand tasks to one another with no one sitting in between. One error becomes a chain, and it runs faster than an operator can follow it. In a marketing workflow that’s annoying. In a control room it’s something else.
Agentic AI in OT: the difference from classic IT
IT incidents can affect confidentiality, integrity and availability. In OT, incorrect commands can also affect physical processes and safety. Match agent permissions, change approval and recovery procedures to the process hazards.
#What the BSI and CISA say about AI agents
Anyone who thinks this is unregulated territory has missed the last twelve months.
December 2025: CISA and Australia’s ACSC, together with further agencies including the BSI, publish principles for the secure integration of AI in OT. Explicitly for critical-infrastructure operators, explicitly for AI agents too. The BSI sums up the recommendations like this: define AI roles and responsibilities, test and monitor continuously, extend incident-response and safety processes to cover AI scenarios.
May 2026: The same agencies plus the FBI, NCSC-UK, NCSC-NZ and CCCS follow up with Careful Adoption of Agentic AI Services. This time it’s only about agents. Named risks: a larger attack surface, privilege escalation, deviant behaviour, missing auditability. The recommendations are unspectacular and useful for exactly that reason, a dedicated identity per agent, continuous authentication, least privilege, red-teaming across the lifecycle. And: start with non-critical tasks and expand autonomy only once you know it holds.
June 2026: The BSI warns about the impact of AI on the threat landscape (context here). It gets critical, per the BSI, above all where an agent is coupled to external tools and APIs and its outputs trigger direct actions. That path lets an attacker exfiltrate data, launch unauthorised access and persist malware.
July 2026: The BSI puts A5 up as a community draft, a modular assessment architecture for AI systems. The announced comment deadline was 31 August 2026. Check the BSI publication page for the current status.
Give each agent a traceable identity, bounded access and an owner who can act when something goes wrong.
#AI agents and NIS2: it already applies, no new law needed
A common misconception is that rules for agents still have to be written. The existing ones already bite. heise cleanly untangled the three layers back in April.
NIS2 obligations apply to covered entities. Include relevant AI systems in their risk management, and assess significant incidents using the applicable criteria. Our NIS2 reporting guide explains the German reporting stages.
The EU AI Act requires a use-case-specific classification. Some AI safety components in specified critical-infrastructure contexts can be high-risk; deployment in an OT environment alone does not settle that classification. Check the current application timetable before assigning legal deadlines.
At the BSI this gets concrete in the guidance on attack-detection systems and in the AIC4 criteria catalogue.
Put differently: anyone running an agent in a critical-infrastructure process without documentation, without logging and without named responsibility is not in a grey zone. They’re behind.
#How to assess your own agent-security gaps
The Cloud Security Alliance’s 2026 NHI and AI security survey reports gaps in ownership and lifecycle policies. Use those findings as questions to test against your own agent inventory.
- Discovery: compare known agents with SaaS integrations, service accounts and automation workflows.
- Ownership: identify who approves the purpose and access of each agent.
- Containment: demonstrate how you pause execution and revoke credentials safely.
- Evidence: verify that tool activity and permission changes can be reconstructed.
A survey cannot establish your own exposure. Run a bounded review of one operational workflow: identify the agent, inspect its credentials, trace reachable systems and test who can stop it.
Record the gaps found in that review and assign each one an owner and a remediation date.
#Six measures for critical-infrastructure operators
None of this is new. It’s just rarely done.
- Inventory first, debate later. Before you talk about agent governance, you have to know which agents are already running. They rarely arrive through a project. They arrive through a SaaS feature someone enabled, or a vendor update.
- Every agent gets its own identity. No shared service accounts, no long-lived tokens. Short-lived credentials with a tight scope.
- Not least privilege, but least agency. Limiting permissions isn’t enough. You have to limit what the agent is allowed to do at all, which tools, which APIs, which actions. Read-only is a legitimate target state.
- Irreversible actions stay with a human. Switching operations, mass deletion, sign-off. Human in the loop not as a principle but as a technically enforced step.
- Extend your incident processes. Most IR playbooks have no case for “the agent autonomously did the wrong thing.” That belongs in there, including how you stop an agent mid-operation and what has to be rolled back afterwards.
- Practise safe containment and removal. Test credential revocation, queued tasks and rollback in a controlled environment before relying on the procedure in production.
#In closing
The Fraunhofer agent in the control room is well done: a narrow remit, a human deciding, a controlled trial with three operators. That’s how it should run.
The risk isn’t with the projects set up that way. It’s with the agents nobody treated as a project, because they came in with a software update. They’re in no register, have no owner, and run with whatever permissions were convenient at setup.
You only find those when you go looking. Elmoz makes them visible.
#FAQ
Are AI agents allowed in critical infrastructure (KRITIS)?
Some AI deployments are permitted in critical infrastructure, but admissibility and duties depend on the use case and applicable rules. Assess safety, sector requirements, AI Act classification and application dates before deployment.
Does an AI agent fall under NIS2?
NIS2 regulates covered entities rather than defining a separate category of regulated AI agents. Relevant agent deployments belong in those entities’ risk-management and incident-response processes.
What is the difference between an AI agent and a chatbot?
A chatbot answers. An agent acts. It plans multi-step tasks, calls tools and APIs on its own and uses its own credentials to do so. That makes it a non-human identity on the network, not just a user interface.
What are shadow agents?
Shadow agents are AI agents operating without appropriate IT or security visibility. They may appear through SaaS features, no-code workflows or vendor updates. Check for an owner, purpose and access record for each one.
How do you get started with agent security?
With an inventory. Without knowing which agents exist, what permissions they hold and who owns them, every further measure is theory.