AI in the Power Grid: What CISA’s New OT Guidance Actually Says

Two real documents now exist that address, specifically, what happens when AI meets the systems that keep the lights on, the water flowing, and the trains running. Neither is a law. Both come from CISA, working with an expanding circle of partner agencies, and both are narrower and more specific than the “AI is coming for critical infrastructure” headlines around them suggest. This guide covers what each document actually requires, why operational technology (OT) is treated as a distinct problem from ordinary IT security, and what the fact that eight other countries’ cyber agencies signed onto the first one is a signal of — and isn’t.

Why OT Is Not Just IT With Higher Stakes

The instinct to treat AI-in-OT as a bigger version of AI-in-IT is the mistake both documents are written to correct. The NIST Cybersecurity Framework and most enterprise AI-governance guidance assume an environment where a compromised system means data loss, downtime, or reputational damage — serious, but recoverable through backups and incident response. OT environments are built around a different failure mode. As CISA’s own December 2025 guidance puts it, OT systems “control physical systems that can harm people or property, such as systems that deliver biological or chemical agents, control operations for a dam or wastewater treatment, or automate the flow of vehicle traffic.” That is why the document defines “safety” throughout as functional safety — physical harm to people or property — and treats it as a distinct concern from information security, not a subset of it.

Three structural features of OT drive this distinction in practice. First, legacy: much of the installed base of programmable logic controllers, remote terminal units, and SCADA systems long predates modern AI, and wasn’t engineered with machine-learning inputs in mind. Second, uptime is not a service-level target but a safety requirement — an OT system that fails closed or fails open can itself be the hazard, in a way a frozen web app is not. Third, and most consequentially, an OT failure has a physical consequence in the world: a wastewater treatment error, a grid dispatch mistake, a mispositioned valve. That is the gap the “power grid” framing in this guide’s own title is pointing at — AI advising or acting on physical infrastructure, not just answering a chat prompt in an office IT stack.

Document One: Principles for the Secure Integration of AI in OT

Published December 3, 2025 (the PDF itself is dated January 2026), Principles for the Secure Integration of Artificial Intelligence in Operational Technology is co-authored by CISA and Australia’s ACSC, “in collaboration with” the NSA’s Artificial Intelligence Security Center, the FBI, and the national cyber agencies of Canada, Germany, the Netherlands, New Zealand, and the United Kingdom. It lays out four principles, each with several sub-sections of concrete practice:

• 1. Understand AI. Know the specific risks AI introduces into an OT environment before adopting it — the guidance flags OT process models “drifting” over time and safety-process bypasses as OT-specific failure modes that a generic AI-risk checklist won’t catch — follow a secure AI system development lifecycle, and train personnel accordingly.
• 2. Consider AI Use in the OT Domain. Build an actual business case for AI in OT rather than adopting it by default, manage the data-security risks specific to OT data, understand what role OT vendors play in the integration, and evaluate the practical challenges of connecting AI systems to OT.
• 3. Establish AI Governance and Assurance Frameworks. Put governance mechanisms in place, integrate AI oversight into existing security frameworks rather than building a parallel one, test and evaluate AI models on an ongoing basis, and account for the regulatory and compliance landscape specific to critical infrastructure.
• 4. Embed Safety and Security Practices Into AI and AI-Enabled OT Systems. Establish real-time monitoring and human oversight, and build in the safety and failsafe mechanisms — the ability to detect a bad AI-driven decision and override it before it reaches a physical process — that OT’s harm profile demands.

The document is also explicit about scope: it targets machine-learning and large-language-model-based AI and AI agents specifically, because those are the categories that introduce “more complex safety and security considerations” than the statistical modeling and rule-based automation OT engineering has used for decades. Its own risk table names AI-specific cybersecurity risks — prompt injection among them — alongside the point that traditional controls like access control, auditing, and encryption still apply on top of them, not instead of them.

Document Two: Careful Adoption of Agentic AI Services

Published May 1, 2026, Careful Adoption of Agentic AI Services is a second, separate CISA release — this one authored with Australia’s ACSC “and other international and U.S. partners,” per CISA’s own publication page. Where the December 2025 document is scoped to OT integration specifically, this one addresses agentic AI adoption more broadly: CISA describes it as outlining “key security challenges and risks associated with agentic AI” and providing “actionable steps for designing, deploying, and operating these systems safely,” aimed at helping organizations “align AI risk management with existing cybersecurity frameworks and strengthen oversight as agentic AI adoption grows.” The full text is hosted on the ACSC’s site rather than mirrored on cisa.gov, and was not reachable while drafting this guide, so the specifics of its risk categories and per-risk mitigations should be verified against the primary document directly, at CISA’s publication page, before being cited in detail.

What is confirmed is the relationship between the two documents: the December 2025 release is OT-specific guidance about AI generally, including agentic systems as one category among several; the May 2026 release is agentic-AI-specific guidance that applies across sectors, OT included. Read together, they cover the same underlying concern — AI systems that don’t just recommend an action but can initiate one — from two different starting points.

Nine Agencies, Seven Countries: A Multilateral Signal

The authoring list on the OT-integration document is worth reading in full, because the coalition is the part of this story that’s easy to undercount. It carries nine agency signatures across seven countries: the United States (CISA, the NSA’s AI Security Center, and the FBI — three separate agencies), Australia’s ACSC, the Canadian Centre for Cyber Security, Germany’s Federal Office for Information Security (BSI), the Netherlands’ NCSC, New Zealand’s NCSC, and the UK’s NCSC. That is a materially different thing than a single agency issuing best-practice advice. It is the same kind of multilateral cyber-agency alignment that produced the 2023 Guidelines for Secure AI System Development, and it signals that “how do you secure AI touching physical infrastructure” has moved from an open research question to something seven governments’ security agencies are prepared to co-sign a common position on — even though, as with that earlier guidance, none of it carries the force of regulation. Owners and operators are not required to follow it; nothing in either document creates an enforcement mechanism or a compliance deadline.

Where This Sits Next to NIKOLAI

CASRAI’s own NIKOLAI project — an independent, unendorsed reference dictionary of 64 elements used across frontier-AI-safety frameworks — tracks Risk Domain (element N1) as the top-level category a safety commitment is scoped to: a controlled list that includes CBRN, Cyber offense, loss of control, and harmful manipulation, drawn from how frontier AI labs and a handful of regulators actually define those categories in their own published frameworks. That element’s crosswalk table is worth reading alongside this guide, because it shows how differently the labs themselves treat “cyber” risk — Anthropic, OpenAI, Google DeepMind, xAI, and Meta each define it somewhat differently, and the EU’s GPAI Code of Practice and California’s SB 53 add two more regulatory readings on top.

Here is the distinction worth stating plainly rather than implying: neither CISA document appears as a mapped row in NIKOLAI’s Risk Domain crosswalk, and it would be inaccurate to suggest otherwise. NIKOLAI’s crosswalks track frontier AI developers and the regulators that have published a scoped framework governing them — the labs, the EU AI Act, SB 53, the U.S. government’s own capability-threshold work under Executive Order 14409 and NIST’s CAISI. CISA is a government security agency issuing operational cybersecurity guidance for critical-infrastructure owners and operators; it is adjacent territory to Cyber offense as a risk domain, not a framework NIKOLAI currently tracks or maps against. That is itself worth noting as a gap: none of the organizations NIKOLAI currently maps address OT or critical-infrastructure deployment specifically, which is exactly the space this CISA guidance occupies. Whether that becomes a tracked row in a future NIKOLAI release is an open question, not a current fact — and if it ever does, it would need its own verified crosswalk entry, not an inference from this guide.

For more on how NIKOLAI structures the rest of frontier-AI-safety terminology, the map of all ten NIKOLAI tracks is the starting point; for the compute and cyber-evaluation guidance already on CASRAI that this piece deliberately doesn’t overlap with, see compute governance and export controls (chip-level controls) and CAISI’s open-weight model cyber assessments (PRC-origin model evaluation) — both cover different mechanisms than the OT-deployment and agentic-AI-adoption guidance covered here.