Critical infrastructure is a short list of systems whose failure a society cannot absorb: power, water, finance, health, communications, government. For years AI was an application that sat next to those systems and gave advice. That has changed. Agents with real credentials now read mail, change configurations and call tools inside the networks that run those sectors, and the agencies that defend them say so in writing. The systems around AI already get critical-infrastructure discipline. AI should get it too.
What critical infrastructure means
The definitions are old and deliberately broad. CISA lists 16 critical infrastructure sectors, from energy and water to financial services, healthcare, communications, information technology and government facilities. What puts a sector on the list is that its assets, physical or virtual, are “so vital to the United States” that losing them would weaken security, the economy or public health and safety.
Europe’s NIS2 Directive covers 18 sectors and requires medium and large entities in them to take cybersecurity risk-management measures, report significant incidents to national authorities, and hold top management accountable when they don’t. In September 2024 the UK went a layer down and designated data centres as Critical National Infrastructure, on the same footing as energy and water.
The pattern is consistent. When a technology becomes something the essential services cannot run without, it gets inventory, resilience requirements, accountable owners, incident reporting and audit.
AI is already inside
The clearest statement comes from the agencies themselves. In May 2026 the cyber agencies of Australia, the US (CISA and NSA), Canada, New Zealand and the UK published Careful adoption of agentic AI services. Its first line says agentic AI systems “increasingly operate across critical infrastructure and defence sectors” and support mission-critical capabilities.
Operational technology has its own guidance. In December 2025 CISA, Australia’s ACSC and partners from the US, Canada, Germany, the Netherlands, New Zealand and the UK published principles for integrating AI into operational technology, written for owners and operators and focused on machine learning, LLM-based systems and AI agents.
Regulators have started to draw lines around it. The EU AI Act classes as high-risk any AI system used as one of the safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity (Annex III, point 2). After the Digital Omnibus on AI, Regulation (EU) 2026/1744, those obligations for stand-alone high-risk systems apply from 2 December 2027, and from 2 August 2028 for AI embedded in regulated products. In July 2026 the Commission’s Action Plan on Cybersecurity and Artificial Intelligence set out a secure testing environment for organisations in energy, transport, health, finance and public administration that want to trial AI tools.
What regulation should do
Today no jurisdiction lists AI itself as a critical infrastructure sector. The EU’s high-risk category covers AI used as a safety component, US guidance is voluntary, and the agencies’ own answer is restraint. Each of those is a starting point. Here is what regulation should build on it.
- Cover AI where it acts, not only where it is a safety component. An agent with an engineer’s credentials doing IT work in a utility is not, by the AI Act’s text alone, a safety component in the supply of electricity, yet it can change the systems that are. Critical-infrastructure duties should reach every AI system and agent operating inside an essential entity’s network, the way NIS2’s risk-management duties already reach the entity’s other IT.
- Turn the voluntary baseline into obligations. DHS’s Roles and Responsibilities Framework for AI in Critical Infrastructure (November 2024) already lists the right responsibilities across the 16 sectors, but only as voluntary ones. It was written to complement Executive Order 14110, which Executive Order 14148 revoked on January 20, 2025. Inventory, least privilege, redundancy and an AI incident runbook should be requirements for critical-infrastructure operators, not suggestions.
- Make restraint enforceable. The Five Eyes agentic guidance recommends using agentic AI only for low-risk, non-sensitive tasks and never granting it broad or unrestricted access to critical systems. Regulation should require that those limits are enforced outside the agent, on each action, with human approval for high-impact actions, and that the operator can prove it.
- Bring AI incidents into existing reporting. A prompt injection that moves money or changes a configuration is a significant incident and should be reported through the channels that already exist, such as NIS2’s. America’s AI Action Plan (July 2025) calls for a DHS-led AI Information Sharing and Analysis Center across critical infrastructure sectors and for AI in incident-response playbooks; those recommendations should become standing practice.
- Oversee concentration. When many operators depend on the same few model providers, one outage or bad update reaches all of them at once. Financial regulation already has a model: the EU’s Digital Operational Resilience Act sets up oversight of critical ICT third-party providers. Major model providers serving critical sectors deserve the same scrutiny.
- Require evidence an auditor can trust. Operators should keep a tamper-evident record of what each agent was allowed to do, what it was refused and who approved what, one that the agent being audited cannot edit.
None of this needs a new regulator. It extends regimes that already exist to the newest operator in the network. And it closes the gap in today’s guidance, which says agents already operate across these sectors while telling organisations to keep them away from anything critical. Both are true at once in most large operators, so the restraint has to be enforced somewhere, on every action, by something other than the agent.
Why AI fails differently
A server fails when it is compromised or misconfigured. An agent can fail while working exactly as designed, because the thing that steers it is text, and text arrives from everywhere.
Prompt injection
Agents inherit the weaknesses of the language model at their core. The Five Eyes guidance gives the example of a malicious prompt in a phishing email that convinces an email-monitoring agent to download malware. Every data source an agent reads, including web search, widens that surface.
Tool misuse under a trusted identity
An agent acting with an employee’s privileges is a new kind of operator that nobody vetted. The guidance describes the confused-deputy pattern: a trusted agent misused to do what its user could not, producing audit logs that look legitimate and delay detection. It calls strict least privilege critical.
Supply chain
Tools, plugins, MCP servers (Model Context Protocol) and other agents become part of the system. The guidance warns that unvetted third-party components can carry excessive privileges into agent workflows, and lists supply-chain tampering and poisoned environments among the ways a single compromised agent causes cascading failures.
Concentration
Many deployments call the same few model providers. The Financial Stability Board named “third-party dependencies and service provider concentration” as one of four AI-related vulnerabilities that could raise systemic risk in its November 2024 report. A provider outage, or a bad model update, reaches every operator that depends on it at once.
New failure states
The operational-technology principles put it plainly: integrating an AI system into an OT network inevitably creates new failure states for the whole system, and functional-safety and incident-response processes have to account for them.
What critical-infrastructure treatment requires
Operators do not have to wait for any of it. The controls critical systems already get can be applied to AI now, and most of the list below comes straight from the published guidance.
Industry is arriving at the same place. On October 10, 2026, Microsoft CEO Satya Nadella argued that frontier models should be treated as insider risks, not because they are malicious but because any capable actor with access to important systems can make mistakes or be compromised. He calls for “contained systems whose behavior we can observe, limits we can test” and whose actions can always be contained, with the controls kept outside the model. Observing is items 1 and 5 below, containing is item 3, and testing the limits is how you prove items 4 and 6 work.
1. Inventory
Know every AI component and every component that relies on one: assistants, coding agents, MCP servers, local models, the model APIs they call. The OT principles open their oversight section with exactly this, and with logging and monitoring each component’s inputs and outputs.
2. Least privilege and identity
Give each agent the minimum access for its role, limited in resources, operations and time, with short-lived credentials instead of long-lived secrets. The guidance warns that entitlements checked only once, at start-up, miss what the agent does later.
3. Control at the point of action
Decide each action before it runs. The Five Eyes guidance calls for human approval before high-impact actions such as system resets, network egress or deleting critical records, and for holding any request to delete logs until a person reviews it. A policy the agent can read but nothing enforces is advice.
4. Resilience and fallback
Plan for the AI system to be unavailable or wrong. The OT principles call for failsafe mechanisms that let AI fail gracefully and revert to traditional automation or manual operation; DHS asks for system redundancy. Decide now what happens when your model provider is down.
5. Evidence
Keep a record of what each agent was allowed to do, what it was refused and who approved what, in a form an auditor can trust and your SIEM can read. Logs that a compromised agent can alter are not evidence.
6. Incident response
DHS’s framework asks owners and operators to plan how to stop an AI system, start a backup, notify the authorities and customers, withdraw the AI’s access and roll it back. Write that runbook and rehearse it before you need it.
Where protection at the point of action fits
Every failure mode above ends the same way: an agent does something. A prompt injection becomes a tool call. A confused deputy becomes a command run under someone’s identity. A poisoned plugin becomes a connection to a host nobody approved. Whatever the model, provider or framework, the action is the one place a control sees all of them, and it is where items 3, 5 and 6 on the list are enforced or not.
When you evaluate a product for this layer, ask four things. Does it decide before the action runs, or report afterwards? Does it work whichever model produced the action? Who writes the policy, and can a user or the agent switch it off? Does the evidence leave your network, and with what content?
MoorAI is built for this layer; we call the category on-device AI detection and response. An endpoint agent checks each agent tool call before it runs, allowing, asking or blocking it against an 80-threat matrix, and an MCP gateway and a model proxy (Anthropic, OpenAI, Gemini and local Ollama) check remote tool calls and model responses. The console holds the AI inventory and signed policy, and keeps a hash-chained audit trail with SIEM export. It is content-free by default and runs air-gapped.
Its limits are as much a part of the answer. It governs the AI agents that can reach controllers and safety systems, not the controllers themselves; it does not test or certify models; and it does not keep a service running when its model provider fails. Those stay with your architecture and your suppliers. Treating AI as critical infrastructure means deciding who owns each of them, and writing it down.
Sources
- Sectors and definition. Critical Infrastructure Sectors, CISA.
- NIS2. NIS2 Directive, European Commission.
- UK data centres. Data centres designated Critical National Infrastructure, DSIT, September 12, 2024.
- Agentic AI. Careful adoption of agentic AI services, ASD’s ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK, May 1, 2026.
- AI in OT. Principles for the Secure Integration of AI in Operational Technology, CISA, ASD’s ACSC and partners, December 3, 2025.
- DHS framework. Roles and Responsibilities Framework for AI in Critical Infrastructure, DHS, November 14, 2024.
- EO 14148. Initial Rescissions of Harmful Executive Orders and Actions, Federal Register, January 28, 2025.
- US AI Action Plan. America’s AI Action Plan, The White House, July 2025.
- EU AI Act. Annex III, AI Act Service Desk, European Commission; Digital Omnibus on AI, European Parliament Legislative Train.
- EU action plan. EU Action Plan on Cybersecurity and Artificial Intelligence, European Commission, July 7, 2026.
- Models as insider risks. Models as Insider Risks in the Super Intelligence Era, Satya Nadella, sn scratchpad, October 10, 2026.
- Concentration. The Financial Stability Implications of Artificial Intelligence, Financial Stability Board, November 14, 2024.
- Critical ICT third parties. Digital Operational Resilience Act, Regulation (EU) 2022/2554, oversight of critical ICT third-party providers.
Some US federal pages linked here now say “super intelligence (SI)” where they used to say AI, following Executive Order 14434 of September 29, 2026. The documents themselves are unchanged.
See also: The layer above the model, Choosing an agentic security vendor, and How MoorAI protects AI apps and APIs.