AI security for critical infrastructure is an emerging operational risk that most energy and utility organizations are not prepared to address. The energy sector deployed AI faster than it deployed AI security controls, and attackers have noticed.
Only 9% of energy organizations conduct AI-specific red teaming, compared to 24% globally, according to Kiteworks research. Only 14% maintain AI-specific incident response playbooks. Meanwhile, nation-state actors like Volt Typhoon have been pre-positioned inside U.S. OT networks since at least 2021, and AI now gives them capabilities that living-off-the-land (LOTL) techniques alone never provided.
This guide covers the AI attack vectors specific to energy and utility AI deployments: why existing standards like NERC CIP and IEC 62443 do not address them, what the regulatory landscape looks like heading into 2026, and what a defensible AI security posture for critical infrastructure actually requires.
Key Takeaways
- U.S. utilities faced 1,162 cyberattacks in 2024, a 70% increase from the prior year, and nation-state OT attacks doubled in 2025.
- New AI-specific attack vectors in OT, including prompt injection to SCADA and adversarial evasion of AI anomaly detection, bypass all controls in current NERC CIP and IEC 62443 standards.
- Only 9% of energy organizations red-team their AI systems, and only 14% have AI-specific incident response playbooks.
- CISA published joint guidance on securing AI in OT environments in December 2025. NIST released a concept note for an AI RMF Critical Infrastructure Profile in April 2026.
- Predictive model poisoning attacks on grid forecasting AI can force deviations beyond the 5% threshold for safe grid operation without triggering any existing alarm.
- AI agents with OT tool access create a new cross-zone attack surface that IEC 62443 security zone architecture was not designed to contain.
Why Critical Infrastructure AI Is Uniquely Exposed
The energy sector uses AI across a wider attack surface than most industries realize. AI now appears in predictive maintenance for turbines and transformers, demand forecasting and load balancing, anomaly detection for both IT and OT networks, AI-assisted operations consoles that summarize alerts, natural language interfaces to grid management tools, and digital twin simulations for planning and response exercises.
Each of these deployments creates AI attack surface that did not exist in 2020. The challenge is that every one of them touches operational technology. A compromised AI system in a retail environment leaks data. A compromised AI system in an energy utility can cause physical consequences: equipment damage, localized outages, or, in the worst case, cascading grid failures.
Traditional OT security is built around the principle of isolation: air gaps, security zones, conduits, strict network segmentation as defined in IEC 62443. That architecture worked when operators accessed OT systems directly. It does not work when an AI agent operating with legitimate operator credentials becomes the access pathway.
The IT/OT convergence that digitalization has accelerated over the past five years means that AI systems increasingly span both domains. A single AI model that ingests IT telemetry and generates OT commands creates a logical bridge that bypasses the physical security zone architecture entirely. IEC 62443 security zones and conduits cannot contain a threat that travels through an authorized AI agent.
The Critical Infrastructure AI Threat Landscape
Prompt Injection via AI-Assisted Operations Tools
The most immediately dangerous threat vector is prompt injection targeting AI agents that have tool access to OT systems.
In practice, the pattern works like this: an operations engineer uses an LLM-based tool (connected to OT systems via MCP or a custom integration) for a routine task: summarizing maintenance reports, querying sensor data, or drafting work orders. An attacker has placed a malicious PDF on a shared drive, in an email attachment, or in a log file that the AI will process. The PDF contains hidden instructions in white-on-white text or as encoded strings that are invisible to the human reviewer but parsed by the AI.
The AI reads the hidden instructions and executes them using its legitimate operator credentials. It issues a command to modify SCADA parameters as a "maintenance update." Traditional OT security controls do not fire: the network sees legitimate credentials, legitimate protocol, legitimate source address. There are no malware signatures to detect because no malware was used.
This is not theoretical. Research published in MDPI Information (2026) documented this exact attack pattern against LLM agents with OT system access. MITRE ATLAS v5.4.0 catalogues this as AML.T0051 (LLM Prompt Injection) combined with AML.T0054 (Agent Context Poisoning). OWASP LLM Top 10 2025 places Prompt Injection at LLM01 and Excessive Agency at LLM06, both directly applicable here.
The root cause is that AI agents operating in OT environments are granted trust that the OT security architecture never anticipated. An agent authorized to read sensor data may also have write access to control parameters, because least-privilege scoping for AI agents is not part of any current OT security standard.
See our detailed coverage of indirect prompt injection defense strategies and the broader OWASP Agentic Top 10 framework for the full taxonomy of agentic AI threats.
Adversarial Evasion of AI-Based Anomaly Detection
Many energy organizations have deployed ML-based anomaly detection as a security control: the AI monitors operational parameters and triggers alerts when readings deviate from learned baselines.
Attackers are now targeting the AI defense itself.
Academic research published in 2025 demonstrated that adversarial sample generation techniques adapted for ICS time-series data achieved 100% evasion of SVM-based intrusion detection classifiers and 96% evasion of decision trees in industrial control system environments. The adversarial inputs kept all monitored operational parameters (temperature, pressure, voltage, flow rates) within normal ranges while the malicious operation executed in the background.
The implication is significant: deploying AI for OT anomaly detection does not automatically improve security posture if the AI can be blinded. Adversaries who have studied the deployed model can craft inputs that are statistically indistinguishable from normal operation. This is the adversarial ML problem described by MITRE ATLAS techniques AML.T0015 (Evade ML Model) and AML.T0016 (Craft Adversarial Data), and it applies directly to AI security controls in critical infrastructure.
Predictive Model Poisoning for Grid Stability Attacks
Grid operators use AI models for demand forecasting, load balancing, and real-time grid optimization. These models are trained on historical operational data: load profiles, weather data, equipment telemetry, and consumption patterns.
Data poisoning attacks corrupt training data before or during model training. Three primary poisoning techniques apply here: label poisoning (mislabeling normal operating states as anomalous or vice versa), feature poisoning (injecting corrupted sensor readings into the training dataset), and sample poisoning (inserting fabricated data points that shift the model's learned decision boundary).
Research on smart grid AI has shown that poisoning attacks can force prediction deviations beyond the 5% threshold for safe electric energy grid operation. The 5% figure is not arbitrary: it is the operational safety limit for load imbalance. Deviations beyond this threshold cascade: load balancers cannot compensate, frequency deviates, protection systems activate, and targeted sections of the grid are isolated.
Unlike IT data poisoning attacks, the consequences here are physical. The attack does not exfiltrate data. It degrades the AI model's accuracy in a controlled way, causing operational failures at a time and location of the attacker's choosing. MITRE ATLAS catalogues this as AML.T0020 (Poison Training Data). NERC CIP-010 (Configuration Change Management) covers configuration of the underlying systems but does not address integrity of AI training pipelines.
AI Model Supply Chain Compromise
Energy and utility organizations are increasingly downloading pre-trained AI models from public repositories for predictive maintenance, anomaly detection, and operational analytics. Each downloaded model represents a supply chain trust assumption.
The Model Namespace Reuse attack, documented by Palo Alto Unit42, demonstrates the risk: attackers register abandoned or typosquatted namespaces on Hugging Face and publish malicious models with names that infrastructure pipelines are already configured to retrieve. Any deployment pipeline that references models by name rather than cryptographic hash will silently pull the malicious version.
The NullBulge supply chain campaign demonstrated the full kill chain: weaponized models delivered via Hugging Face installed Python payloads that deployed LockBit ransomware. Energy sector AI deployments that rely on public model repositories without integrity verification are exposed to this vector.
This connects to a broader supply chain AI risk covered in our AI model supply chain security guide, which documents how MITRE ATLAS AML.T0010 applies across industry sectors. NERC CIP-013 (Supply Chain Risk Management) covers vendor risk but was written for hardware and software procurement, not for AI model downloads from open repositories.
Nation-State AI-Assisted Pre-Positioning
Volt Typhoon (People's Republic of China) has used living-off-the-land techniques to maintain persistent access inside U.S. critical infrastructure since at least 2021. CISA Advisory AA24-038A confirmed access across energy, communications, transportation, and water sectors.
The critical evolution is what AI adds to this capability. AI-assisted reconnaissance, automated lateral movement planning, and AI-generated attack tooling lower the barrier and accelerate attacker velocity. The average attacker dwell time in OT environments exceeds 200 days. An adversary with AI-assisted capabilities can accomplish in days what previously required months of manual analysis.
The 2026 Annual Threat Assessment from the Office of the Director of National Intelligence explicitly identifies China, Russia, Iran, and North Korea as treating U.S. critical infrastructure as a "standing battlespace," with AI as a force multiplier for both reconnaissance and attack operations.
Regulatory Landscape: What Has Changed in 2025-2026
CISA Joint Guidance: Principles for Secure AI in OT (December 2025)
The most significant regulatory development for AI security in critical infrastructure is the joint guidance published on December 3, 2025, co-authored by CISA, NSA, FBI, Australian ASD, UK NCSC, Canadian CCCS, German BSI, Dutch NCSC, and New Zealand NCSC.
"Principles for the Secure Integration of Artificial Intelligence in Operational Technology" establishes four governing principles: understand your AI, assess AI use in OT, establish AI governance, and embed safety and security. It explicitly addresses ML systems, LLMs, and AI agents in OT contexts, and it acknowledges that AI in OT is fundamentally different from AI in IT environments.
This guidance is the authoritative international consensus on how to approach AI security in industrial environments. It is not yet codified as regulation, but it represents the direction of future compliance requirements.
NIST AI RMF Critical Infrastructure Profile (April 2026)
On April 7, 2026, NIST released a concept note for a "Trustworthy AI in Critical Infrastructure Profile" of the AI Risk Management Framework. This profile aligns the AI RMF with NIST SP 800-82 (Industrial Control System Security) and addresses the operational realities of OT environments: legacy systems, safety constraints, distributed infrastructure, and the need for continuous availability.
Organizations already implementing the NIST AI RMF for enterprise AI should begin mapping their OT AI deployments to this emerging profile now, before it becomes a compliance requirement.
NERC CIP and the AI Gap
NERC CIP standards have been updated for 2026. CIP-003-9, with an April 1, 2026 effective date, addresses security management controls for lower-risk bulk electric system environments. CIP-012-2 protects real-time operational data. CIP-015 (emerging) will address internal network security monitoring.
None of these standards contain AI-specific controls. The NERC CIP Roadmap published in January 2026 calls for a "risk-driven evolution" treating the framework as an "adaptable defense system," which signals future AI provisions, but they do not exist yet.
The practical consequence: organizations subject to NERC CIP must manually map AI-specific threats to existing CIP controls. AI training pipeline integrity maps imperfectly to CIP-010 (Configuration Change Management). AI agent access maps imperfectly to CIP-005 (Electronic Security Perimeters) and CIP-007 (Systems Security Management). There is no CIP standard that addresses prompt injection, adversarial evasion of AI anomaly detection, or AI model supply chain compromise.
IEC 62443 and AI Agent Cross-Zone Threats
IEC 62443 organizes OT security into security zones with defined levels of trust and communication rules between zones. Zone 3 (operations) communicates with Zone 2 (supervisory) through a defined conduit. Zone 2 communicates with Zone 1 (basic control) through another defined conduit.
AI agents violate this architecture when they span zones. An AI agent operating in Zone 3 that has tool access to Zone 2 or Zone 1 systems creates a logical connection that bypasses the conduit controls. Prompt injection into that agent is effectively a Zone 3-to-Zone 1 breach via an authorized pathway, which IEC 62443 zone architecture cannot prevent.
Defense Framework for Critical Infrastructure AI
Principle 1: AI Agent Least Privilege in OT Environments
Every AI agent deployed in or adjacent to OT environments must have its tool access scoped to the minimum required for its function. An agent that reads sensor data should not have write access to control parameters. An agent that generates maintenance reports should not have API access to the SCADA historian.
This sounds obvious, but it requires a deliberate review of every AI agent's authorization scope. Most AI deployments in energy organizations inherit permissions from the operator account used for deployment, not a purpose-scoped service account. The review process maps directly to OWASP LLM06 (Excessive Agency) remediation.
Principle 2: Untrusted Input Sanitization for OT-Adjacent AI
Every document, log, email, or data feed that an AI agent processes in an OT context is a potential prompt injection vector. Sanitization must occur before AI processing, not as a post-hoc filter.
Practical controls include: stripping or encoding content that could contain instruction syntax from PDFs and documents before AI processing, maintaining separate AI agent instances for document processing and OT command execution (no shared context between untrusted input processing and OT tool use), and implementing a human-in-the-loop approval gate for any AI-generated OT command before execution.
Principle 3: AI Training Data Integrity for Operational Models
ML models used in grid operations (demand forecasting, anomaly detection, predictive maintenance) must have verifiable training data provenance. Controls include: cryptographic signing of training datasets at collection time, outlier detection in training batches to flag potential data poisoning, separate validation datasets isolated from production data collection pipelines, and regular model behavioral testing against known-clean baselines.
Only 27% of energy organizations currently encrypt AI training data, according to Kiteworks research. Encryption is a floor, not a ceiling. Integrity verification of training data is the control that addresses poisoning attacks.
Principle 4: AI-Specific Incident Response for OT
Standard OT incident response playbooks do not cover AI-specific scenarios: how to identify a compromised AI agent, how to isolate an AI model that may have been poisoned, how to roll back AI-generated OT changes, and how to preserve forensic evidence from an AI system while maintaining operational continuity.
Only 14% of energy organizations currently have AI-specific incident response playbooks. Building one means extending existing OT IR procedures with AI-specific runbooks: prompt injection indicators (unexpected AI-generated commands, unusual API call patterns), anomaly detection evasion indicators (behavioral shifts in monitored equipment that do not trigger AI alerts but are noticed by human operators), and model integrity indicators (prediction accuracy degradation against held-out validation data).
Principle 5: Supply Chain Verification for AI Models
Every AI model deployed in critical infrastructure should be:
See our AI gateway and supply chain security guide for implementation patterns applicable to critical infrastructure AI deployments.
Principle 6: AI Red Teaming in OT Replica Environments
Red teaming AI systems in live OT environments is not feasible: the risk of disruptive test outcomes is unacceptable. The correct approach is to build an isolated OT replica environment (a digital twin or staging environment that mirrors the live OT architecture) and conduct AI security testing against that replica.
Test cases for OT AI red teaming include: prompt injection via every document type that AI agents process in production, adversarial inputs against AI anomaly detection (adapted for the specific ML models deployed), supply chain integrity tests (deploy a test model with a known payload to verify detection), and agentic excessive agency scenarios (verify that an agent with read access cannot execute write operations even under adversarial prompting).
This is what AI-native security assessment for critical infrastructure looks like. Generic AI application testing that targets LLM chat interfaces is not the same thing.
The Gap Between Current Practice and What Is Required
The data is clear. Only 9% of energy organizations conduct AI red teaming. Only 32% have board-level AI governance. Only 18% have an AI data gateway. These figures come from the same sector where U.S. utilities faced 1,162 cyberattacks in 2024 and where nation-state actors have maintained persistent OT access for years.
The regulatory gap is also clear. NERC CIP, IEC 62443, and existing DOE guidance were not designed for AI agents with OT tool access, adversarial ML attacks on grid forecasting models, or supply chain model compromise. The DOE Office of Inspector General explicitly identified the lack of an enterprise-wide AI and cybersecurity framework as a top management challenge for FY2026.
The CISA December 2025 guidance and the NIST AI RMF Critical Infrastructure Profile concept note represent the direction regulators are moving. Organizations that begin implementing AI-specific security controls now, before those frameworks become compliance mandates, will be better positioned than those waiting for the regulations to arrive.
Conclusion
Securing AI in critical infrastructure is not the same problem as securing AI in an enterprise SaaS environment. The attack vectors are different (prompt injection to SCADA, adversarial evasion of AI anomaly detection, predictive model poisoning), the consequences are different (physical outcomes versus data exposure), and the regulatory environment is different (NERC CIP, IEC 62443, and the emerging CISA/NIST frameworks).
The energy and utility sector is underinvesting in AI security relative to the risk. Nation-state actors are already using AI as a force multiplier. The window for proactive remediation is narrower than most organizations realize.
If you operate AI systems in an energy, utility, or critical infrastructure environment, the starting point is an AI security assessment that specifically tests the OT-facing AI attack surface. That means testing AI agents that have tool access to operational systems, verifying training data integrity for grid AI models, and reviewing the scope of AI agent authorization across your OT zones.
Request an AI security assessment to evaluate your critical infrastructure AI systems against the current threat landscape, or run a preliminary scan to identify exposed AI endpoints in your environment.
Further Reading
AI Security Audit Checklist
A 30-point checklist covering LLM vulnerabilities, model supply chain risks, data pipeline security, and compliance gaps. Used by our team during actual client engagements.
We will send it to your inbox. No spam.
BeyondScale Team
AI Security Team, BeyondScale Technologies
Security researcher and engineer at BeyondScale Technologies, an ISO 27001 certified AI cybersecurity firm.
Want to know your AI security posture? Run a free Securetom scan in 60 seconds.
Start Free Scan
