Executive summary

The convergence of Information Technology (IT) and Operational Technology (OT) has now entered a critical new phase with the integration of Artificial Intelligence (AI). While AI does offer transformative advancements in predictive maintenance, process optimization, and asset management, they also introduce deep systemic risks when introduced to deterministic, safety-critical Cyber-Physical Systems (CPS) without guardrails.

This article examines the structural, operational, governance, and cybersecurity risks associated with deploying AI platforms within industrial environments. Using the public technical profile of frontier AI architectures such as Anthropic’s Claude Mythos (introduced in early 2026), we will try and distinguish between the vulnerabilities that are inherent to any operational AI model and the specific risk vectors introduced by agentic, autonomous security-research models capable of automated exploit generation. For asset owners, Chief Information Security Officers (CISOs), and plant managers, navigating this shift mandates moving well past an IT-centric security models and establishing an engineering-aligned, zero-trust approach to industrial AI governance.

The idea is not to discourage AI usage but to understand the risks so that a mitigation strategy can be put in place to address them.

Why OT environments are fundamentally different from IT

The fundamental error made by enterprise security teams when deploying modern software, including AI, is treating an industrial facility like a corporate data center. The operational parameters, constraints, and risk tolerances are diametrically opposed.

In an IT environment, a software malfunction or unexpected output results in a crashed application, a hung process, or data corruption that can often be resolved via an automated reboot (did you switch it off and turn it back on?) or a backup restoration. In an OT environment, unexpected behavior at Level 2 (Control) or Level 1 (Sensing/Actuation) of the Purdue Model can drive a physical process past its safe operating limits. This could result in the form of equipment damage, catastrophic physical failure, or compromised human safety.

The expanding role of AI in industrial operations

Industrial operators are increasingly leveraging AI across two distinct vectors:

• Operational AI engines: Deployed inside or adjacent to Manufacturing Execution Systems (MES), Distributed Control Systems (DCS), and Data Historians to analyze massive streams of telemetry. These platforms optimize fuel-to-air ratios in turbines, predict valve failures, and adjust chemical dosing levels in real time.

• Frontier Agentic AI Platforms (The Mythos Disruption): Frontier architectures like Anthropic’s Claude Mythos represent a shift from passive text generation to autonomous and multi-step reasoning. Publicly documented capabilities of Mythos include autonomous zero-day discovery, codebase analysis, recursive self-correction, and the ability to execute code directly via sandboxed tool integration.

While platforms like Mythos are built for defensive or offensive security research in IT, the underlying capability that uses large language models (LLMs) to read code, form operational hypotheses, and directly interface with system tools, signals a reality where autonomous code analysis can (theoretically) be directed at legacy industrial software, vendor firmware, and PLC logic.

Key operational risks of introducing AI into OT

Loss of deterministic operations

Industrial Control Systems (ICS) depend on deterministic behavior: for a given set of inputs, a programmable logic controller (PLC) or safety instrumented system (SIS) must execute the same mathematically predictable sequence within a strict time window, often measured in milliseconds.

AI models, particularly neural networks and LLMs, are inherently stochastic and operate on probabilistic weights. Introducing an AI engine into the decision loop or allowing it to write configurations directly to field devices eliminates determinism, substituting predictable control logic with variable, non-repeatable algorithmic outcomes.

Safety implications

If an AI platform is integrated into a control loop (either directly or via a poorly isolated engineering workstation) an algorithmic edge case can trigger physical safety incidents that may go out of control in a short period of time. Unlike traditional advanced process control (APC) algorithms, which operate within strictly bounded mathematical matrices, deep learning models can generate unexpected anomalous commands when exposed to novel operational telemetry (out-of-distribution data).

Incorrect recommendations affecting production

Even when restricted to an advisory role (human-in-the-loop), AI tools can misinterpret sensor drift, calibration errors, or unusual process upsets as normal operations or standard optimization opportunities. An engineer executing an unvalidated recommendation from an AI regarding setpoint adjustments can induce stall conditions in compressors, thermal stress in cracking towers, or over-pressurization in pipelines.

Human overreliance (automation bias)

As AI platforms achieve high baseline accuracies, control room operators and plant engineers fall victim to automation bias, the tendency to trust automated suggestions blindly over human situational awareness. Over time, this erodes institutional troubleshooting expertise. When the AI encounters a rare process exception and provides catastrophic advice, operators may lack the immediate context or confidence to override the system.

Process integrity risks

Industrial processes require strict adherence to chemical, thermal, and mechanical equilibrium. Minor adjustments to a single variable cascade across multiple unit operations. Because general AI platforms lack an intrinsic understanding of physics, thermodynamics, and fluid dynamics, their optimization recommendations are derived from data correlations rather than physical laws, introducing hidden risks to physical process integrity.

Cybersecurity Risks

Increased attack surface and integration risks

Deploying an AI platform requires ingesting massive volumes of operational data. To achieve this, integrations are built between the AI environment and critical Level 3/2 assets, including:

• Data Historians (such as AVEVA PI System)

• Supervisory Control and Data Acquisition (SCADA) servers

• Distributed Control Systems (DCS)

• Engineering Workstations running PLC programming software

Every API endpoint, database connector, and software agent deployed to extract this data serves as a new potential entry path for threat actors. If the AI platform is hosted in the cloud, it effectively establishes a continuous, bi-directional path traversing the industrial DMZ directly from Level 3/2 into the public cloud, invalidating traditional network isolation models.

[Level 1/2: PLCs & SCADA] <--> [Level 3: Data Historian] <--> [OT DMZ Gateways] <== (AI Data Pipeline) ==> [Cloud-Hosted AI Platform]

Credential management and privilege escalation

AI agents operating within the OT environment require access credentials to query databases or push optimization profiles. If these credentials are improperly secured or hardcoded into AI service accounts, a compromise of the AI application allows an attacker to harvest highly privileged OT credentials. With these credentials, attackers can pivot directly to engineering workstations or SCADA runtime environments.

Supply chain and Third-Party software risks

Modern AI platforms are built on complex open-source software stacks, incorporating hundreds of Python libraries, vector databases, and orchestration frameworks (e.g., LangChain). These dependencies introduce deep supply chain vulnerabilities. A single malicious package or unpatched dependency within the AI platform's ecosystem can expose the entire attached industrial network to remote code execution (RCE).

Data leakage

Operational telemetry contains highly sensitive information regarding production volumes, chemical formulations, mechanical weak points, and proprietary manufacturing steps. If a cloud-based AI model utilizes this data for continuous training or retrains on user prompts without strict data isolation boundaries, proprietary industrial intelligence can leak into the public domain or be exposed in multi-tenant environments.

Prompt injection and AI manipulation

If an adversary gains a foothold on an IT network or a Level 3 asset, they can manipulate the inputs fed into the operational AI platform. Through indirect prompt injection—such as injecting malicious data payloads into log files or historian records that the AI parses—the attacker can alter the AI’s reasoning. This forces it to output corrupted optimization parameters, bypass built-in safety boundaries, or misclassify critical system alerts.

Lateral movement and the impact of Mythos-class capabilities

The emergence of platforms like Claude Mythos highlights an accelerated risk vector for lateral movement inside OT networks. Legacy industrial networks are historically flat, relying on perimeter defenses rather than internal segmentation. If an advanced, agentic AI platform—or an adversary utilizing equivalent autonomous exploit-generation tooling—gains access to an OT jump host or an active Active Directory domain controller, it can autonomously:

• Discover undocumented PLCs, remote terminal units (RTUs), and human-machine interfaces (HMIs).

• Decompile or reverse-engineer proprietary vendor binaries and firmware using native tool integration.

• Identify legacy software flaws (such as decades-old buffer overflows or unauthenticated protocols).

• Construct and execute multi-vulnerability exploit chains in minutes to achieve complete control over the physical process layer.

Compliance and regulatory considerations

Asset owners must evaluate industrial AI deployments against mandatory and voluntary cybersecurity frameworks to maintain compliance and protect their operational licenses.

ISA/IEC 62443 standard suite

The ISA/IEC 62443 framework provides the foundational methodology for securing industrial automation and control systems (IACS). AI systems must be evaluated across several specific parts:

• IEC 62443-3-2 (Zones and Conduits): Any AI platform must be assigned to its own distinct logical security zone. All communication flows between the AI zone and the operational assets (PLCs, Historians) must be funneled through strictly defined, monitored, and firewalled conduits.

• IEC 62443-3-3 (System Security Requirements): The integration must enforce strict access control, data integrity, and resource availability, ensuring the AI cannot exhaust network or processing resources needed by real-time control applications.

• IEC 62443-4-1 / 4-2 (Product Lifecycle and Component Security): Industrial AI software vendors must demonstrate a secure development lifecycle, including rigorous software bill of materials (SBOM) management to mitigate supply chain risks.

NIST SP 800-82 Rev. 3 (Guide to OT Security)

The newly updated NIST SP 800-82 Rev. 3 details safety and security requirements for cyber-physical systems. It mandates that any advanced analytical or automated platform deployed adjacent to an ICS must not impair safety-critical functions. It explicitly requires rigorous risk management processes before connecting analytical tools to operational layers, emphasizing network segmentation and continuous monitoring of configuration deviations.

NIS2 Directive (European Union)

Under the NIS2 Directive, organizations managing critical infrastructure (energy, transport, water, manufacturing) face strict supply chain security and risk-management obligations. Introducing unvetted AI engines that process operational data or provide control feedback without comprehensive third-party risk assessments can result in severe non-compliance penalties, as NIS2 places direct personal liability on corporate leadership for security failures.

Questions every OT security team should ask before deploying AI

Before any AI platform is granted access to operational data, the security and engineering teams must demand formal answers to the following questions:

• Where does the data reside? Is the AI model executed entirely on-premise within an air-gapped or localized edge server, or does it require outbound connectivity to a cloud environment?

• What are the precise read/write permissions? Does the platform operate strictly in a read-only capacity relative to the data historian/SCADA, or does it possess programmatic write privileges to modify setpoints, configurations, or logic parameters?

• How is the data isolated? If a cloud model is utilized, is our operational data isolated within a dedicated single-tenant instance, and is it explicitly excluded from the vendor's model retraining datasets?

• What is the fail-safe mechanism if the AI platform disconnects or malfunctions? Will the physical process immediately default to a known, safe, deterministic state governed purely by local PLC logic without operational disruption?

• How are the software dependencies of the AI stack managed? Can the vendor provide a verified, regularly updated Software Bill of Materials (SBOM) for the entire AI application stack, including open-source libraries?

Risk assessment checklist

The following framework should be executed during the engineering design phase of any industrial AI project:

Mitigation strategies and secure AI adoption best practices

To integrate AI capabilities without compromising the safety and resilience of critical infrastructure, organizations should adopt the following operational best practices.

Implement strict unidirectional data diodes

For AI platforms focused on predictive maintenance and operational optimization, enforce a physical or cryptographic unidirectional architecture. Use hardware-based data diodes to replicate real-time telemetry from Level 2/3 historians up to the AI platform hosted in the corporate zone or cloud. This ensures the AI platform can ingest and analyze data, but remains physically incapable of sending any packet or command back down into the control network.

Isolate the Core Identity Architecture

Never allow an AI platform to leverage corporate or shared Active Directory credentials that span across both IT and OT assets. Deploy a dedicated, standalone OT Active Directory forest with zero trust relationships extending to the corporate network. AI service accounts must be restricted exclusively to the specific database instances they require, preventing them from being used as lateral movement vectors.

Establish immutable out-of-band backups

Because autonomous exploit-generation capabilities compress the defensive window for patching, organizations must guarantee their ability to recover from a worst-case compromise. Implement an immutable backup strategy for all PLC logic files, SCADA runtimes, DCS configurations, and HMI images. Backups must be stored completely out-of-band and offline, with regular, validated restoration drills executed by plant engineering teams.

Air-gap engineering workstations

The engineering workstation is the most high-value target within an industrial facility because it dictates the logic written to the PLCs. These systems must be strictly isolated from standard corporate applications, email, internet access, and any analytical AI software stacks. Software or logic modifications should be governed by a rigorous change-control process involving physical, media-scanned USB inputs or dedicated, highly-monitored transfer gateways.

Recommendations for leadership

For Chief Information Security Officers (CISOs)

• Stop borrowing IT playbooks. Do not assume that an enterprise data governance framework or standard IT endpoint detection and response (EDR) agent is sufficient to manage the physical risks of an industrial AI engine.

• Establish an AI War Room. Partner directly with the VP of Manufacturing or Operations to create a dedicated, cross-functional engineering and security assessment team tasked with vetting all proposed analytical and operational software integrations.

For OT security leaders

• Enforce Zone Segmentation. Treat the AI system as an untrusted third-party component. Map all asset dependencies and communication paths using Network Detection and Response (NDR) tools optimized for industrial protocols (e.g., Modbus, CIP, DNP3, OPC UA).

• Operationalize Vendor Advisory Triage. Establish clear service level agreements (SLAs) to evaluate and apply vendor patches or compensating controls immediately when critical software flaws are disclosed, anticipating that AI-driven tools will accelerate the timeline from disclosure to exploit weaponization.

For plant operations teams and plant managers

• Prioritize Safety Instrumented Systems (SIS). Ensure that safety systems remain entirely separate, hardwired, and isolated from any network layer containing optimization software or AI platforms. The safety loop must serve as an uncompromised backstop against any aberrant control command.

• Combat Automation Bias. Conduct continuous operator training and simulation drills focusing on managing process upsets manually. Ensure that operators maintain the baseline competency to recognize, distrust, and override flawed automated recommendations.

Conclusion

Integrating AI platforms into Operational Technology environments holds immense potential for maximizing efficiency and reducing industrial downtime. However, introducing stochastic, non-deterministic software engines into safety-critical, deterministic architectures presents profound operational and cybersecurity challenges.

Advanced agentic capabilities, typified by frontier models like Claude Mythos, prove that the velocity of vulnerability discovery and exploitation has permanently accelerated. To defend critical infrastructure against this evolving threat landscape, asset owners cannot rely on conventional perimeter defenses or passive compliance models. Security and engineering teams must collaborate to build resilient architectures rooted in strict zone segmentation, unidirectional data delivery, human-in-the-loop validation, and an unyielding commitment to physical process safety.