AI in OT Security: Govern It Before It Governs You

A single bad decision in operational technology (OT) doesn’t just break an app. It can overpressure a pipe, spoil a batch, trip a turbine, or shut down a line that’s already running on thin margins. Now add AI—especially nondeterministic models like large language models (LLMs) and agentic systems—into that environment and you’ve got a tension that most organizations underestimate: AI thrives on probabilistic outputs, while OT demands repeatable, predictable control.

A recent joint advisory from government partners lays out sensible principles for integrating AI into OT: understand the technology, assess use cases, set governance, and embed safety and security. I agree with the direction. But here’s my stance: if your OT environment can’t prove device identity, data integrity, and lifecycle control, adding AI doesn’t “modernize” anything—it amplifies uncertainty.

This post is part of our AI in Cybersecurity series, and it tackles the practical question security leaders are wrestling with in late 2025: Can AI help secure the very systems it can destabilize? Yes—but only if you treat AI like an untrusted component until proven otherwise.

OT and AI don’t naturally fit—here’s why that matters

OT systems are engineered to be deterministic; many AI systems are not. That mismatch creates security and safety failure modes you don’t typically see in IT.

In OT, stability is a feature. Logic is validated. Change windows are rare. “It worked yesterday” is a legitimate safety requirement. By contrast, many LLMs and AI agents are nondeterministic—they can produce different outputs for the same prompt because of probabilistic sampling.

That difference shows up as real operational risk:

• Model drift: The model’s behavior degrades as the environment changes (new sensors, recalibrations, seasonal shifts, wear-and-tear).
• Explainability gaps: When an OT operator asks “why did you flag this?” a fuzzy explanation isn’t good enough.
• New attack surface: Prompts, model inputs, integrations, and update mechanisms become new places to break trust.

The takeaway is simple and extractable: In OT, an AI feature that can’t be bounded, tested, and monitored becomes a safety issue—not just a cyber issue.

The quiet risk: “correct” AI output based on wrong data

Most AI failures in OT won’t look like a Hollywood meltdown. They’ll look like plausible dashboards and calm operator screens—while reality drifts.

If sensors can be spoofed, if firmware can’t be authenticated, or if updates aren’t signed and attested, then AI can be “right” according to its inputs and still be disastrously wrong in the real world.

This is where OT security fundamentals stop being “hygiene” and start being prerequisites.

Trust is the bottleneck: AI can’t be safer than the data it consumes

AI in OT is only as trustworthy as your device identity and data lineage. If your environment can’t verify what a device is, what code it’s running, and whether its telemetry is authentic, then AI is operating on faith.

Many industrial environments still struggle with:

• Weak or absent device identity (no cryptographic identity established at manufacturing or commissioning)
• Inconsistent code signing and firmware provenance
• Limited asset lifecycle control (credentials that never rotate, undocumented replacements, “shadow” changes during outages)
• Sparse SBOM/CBOM practices that would help spot tampered components or risky dependencies

If you’re trying to deploy AI-driven monitoring or AI-assisted decisioning on top of those gaps, you’re building a smart layer on a shaky base.

What “trust foundations” look like in OT (practical checklist)

If you want AI in OT without betting the plant on it, start with controls that make AI inputs provable:

1. Cryptographic device identity for critical assets (including gateways and sensors that feed analytics)
2. Signed firmware and updates with enforcement, not “optional verification”
3. Remote attestation where feasible (prove device state before trusting its data)
4. Credential and key lifecycle governance (issuance, rotation, revocation, inventory)
5. Supply chain verification practices (SBOM/CBOM expectations in procurement; acceptance testing at receiving)

You don’t need perfection. You need enough integrity that an AI model isn’t learning from lies.

Snippet-worthy truth: If you can’t attest the device, you can’t trust the model.

Governance for AI in OT: treat it like a safety instrumented system

AI governance in OT must be stricter than AI governance in IT. The reason is consequence, not compliance.

In IT, an LLM hallucination might waste time. In OT, a hallucination can trigger the wrong escalation path, generate false confidence, or distract operators with high-volume noise.

A governance program that actually works in OT is concrete and testable:

Define “allowed AI” by use case, not by vendor pitch

Classify AI use cases into risk tiers:

• Tier 1 (low risk): Passive AI for detection/triage (read-only), no automatic control actions
• Tier 2 (medium risk): AI recommendations for operators with strict human confirmation and runbooks
• Tier 3 (high risk): AI that can initiate changes (write access, orchestration, automated containment)

My recommendation: start with Tier 1, prove value, then graduate slowly. Most companies skip this and regret it.

Establish model lifecycle controls that match OT lifecycles

OT assets can run for decades. AI models don’t.

Your governance should define:

• Retraining/validation cadence (and what triggers re-validation: sensor replacement, process change, maintenance event)
• Baseline datasets and “known-good” operating envelopes
• Rollback plans (versioned models, versioned pipelines, versioned feature engineering)
• Change management that maps model updates to maintenance windows

If a vendor can’t support long-lived deployments with auditable change control, that’s not “innovation.” That’s architectural debt.

Embed safety and security together

In OT, cyber and safety are intertwined. AI governance should be co-owned by security, OT engineering, and safety stakeholders so you don’t end up with:

• Security teams optimizing detection while increasing operator burden
• Engineering teams optimizing throughput while creating blind spots
• Vendors shipping “black box” models that no one can validate

How attackers will target AI in OT (and how to blunt it)

Attackers don’t need to break the model to win—they only need to shape what the model sees.

Three attacker patterns matter most for AI-enabled OT environments:

1) Data poisoning and sensor spoofing

If adversaries can manipulate telemetry, they can push the model to normalize malicious states or suppress alarms.

Defense: integrity controls (attestation, signed firmware), anomaly detection that correlates across independent sources (network + process + endpoint), and strict segmentation so an attacker can’t easily reach both sensors and analytics pipelines.

2) “Normal-looking screens” during active disruption

This is an old OT trick—mask the HMI so operators see stable values while the physical process changes. AI can make this worse if it’s trained to trust HMI-side telemetry without cross-checks.

Defense: out-of-band validation channels, independent historian comparisons, and NDR that flags command/traffic patterns that don’t match the supposed steady state.

3) AI-assisted recon and exploit chaining

Threat actors are already using AI to scale discovery: faster vulnerability research, faster targeting, faster social engineering. OT environments—often under-instrumented—are attractive.

Defense: multiple lines of defense that assume compromise: prevention (hardening/segmentation), detection (NDR + endpoint monitoring where safe), response (playbooks and isolation options), and recovery (tested restore paths).

The key line for leadership: AI increases attacker speed; your controls must reduce attacker reach.

Where AI helps OT security without raising the risk floor

The best early AI wins in OT are passive, bounded, and explainable. I’m opinionated here: if your first AI project touches control logic or introduces autonomous actions, you’re taking the hardest path first.

AI for anomaly detection in passive monitoring

Traditional machine learning (not necessarily LLMs) can improve:

• Detection of unusual east-west traffic in OT zones
• Identification of abnormal protocol use (command sequences that don’t match baseline)
• Early warning on lateral movement patterns that humans miss in noisy logs

Because this can be done via passive network taps/SPAN ports, it doesn’t interfere with process control.

AI to reduce alert fatigue (when done carefully)

Security teams want AI to triage. OT teams want fewer distractions. Both can be true if you enforce guardrails:

• Evidence-first alerts: every alert includes packet capture references, asset context, and “why this is anomalous” features
• Operator-friendly severity: map detection outputs to operational impact categories (process risk, safety risk, availability risk)
• Confidence thresholds: don’t surface low-confidence alerts to the control room; route them to security analysts first

A practical design pattern I’ve seen work: AI summarizes and clusters alerts for the SOC, while OT operators receive only high-confidence, high-impact incidents with clear runbooks.

AI to accelerate asset visibility and documentation

If your OT network is under-documented (many are), AI-assisted discovery and classification can help:

• Normalize asset inventories
• Identify firmware versions and communication relationships
• Detect “unknown” devices that suddenly appear

This directly supports AI governance because you can’t govern what you can’t inventory.

A “safe adoption” roadmap you can use next quarter

Start with constraints, not capabilities. AI projects succeed in OT when the first requirement is safety and integrity, not feature breadth.

Here’s a pragmatic sequence:

1. Baseline the environment: inventory assets, map zones/conduits, document critical data flows
2. Fix trust primitives: device identity, signed updates, credential/key governance for critical tiers
3. Deploy passive visibility: network detection and response tuned for OT protocols
4. Add bounded AI: anomaly detection and triage in read-only mode
5. Run operational drills: test false positives, test operator handoffs, test containment options
6. Expand use cases slowly: recommendations before automation; automation only with strong controls and rollback

If you’re a smaller organization, this also helps with resourcing. You can buy time by focusing on passive controls that provide immediate risk reduction without large engineering rework.

What to do if you’re planning AI in OT in 2026

AI will keep moving into industrial environments because the business incentives are real: productivity, predictive maintenance, quality optimization, faster troubleshooting. The mistake is treating OT like just another endpoint fleet.

If your organization is investing in AI for industrial operations, make a parallel investment in AI-driven cybersecurity: passive detection, security automation that respects OT constraints, and governance that keeps models measurable and bounded.

The forward-looking question I’d ask your team is this: If your AI model starts drifting on a holiday weekend with a skeleton crew on site, what exactly happens—and who can prove what the model saw?