AI in OT and Industrial Control Systems Security Guide

AI is moving into industrial control environments as predictive maintenance models, anomaly detectors, operator assistants and now agents, and every one of them needs data from the plant and, in the worst designs, a path back into it. In OT a wrong answer is not just a bad report: it can mean a wrong setpoint, a missed alarm or an unsafe state. In December 2025 CISA and partner agencies from Australia, Canada, Germany, the Netherlands, New Zealand and the UK, with the FBI and the NSA AI Security Center, published joint principles for the secure integration of AI in OT, and in April 2026 NIST began work on an AI RMF profile for critical infrastructure covering IT, OT and ICS. This guide turns that direction into architecture patterns, identity controls, monitoring and failure modes for asset owners. It is written for OT security engineers, control system engineers and the IT and data teams who bring AI to the plant. For the wider OT programme see the OT Security Guide and the OT Security Maturity Model.

Key takeaways

Decide the AI's authority first. Advisory AI (it tells a human) and closed-loop AI (it writes to the process) are different risk classes. Most organisations should keep AI advisory and let operators and existing safety systems act.
Move data out, not commands in. Send OT data outwards through a DMZ or a unidirectional gateway to where models run; do not open inbound paths from cloud or IT-hosted AI into control networks.
AI components are machine identities. Historian connectors, model service accounts, vendor cloud tokens and agent credentials need the same owner, scope and rotation discipline as any OT service account.
Safety systems stay independent. AI must never replace or bypass the safety instrumented system, interlocks or manual override.
Plan for the model being wrong. Drift, poisoned data and adversarial inputs are normal operating risks; define fallbacks, monitoring and how to take the model out of the loop quickly.

Where AI shows up in OT

Use	Typical data and location	Authority	Main risk
Predictive maintenance	Vibration, temperature, historian data; models in IT, DMZ or cloud	Advisory (work orders)	Operational data leaving site; poisoned or drifting models
Process optimisation and advanced control	Process variables; models near Level 2 or 3	Advisory or closed loop (setpoint recommendations or writes)	Unsafe setpoints; loss of operator understanding
Anomaly detection in OT monitoring	Network traffic and process data	Advisory (alerts)	False positives eroding trust; attacker evasion
Computer vision for safety and quality	Camera feeds at the edge	Advisory or interlock input	Misclassification, physical adversarial inputs
LLM operator and engineering assistants	Manuals, procedures, alarm text, sometimes live data	Advisory	Hallucinated procedures; prompt injection through documents; data disclosure
AI agents for engineering or operations tasks	Tool access to historians, ticketing, engineering workstations	Can act	Excessive agency; unattended changes to control logic or configuration
Vendor AI features in OT products	Data sent to vendor cloud	Varies	Hidden data flows and remote access paths

The joint principles organise the problem in four steps: understand AI (its risks in OT, staff education and the secure AI development lifecycle); consider AI use in the OT domain (the business case, OT data security risks, the role of vendors and integration challenges); establish AI governance and assurance frameworks (governance, integration with existing security frameworks, continuous testing and evaluation of models, regulatory compliance); and embed safety and security practices (oversight for safe operation, transparency, and AI in incident response plans).

Architecture patterns

Use the Purdue levels or IEC 62443 zones and conduits you already have; AI does not change the model, it adds new conduits. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Pattern	How it works	When to use	Trade-off
Outbound replication to IT or cloud	Historian replicated through the DMZ, or through a unidirectional gateway, to a model platform; results go to people, not back to controllers	Predictive maintenance, fleet analytics	Data residency and confidentiality of process data; latency
Edge or on-site inference	Model runs on a hardened server in the site DMZ or Level 3 zone	Latency-sensitive vision or anomaly detection; sites that must keep data local	Patching and model updates become OT change activities
Recommendation with operator acceptance	AI proposes setpoints in the HMI; an operator approves each change	Optimisation pilots	Approval fatigue; needs clear limits shown to the operator
Bounded closed loop	AI writes within engineered limits enforced by the control system, with automatic fallback to conventional control	Mature sites, well-understood processes, after long advisory phase	Highest assurance burden; needs process safety review

Prefer push from OT over pull from IT: an OT-side component that sends data out needs no inbound firewall rule. A cloud service that polls into the plant does.
Unidirectional gateways: where consequence is high, hardware-enforced one-way transfer removes the return path entirely. See the Data Diodes and Unidirectional Gateways Guide.
Write paths are conduits: any route by which AI output reaches a controller, even through an HMI or engineering workstation, must be documented as a conduit with its own security level target.

Where identity fits: AI components as OT machine identities

Each AI deployment adds non-human identities to the OT estate, and these are often created by data or vendor teams outside OT change control.

Historian and data connectors: read-only service accounts per connector, scoped to the tags needed, never shared with engineering tools. MITRE ATT&CK for ICS lists T0859 Valid Accounts among techniques adversaries use in OT, so every extra account is extra attack surface.
Model platform credentials: cloud keys or tokens used to push data or pull models should be short-lived, held in a vault and owned by a named team. See the Identity for OT Environments Guide.
Vendor remote access: AI features that need vendor support often bring remote connections (ATT&CK for ICS T0822 External Remote Services, T0886 Remote Services). Route them through your remote access platform with MFA (ATT&CK mitigation M0932) and session recording. See the OT Third-Party and Integrator Access Guide.
Agents: an AI agent that can open tickets, query historians or touch engineering workstations needs its own identity, an allow list of tools and read-only rights by default. Any write action should require operator approval. See the Human-in-the-Loop for AI Agents Guide.
Kill switch: revoking the AI's credentials and closing its conduit should take minutes and be rehearsed. See the AI Agent Kill Switch and Containment Guide.

Safety, assurance and governance

Business case and consequence: before any AI project, record what the model does, what decisions it informs and the worst credible consequence if it is wrong. Use your existing process hazard analysis and IEC 62443-3-2 risk assessment. See the IEC 62443 Guide.
Independence of safety layers: safety instrumented functions, interlocks and alarms stay outside the AI's reach. NIST SP 800-53 CP-12 Safe Mode is the relevant control concept: define the state the process falls back to when the AI is removed.
Operator competence: operators must be able to run the process without the AI and understand what it is recommending and why. The joint principles stress educating personnel on AI risks.
Testing before and after deployment: test models against historical upsets and edge cases, then monitor in production. The principles call for continuous testing and evaluation of AI models.
Change control: model retraining or replacement is a change to the control environment and goes through OT management of change, with rollback to the previous model version.
Vendor transparency: require suppliers to declare AI features, data flows, remote connectivity and model update methods. See the OT Product Procurement Guide.
Incident response: add AI scenarios (model producing unsafe recommendations, data leak through the AI platform, compromised AI credentials) to OT incident plans, as the principles recommend.

Implementation sequence

Inventory existing AI, including vendor features already switched on.
Pilot advisory use on one non-critical unit, with outbound-only data flow.
Measure model accuracy, false alarm rate and operator acceptance over a defined period.
Extend to more units only after review; consider operator-approved recommendations next.
Consider bounded closed loop only with process safety sign-off, engineered limits and tested automatic fallback; roll back by disabling the AI write path and reverting to conventional control.

OT data handling for AI pipelines

The joint principles list managing OT data security risks as part of deciding whether to use AI at all. Process data is often more sensitive than it looks: tag names, alarm limits and historian trends describe how a plant works and where it is fragile.

Minimise: send only the tags and time ranges a model needs. A predictive maintenance model for pumps does not need the whole historian.
Classify and locate: record where OT data is stored once it leaves the site (region, provider, retention) and who at the vendor can read it.
Restrict vendor reuse: contracts should say whether a vendor may use your process data to train shared models.
Protect the return path: model files and configuration pushed back to edge devices are software updates. Sign them and verify integrity before loading (SP 800-53 SI-7).
Keep provenance: record which data trained which model version, so a suspected poisoning or bad sensor period can be traced and the model retrained.

Small sites and large operators

Small sites and single-plant operators: usually consume AI through vendor products. Focus on procurement questions, an outbound-only data path and making sure vendor connectivity goes through your own remote access controls.
Large or multi-site operators: often build central AI platforms. Standardise one approved data export pattern per site, a central register of AI connectors and credentials, and a common review for any proposal that adds a write path.
Critical infrastructure under regulation: map AI changes to the sector's existing OT security obligations and keep evidence of the consequence assessment and safety review.

Threats specific to AI in OT

Threat	Effect in the plant	Reference	Control
Manipulated AI output leading to wrong actions	Operators or control logic act on false recommendations	ATT&CK for ICS T0831 Manipulation of Control, T0832 Manipulation of View	Advisory only; engineered limits; independent safety layers
Theft of process data through AI pipelines	Loss of recipes, process know-how, site layouts	ATT&CK for ICS T0882 Theft of Operational Information	Data minimisation, encryption, contractual limits on vendor use
Internet-exposed AI or vendor connectors	New entry point to OT	ATT&CK for ICS T0883 Internet Accessible Device	No inbound paths; DMZ brokers; M0930 Network Segmentation, M0937 Filter Network Traffic
Poisoned training or historian data	Model learns to ignore real faults	MITRE ATLAS AML.T0020 Training Data Poisoning	Data provenance, validation against physics and known events
Adversarial or physical inputs to vision models	Safety camera misses a person or defect	MITRE ATLAS AML.T0015 Evade AI Model	Multiple sensors (ATLAS AML.M0009); vision never the sole safety input
Prompt injection into OT assistants	Assistant gives altered procedure or leaks data	OWASP LLM01:2025 Prompt Injection	Curated document sources; no tool write access; human verification. See the Prompt Injection Guide
Loss of safety	Unsafe state reached	ATT&CK for ICS T0880 Loss of Safety	SIS independence; CP-12 safe mode

Detection and measurement

Conduit monitoring: watch every AI-related conduit in your OT network security monitoring, alerting on any inbound connection or new protocol. See the OT Network Security Monitoring Guide.
Credential use: alert on AI service accounts used outside their expected hosts, hours or tags, and on any write attempt by a read-only connector.
Model behaviour: track drift between model predictions and measured outcomes, and sudden changes in recommendation patterns.
Operator overrides: a rising override rate means the model is losing accuracy or trust.

Metrics:

Share of AI uses with a documented authority level, consequence assessment and owner (target 100%).
Number of inbound connections from IT or cloud AI services into OT zones (target zero).
Share of AI service accounts that are read-only, vaulted and rotated.
Model accuracy and false alarm rate per unit, reviewed monthly.
Time to remove the AI from the loop in exercises.

Framework mapping

Area	Reference
AI risk governance	NIST AI RMF 1.0 (GOVERN, MAP, MEASURE, MANAGE); planned NIST AI RMF critical infrastructure profile
Segmentation and conduits	NIST SP 800-53 SC-7 Boundary Protection; CSF 2.0 PR.IR-01; ATT&CK for ICS M0930
Remote and vendor access	SP 800-53 AC-17; ATT&CK for ICS M0932, M0801 Access Management
Least functionality for AI hosts	SP 800-53 CM-7
Model and software integrity	SP 800-53 SI-7
Supplier AI features	SP 800-53 SR-3; CSF 2.0 GV.SC-05
Safe fallback	SP 800-53 CP-12 Safe Mode

Common failure patterns

Cloud analytics that pull from the plant: a vendor platform given an inbound connection or VPN into Level 3 to read the historian, creating a permanent remote path.
Shared connector accounts: one historian account used by the AI platform, reporting tools and an integrator, so nobody can scope or rotate it.
Silent move from advisory to control: a pilot that started as recommendations gains a write path "to save operator time" without process safety review.
Vision used as the only safety input: a camera model treated as a guard when it should supplement physical safeguards.
Models never retired: a model trained before a plant modification keeps running, giving confident but wrong outputs.
OT assistants with uncurated sources: an LLM assistant that indexes shared drives and email, so outdated or tampered procedures appear as answers.

Lessons from incidents

No incident in the NHI Mgmt Group breach database has yet been confirmed as an AI system causing or enabling an OT compromise, so none is linked here. The relevant lessons today come from conventional OT incidents: remote access paths and shared or default credentials are the recurring entry points, and every AI integration that adds a connector or vendor link adds to them. The NIST SP 800-82 OT Security Guide covers those baseline controls.

Practitioner checklist

Inventory every AI use in OT, including vendor features, with owner, authority level and consequence.
Keep AI advisory by default; require process safety review before any write path.
Move data outwards through the DMZ or a unidirectional gateway; allow no inbound AI connections.
Give each AI connector, platform and agent its own scoped, vaulted credential.
Keep safety instrumented systems and interlocks independent of AI.
Treat model updates as OT changes with tested rollback.
Monitor AI conduits, credential use, drift and operator override rates.
Add AI scenarios to OT incident response and rehearse removing the AI from the loop.
Require suppliers to declare AI features, data flows and remote connectivity.

AI in OT and Industrial Systems Guide: Safe Adoption Patterns for ICS Operators