AI in OT Security: Fix Trust Before You Automate

A lot of AI pilots in operational technology (OT) are being sold as “low effort, high impact.” The reality on the plant floor is the opposite: AI in OT tends to amplify every existing weakness—identity gaps, poor asset visibility, messy vendor support, and fragile change control—until it becomes a safety and security problem.

That’s why the recent joint advisory from government partners (focused on understanding AI, assessing use, establishing governance, and embedding safety/security) matters. Not because it’s novel, but because it quietly confirms what many OT security teams already know: you can’t outsource judgment to a nondeterministic system inside deterministic environments.

This post is part of our AI in Cybersecurity series, where we focus on using AI for threat detection and automation without creating new failure modes. OT is where that promise gets stress-tested.

Why AI and OT clash: predictability vs. probability

OT is engineered for repeatability; many AI systems are engineered for likelihood. That mismatch is the root of most “AI in OT security” headaches.

Industrial control environments reward systems that behave the same way every time, because small deviations can become physical outcomes: overdosing chemicals, overspeeding motors, unexpected torque, pressure swings, batch contamination, downtime. If your environment is built around stable PLC logic, fixed interlocks, and carefully bounded alarms, then dropping in an AI component that can vary outputs from one run to the next is not a minor design choice—it’s a new class of operational risk.

The nondeterminism problem (and why it scares operators)

Large language models and agentic systems can be nondeterministic: they may produce different responses for similar prompts, depend on hidden internal state, or change behavior when upstream context shifts. In OT, that creates three immediate issues:

• Model drift: the model’s behavior changes over time as equipment ages, processes shift, or training data no longer matches reality.
• Explainability gaps: “why did it recommend that?” isn’t a philosophical question in OT—it’s how you decide whether to stop a line.
• New attack surfaces: prompts, model inputs, telemetry pipelines, and update mechanisms become targets.

Here’s the stance I’ve found most practical: treat nondeterministic AI as advisory until you’ve proven it can’t surprise you. And in OT, “proven” means you’ve tested it in the ugly edge cases, not the happy path demo.

The trust foundation OT teams don’t have (yet)

AI is only as trustworthy as the device data feeding it. If you can’t validate firmware provenance, sensor integrity, or software updates, then you can’t claim the AI’s outputs are reliable—no matter how impressive the model looks in a lab.

This is where most organizations get stuck. They want AI-driven automation, but they haven’t built the basics:

• Strong device identity (unique, cryptographically verifiable)
• Signed firmware and authenticated updates
• Sensor data integrity controls (so “truth” isn’t spoofable)
• Lifecycle management for credentials and keys

If you’re missing those, an attacker doesn’t need to “hack the model.” They can poison the inputs so the AI makes confident, dangerous decisions.

A simple way to explain it internally

A snippet-worthy way to frame it for leadership:

If your sensors can lie, your AI will amplify the lie—faster and at scale.

That’s why the most valuable early investment isn’t a bigger model. It’s cryptographic trust and lifecycle discipline.

What “trustworthy OT data” looks like in practice

You don’t need perfection to start, but you need a roadmap. Prioritize:

1. Cryptographic device identity at manufacturing or onboarding
   • Make device identity non-optional for new deployments.
2. Signed and attested firmware and updates
   • If you can’t verify updates, you’re accepting supply chain risk by default.
3. Credential and key lifecycle governance
   • Rotate, revoke, inventory, and monitor crypto assets like production-critical components.
4. Supply chain verification artifacts
   • Use SBOM/CBOM-style practices to reduce “unknown component” risk.

This isn’t bureaucracy. It’s the difference between AI being a safety assistant and AI being a liability.

The human factor: when AI adds work instead of removing it

AI that can drift, hallucinate, or fail silently increases operator burden. That’s not a theoretical risk; it shows up as alert fatigue, confusion, and slowdowns—especially for small OT security teams that are already stretched thin.

Most plants don’t have a bench of ML engineers on standby. They have control engineers, maintenance teams, and operators who are excellent at troubleshooting physical systems and deterministic logic. When an AI-driven tool generates an alert that can’t be validated quickly, people do what they’re trained to do: they fall back to what they trust.

Why “early warning” can be worse than late warning

In OT, an early alert that’s unclear can be riskier than a delayed alert that’s precise. If the alert triggers an unnecessary response—shutting down a process, changing a setpoint, reconfiguring a system—it can introduce new hazards and downtime.

So if your AI security monitoring creates noise, it doesn’t just waste time. It can change operational behavior in ways that reduce safety margins.

Design rule: AI must be “explainable enough” for shift handover

A practical bar I like:

• If an operator can’t explain an alert and the recommended action during a shift handover in 60 seconds, it’s not ready for production response workflows.

That pushes teams to build clear runbooks, confidence scoring, and “show your work” telemetry views.

How attackers will exploit AI in OT (and why screen-trust matters)

Attackers don’t need full control to win; they need you to trust the wrong signals. OT attacks have already included deception techniques that make HMI screens appear normal during abnormal conditions. AI introduces new ways to scale that deception.

Three attacker plays to plan for:

1) Data poisoning and sensor spoofing

If attackers can manipulate sensor values, timestamps, or telemetry paths, they can train or steer models into blind spots. That can make a detection model “learn” that malicious behavior is normal.

2) Prompt and workflow injection

If you deploy LLMs for incident triage, maintenance assistance, or alarm explanation, you introduce a new class of manipulation: crafted inputs that cause the model to recommend unsafe steps, ignore anomalies, or reveal sensitive procedures.

3) “Normal-looking” interfaces during active compromise

If AI becomes part of operator decision-making, attackers will target the human trust boundary: dashboards, summaries, and AI-generated explanations. A clean-looking AI summary can be more persuasive than raw telemetry.

A blunt but useful reminder:

In OT, the most dangerous compromise is the one that looks normal.

This is why AI security in critical infrastructure needs multiple lines of defense: prevention, detection, response, deception, and recovery—not just “better alerts.”

Cloud-dependent AI vs. OT reality: lifecycle mismatch

Many OT environments can’t support continuous outbound connectivity—and often shouldn’t. That conflicts with common AI lifecycles that assume regular updates, telemetry feedback, and vendor-managed model improvements.

Even if you run AI locally, you still have lifecycle friction:

• Models require periodic validation or retraining to remain accurate.
• OT processes change slowly, but assets last decades.
• Vendors may not support model maintenance on OT timelines.

The “30-day model, 30-year asset” problem

A model that’s updated monthly doesn’t map cleanly to equipment expected to run for 15–30 years. Without a plan, you accumulate architectural debt: brittle dependencies, unsupported components, and security exceptions that become permanent.

If you’re leading OT security, make lifecycle questions part of procurement:

• Who owns model performance monitoring?
• What triggers retraining—and who approves it?
• How do updates get tested against safety constraints?
• What happens when the vendor sunsets a model?

If you can’t get crisp answers, you’re not buying “AI.” You’re buying a long-term integration risk.

A safer way to start: AI for OT anomaly detection (without touching control)

The lowest-risk, highest-value entry point for AI in OT is passive anomaly detection. Not an AI agent making control decisions—AI that observes and helps your team prioritize.

This approach aligns with the broader AI in Cybersecurity theme: use AI to improve detection and triage while keeping humans (and deterministic controls) in charge of safety-critical actions.

What “good” looks like for OT anomaly detection

Aim for architecture patterns like:

• Passive monitoring via network taps/SPAN ports (no inline dependencies)
• OT network detection and response tuned to industrial protocols
• Baselining of normal communications and process-adjacent signals
• Tiered alerting that prioritizes high-confidence deviations

Crucially: the AI system should not be able to change PLC logic, write configurations, or push updates. Keep it observational until trust and governance mature.

Practical controls to wrap around AI detection

• Change-control binding: alerts should reference approved maintenance windows and known work orders.
• Evidence-first alerts: every detection includes packet captures, time-series context, or host telemetry—not just a label.
• Human-in-the-loop escalation: AI can rank and cluster; humans decide action.
• Deception and validation checks: cross-validate anomalies with independent sensors or secondary telemetry paths.

This is how you get real security gains without betting the plant on model behavior.

A pragmatic AI governance checklist for OT leaders

AI governance in OT isn’t paperwork—it’s an operational safety control. If you want AI-driven security automation without surprises, set governance that matches OT constraints.

Here’s a checklist that works well for first deployments:

1. Define what the AI is allowed to do (and what it’s forbidden to do)
   • Advisory only vs. automated containment vs. automated remediation.
2. Set reliability targets tied to operations
   • False positive rate thresholds by asset class.
   • Maximum acceptable “unexplained” alerts per shift.
3. Establish a model lifecycle owner
   • Named individual/team responsible for validation, updates, rollback.
4. Harden data pipelines
   • Signed telemetry where possible, integrity checks, access controls, logging.
5. Plan for failure
   • If the model goes offline or degrades, operations continue safely.
6. Train for cross-functional response
   • OT + IT security + engineering drills that include AI tool failure modes.

If you’re a smaller organization, don’t pretend you can do all of this at once. Start with passive detection, build trust controls, and expand scope only when you can support it.

Where this leaves your AI in OT security roadmap

AI in OT security isn’t “too incompatible” to use—it’s too unforgiving to deploy casually. The organizations that get value will treat AI as part of a defensible architecture: strong identity, verified data, lifecycle governance, and monitoring that doesn’t interfere with control.

If your team is exploring AI-driven threat detection and automation for critical infrastructure, make one decision early: Are you building trust first, or trying to automate around missing trust? Only one of those scales.

If you want a practical next step, start by mapping your OT environment into three zones—observe, advise, act—and place AI only in the first two until your device identity, update integrity, and governance can support the third. What would it take in your environment to move one high-value process from “advise” to “act” without increasing safety risk?