OT AI Governance and Cybersecurity — Managing Risk When AI Agents Enter the Control System

Why AI in OT Is a Different Risk Category

An AI agent with write access to SCADA tags is not an analytics tool — it is a control authority. It occupies the same trust position as a human operator sitting at an HMI console, with one critical difference: it can act faster, at scale, and without the contextual judgment that experienced operators bring to abnormal situations. A compromised AI agent could set dangerous pressure setpoints, suppress critical alarms, generate false maintenance work orders that take safety systems offline, or subtly degrade process efficiency in ways that take weeks to detect.

CISA's guidance on AI in industrial control systems recognizes this distinction explicitly. Traditional IT security focuses on data confidentiality. OT security focuses on process integrity and availability — ensuring that physical processes operate safely and continuously. When AI agents bridge IT and OT, they inherit the risk profiles of both domains simultaneously. A model poisoning attack that would be a data quality issue in IT becomes a process safety issue in OT. This convergence demands governance frameworks specifically designed for AI systems that can influence physical processes.

The AI Attack Surface in OT

AI agents introduce four distinct attack vectors into OT environments that traditional ICS security frameworks were not designed to address. Understanding each vector is essential for building effective defenses as part of the broader agentic AI for SCADA deployment strategy.

• Model poisoning via training data: An attacker who can corrupt historian data or inject false records into training datasets can cause the AI model to learn incorrect process relationships. The model then makes systematically wrong recommendations that appear valid to operators because the model's confidence remains high.
• Adversarial inputs: Carefully crafted sensor readings — within normal ranges individually but forming patterns that exploit model weaknesses — can cause AI agents to make incorrect decisions. Unlike random noise, adversarial inputs are designed to push the model toward specific wrong outputs.
• Agent hijacking: For LLM-based agents, prompt injection attacks can override the agent's instructions, causing it to take actions outside its intended scope. API-level attacks can intercept and modify agent communications with the SCADA system.
• Action interface exploitation: The OPC-UA or API interface that gives the AI agent write access to SCADA tags is also a lateral movement path. An attacker who compromises the AI platform can use the agent's legitimate write credentials to access control system components.

ISA/IEC 62443 Framework Applied to AI Systems

ISA/IEC 62443 provides the foundational security framework for industrial control systems, and AI agents must be integrated into this framework rather than treated as exceptions. The standard's zones and conduits model maps naturally to AI architectures: the AI inference engine typically sits in a conduit between the IT zone (where training data and cloud services reside) and the OT zone (where SCADA systems and controllers operate).

Security Level (SL) assignments must account for the AI agent's capabilities. An agent with read-only access to historian data might warrant SL-1 (protection against casual violation). An agent with write access to process control setpoints requires SL-2 or SL-3 (protection against intentional violation with moderate to sophisticated means). The security level drives requirements for authentication, authorization, data integrity verification, and audit logging at each zone boundary.

Change management procedures under IEC 62443 must extend to model updates. Retraining an AI model is functionally equivalent to modifying control logic — the agent will behave differently after the update. Model updates should follow the same management-of-change process as PLC program modifications: documented justification, testing in a non-production environment, rollback procedures, and authorized approval before deployment.

The Human-in-the-Loop Governance Requirement

Effective OT AI governance uses a tiered autonomy model that matches the AI's decision authority to the risk level of each action. We recommend a three-level framework that balances operational efficiency with safety assurance.

• Level 1 — Informational (fully autonomous): The AI agent monitors, detects anomalies, generates alerts, and provides recommendations. No write access to the control system. This level carries minimal risk and delivers immediate value through faster anomaly detection and reduced alarm fatigue.
• Level 2 — Semi-autonomous (writes within normal operating band): The AI agent can write setpoints to the control system, but only within pre-defined safe operating envelopes. Hard-coded limits in the SCADA system prevent the agent from writing values outside the normal operating range. All writes are logged with full context.
• Level 3 — Human-approval required (outside normal band or safety-related): Any action that would move a process variable outside its normal operating band requires explicit human approval. Safety Instrumented Systems (SIS) and Emergency Shutdown (ESD) systems are never connected to AI write paths under any circumstances.

This tiered approach lets organizations start at Level 1, build confidence, and graduate to Level 2 only after demonstrating consistent, reliable AI performance over months of shadow-mode operation.

Explainability and Audit Requirements for OT AI

Every decision an AI agent makes in an OT environment must be logged and explainable — not as a nice-to-have, but as a regulatory and insurance requirement. When a compressor trips and the root cause investigation reveals that an AI agent adjusted suction pressure 30 minutes earlier, the operations team and regulators need to understand exactly why the agent made that adjustment, what data it was responding to, and what alternatives it considered.

Explainability mechanisms vary by model type. For tree-based and linear models, SHAP values quantify each input feature's contribution to the decision. For neural networks, attention weights and gradient-based attribution methods provide similar transparency. For LLM-based agents, RAG source attribution shows which documents and data points informed the response. All explanations must be stored alongside the action log in an immutable audit store.

Model Lifecycle Governance

AI models are not static — they degrade over time as operating conditions change, equipment ages, and process configurations evolve. A model trained on 2023 compressor performance data will make increasingly poor recommendations as compressor efficiency degrades through 2025 and 2026. Without lifecycle governance, operators gradually lose trust in AI recommendations and revert to manual operation.

Model lifecycle governance requires defined processes for drift monitoring (comparing predictions against actual outcomes), retraining triggers (when prediction error exceeds threshold), training data integrity verification, and version management with rollback capability. Each model retraining cycle must go through the same change management process as the initial deployment.

Practical Governance Checklist for OT AI Deployment

Organizations preparing to deploy AI agents with any level of OT interaction should validate these governance controls before moving from pilot to production.

• Write path review: Every SCADA tag the AI agent can modify has been identified, documented, and approved by operations and safety engineering
• Maximum deviation bounds: Hard-coded limits in the SCADA system prevent the agent from writing values outside the safe operating envelope
• SIS/ESD exclusion: Safety Instrumented Systems and Emergency Shutdown systems have no connection to AI agent write paths
• Immutable action logging: Every AI decision and action is logged to a tamper-evident store with full context
• Human approval for abnormal actions: Actions outside normal operating bands require explicit operator approval
• Model integrity monitoring: Continuous comparison of model predictions against actual outcomes with automated drift alerts
• Incident response procedure: Documented procedure for AI-related incidents including immediate agent isolation and recovery steps
• Adversarial testing: Regular red-team exercises testing model robustness against adversarial inputs and agent hijacking