AI agents in critical infrastructure: the agent in the control room.

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.

That’s the genuinely interesting part of the debate about AI agents in critical infrastructure. People talk as if a decision were pending. It isn’t. It’s being made right now, out of staffing shortages, and usually not by the security team.

#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.

That raises a question classic security models don’t answer: who is responsible when the agent does something? The person who deployed it? The organisation that owns the infrastructure? Our IAM models are built for humans who log in. An agent doesn’t log in. It runs.

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

In IT, the damage is data exfiltration. In OT, the damage is physical. A wrong switching operation, a mis-set setpoint, a suppressed alarm. That’s why, since late 2025, the authorities have treated agents in OT environments as their own category rather than a subcase of IT security, with their own demands on operational practice under IEC 62443.

#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 comment period runs until 31 August 2026. Anyone working in the field should take a look while they can still weigh in.

The BSI treats an AI agent as exactly what it is: a non-human identity with API keys, permissions and attack surface.

#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 requires demonstrable risk management and documented operating processes. An agent that evaluates log data and triggers countermeasures is part of the security organisation. The same rules apply to it as to any other security-relevant system. What that means for operators in practice is in my post on the NIS2 reporting duty for agent incidents.

The EU AI Act can classify AI systems that act as a safety component in critical infrastructure, or that control it, as high-risk. Then human oversight under Article 14 and automatic logging across the full lifecycle under Article 12 come into play.

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.

#The numbers: how far along are companies really?

The Cloud Security Alliance surveyed this in 2026:

• 82 percent of organisations found AI agents in their environment they didn’t know about.
• 65 percent had at least one security incident involving an AI agent in the past twelve months. For 61 percent of those affected it was data exfiltration, for 43 percent operational disruption.
• 21 percent have a defined process to shut an agent down again.
• 18 percent trust their existing IAM to manage agents at all.

Rubrik Zero Labs separately surveyed more than 1,600 IT and security leaders. In Germany, 21 percent say they have full visibility over their AI systems. 86 percent in EMEA expect agents to soon outpace their security controls. And 75 percent in Europe say manually monitoring the agents is more effort than the work the agents take off their hands.

That last point is the most honest thing in the whole survey.

#Six measures for critical-infrastructure operators

None of this is new. It’s just rarely done.

1. 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.
2. Every agent gets its own identity. No shared service accounts, no long-lived tokens. Short-lived credentials with a tight scope.
3. 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.
4. 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.
5. 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.
6. Practise shutting down. If 21 percent have a decommissioning process, that means four in five organisations are running agents nobody can cleanly remove any more.

#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