AI in OT needs cryptographic identity, not just automation

At a glance

What this is: This is an analysis of new AI-in-OT guidance that argues cryptographic identity and continuous trust must govern AI agents, not automation alone.

Why it matters: It matters because OT teams now have to treat AI as an identity-bearing actor whose actions can affect safety, availability, and auditability across human, machine, and agentic environments.

Context

AI in operational technology is no longer just a control-system question. When an AI system can influence sensors, machines, or automated responses, the security issue becomes how that actor is authenticated, verified, and audited while it operates.

The governance gap is that many OT programmes still assume trust is tied to the system boundary or the deployment pipeline. This article argues that AI in OT needs cryptographic identity, because the trust model has to follow the actor wherever it makes decisions.

That shifts the problem from simple automation reliability to identity governance for AI agents, devices, and control systems. In that model, authenticity and integrity are not add-ons after deployment; they are part of operational safety from the start.

Key questions

Q: How should security teams govern AI systems that can act without human approval?

A: Security teams should govern autonomous AI the same way they govern other high-risk identities, but with runtime enforcement instead of periodic review. That means tightly scoping tools, data, and actions; logging every material step; and making revocation and containment available while the session is still active. Static policy alone does not control machine-paced execution.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What should teams check first when AI is being added to OT environments?

A: Start with where identity is asserted, how outputs are verified, and whether certificate or trust lifecycle controls can keep pace with the operational tempo. If those three points are unclear, the programme is already assuming trust that the environment cannot safely grant.

Q: What is the difference between automation controls and cryptographic identity in OT?

A: Automation controls manage how work happens, while cryptographic identity proves which actor is allowed to do it and lets the organisation verify that the action is authentic. In AI-enabled OT, the second control is what keeps automation from becoming an ungoverned decision-maker.

Technical breakdown

Why AI in OT becomes an identity problem

AI in OT is different from ordinary automation because the actor can make decisions that affect physical processes in real time. Once a model or agent can interpret sensor data, select actions, and trigger outputs, the trust question is no longer only whether the pipeline works. It is whether the actor itself can be verified, whether its outputs can be attributed, and whether changes in state can be audited. That is why cryptographic identity matters: it gives each AI component a verifiable trust anchor instead of treating the whole system as implicitly trusted.

Practical implication: OT teams need to govern AI actors as identities, not just as software components.

How PKI supports trusted AI actions in OT

Public key infrastructure gives OT environments three things this article highlights: cryptographic identity, integrity assurance, and non-repudiation. In practice, that means an AI agent, control application, or device can prove who it is, the data it consumed can be checked for tampering, and its actions can be traced back to a signed identity. This matters in distributed OT workflows because trust has to survive across devices, networks, and decision points. Without that chain of verification, a spoofed input or altered output can look operationally legitimate while still being unsafe.

Practical implication: bind AI agents and OT components to signed identities that can be validated end to end.

Why lifecycle automation is part of OT safety

The article also ties trust to lifecycle management because AI systems may operate faster than humans can intervene. That means certificate issuance, renewal, policy enforcement, and revocation cannot depend on manual handling if the environment is genuinely dynamic. In OT, delayed renewal or revocation is not just an administrative defect. It creates a trust gap during which an AI component may continue operating without current verification. The governance model therefore has to treat lifecycle automation as a safety control, not an efficiency enhancement.

Practical implication: automate certificate and trust lifecycle controls so AI-driven OT does not outpace governance.

Threat narrative

Attacker objective: To manipulate or destabilise OT operations by causing untrusted AI-driven decisions to be treated as legitimate.

1. Entry occurs when AI is embedded into OT workflows and begins receiving sensor, machine, or network inputs as an operational actor rather than a passive analytics layer.
2. Credential or trust compromise occurs when the AI component lacks strong authentication or verified identity, allowing spoofed inputs, altered model outputs, or untrusted actions to be accepted.
3. Escalation happens when the AI system makes autonomous or semi-autonomous decisions that affect equipment, energy distribution, or industrial processes without continuous verification.
4. Impact is operational instability, unsafe automated action, or weakened auditability across critical infrastructure and automation pipelines.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cryptographic identity is the missing control plane for AI in OT: This article is not really about automation efficiency. It is about whether an AI actor can be proven trustworthy before it affects a physical process. When AI can interpret inputs, choose actions, and trigger responses, OT governance needs a verifiable identity layer, not just orchestration logic. The practitioner conclusion is that trust must become actor-scoped, not system-scoped.

Automation without identity creates a trust gap that OT cannot absorb: Traditional OT controls assume the operator, device, or application boundary is stable enough for continuous oversight. AI breaks that assumption because the actor can act faster than human review and can change the operational state before anyone intervenes. The implication is that identity assurance must be present at decision time, because post hoc review is too late for safety-critical execution.

Continuous trust should be treated as a lifecycle property, not a deployment feature: Certificate issuance, renewal, and revocation become safety controls once AI participates in OT decisions. A model or agent that is authenticated only at deployment but not continuously verified still leaves room for spoofed inputs or stale trust. The practitioner conclusion is that lifecycle management has to track the AI actor’s operating window, not just the asset inventory.

AI in OT collapses the old separation between automation and accountability: The article points to non-repudiation and auditability because organisations need to know which trusted actor made which decision and when. That is a governance requirement, not a paperwork exercise. The broader field implication is that OT identity programmes now have to span human operators, devices, applications, and AI agents under the same trust model.

Post-quantum readiness belongs in the same conversation as AI trust: The article links AI identity foundations to post-quantum-ready cryptography, which signals that long-lived trust anchors in OT must be built for durability, not just current compatibility. That matters because industrial environments cannot afford frequent redesign of identity foundations. The practitioner conclusion is to align AI trust architecture with cryptographic longevity from the outset.

What this signals

Cryptographic trust has become the control that OT teams cannot postpone: As AI systems begin to act inside industrial environments, identity assurance moves from a security enhancement to a prerequisite for safe operation. Programmes that still treat AI as a telemetry layer will miss the governance problem that matters most: who the actor is at the moment it decides.

Actor-scoped trust will replace boundary-scoped trust in mature OT programmes: The practical shift is from protecting a network segment to verifying the specific AI, device, or application making each action. That change will reshape certificate design, audit trails, and incident review for critical infrastructure teams.

For practitioners

• Map AI-controlled OT flows to identity checkpoints Identify every place where an AI component influences a machine, sensor, or control decision, then require a verifiable identity assertion before that action can take effect.
• Bind AI agents to cryptographic credentials Assign certificates or equivalent trust anchors to AI models, agents, and decision engines so actions can be authenticated and traced across OT workflows.
• Automate certificate lifecycle controls Use renewal, revocation, and policy enforcement automation so trust does not depend on humans keeping pace with AI-driven operational timelines.
• Verify outputs before they reach physical systems Require integrity checks on model outputs, training updates, and decision pipelines before any action can alter equipment, energy flows, or industrial processes.

Key takeaways

• AI in OT changes the trust problem from system control to actor identity, because models and agents can now make operational decisions with physical consequences.
• Cryptographic identity, integrity checking, and non-repudiation are the controls that let teams validate AI behaviour before it reaches equipment or control loops.
• Lifecycle automation matters because OT trust fails when certificate renewal, policy enforcement, or revocation cannot keep pace with AI-driven operations.

Key terms

• Cryptographic Identity: Cryptographic identity is a trust model in which authentication depends on verifiable keys, certificates, or signed assertions rather than shared secrets alone. It is essential for machines and agents because it gives the organisation a stronger way to prove identity and revoke access quickly.
• Non-Repudiation: Non-repudiation is the ability to prove what an identity did, when it did it, and under what authority. For autonomous agents, that evidence must include context, approvals, and tool usage so later review can reconstruct the decision path.
• Lifecycle Management: Lifecycle management is the process of creating, reviewing, rotating, and retiring identities and their secrets in a controlled way. For NHIs, it is essential because stale credentials, orphaned accounts, and incomplete offboarding are common paths to long-lived exposure and unauthorised access.
• Integrity Assurance: Integrity assurance is the control that helps ensure data, models, and outputs have not been altered in transit, storage, or use. In AI OT environments, it protects sensor inputs, model updates, and decision outputs so operators can trust the action path as well as the actor.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational trust in your organisation, it is worth exploring.