Boards make OT risk decisions they do not know they are making. AI agents change behavior with every model upgrade and carry no personal accountability. The most likely AI failure in OT involves no adversary, just an authorized system making a bad decision with physical consequences. Gary Tillery of Skkynet and Matt Morris of EverLine answer the audience questions from the “It Can’t Happen to Me – Until It Does” session at the Industrial AI Summit 2026.
How Do You Communicate OT Cyber Risk to the Board?
Audience question: Do you see your role as an educator for leadership and the board on OT cybersecurity?
Both answers say yes, but redefine the role: not educator, but translator. The board does not need to understand Modbus or Purdue levels. It needs to make risk decisions in operational terms.
Matt Morris, VP of Security and Resilience at EverLine:
Yes, but “educator” undersells the job and slightly misdirects it. Boards don’t need to understand Modbus or Purdue levels. They need to make risk decisions they currently don’t know they’re making. My role is translator and decision-framer.
In practice that means three things. First, I translate cyber into the language the board already governs in: hours of downtime, megawatts or barrels lost, safety and environmental exposure, regulatory consequence. If a risk can’t be expressed in operational consequence, it isn’t ready for the boardroom. Second, I give them the right questions rather than the answers. “Could an IT compromise shut down operations, and when did we last test that?” is more useful to a director than any briefing deck. Third, I force risk acceptance to be explicit. Most organizations are carrying OT risk that nobody formally accepted. It was just never surfaced. Once it’s named, owned, and signed for, you have governance.
There’s also a liability dimension boards increasingly understand: disclosure of board-level cyber oversight is now expected of public companies, and directors carry oversight duties. OT is where that oversight is weakest and consequences are most physical.
As VP/GM of a services practice, I’d add one discipline: the moment board education sounds like a sales pitch, you lose the room. Credibility comes from telling a board what they don’t need to buy.
Gary Tillery, CEO of Skkynet:
Yes, but as a translator of decisions, not as a lecturer. Leadership and the board of manufacturers or site operators already own safety, availability, and production risk. My role is to make OT security risk legible in those terms so they can set appetite, fund the right controls, and know when to intervene. I am not there to teach them packet captures. I am there to show what can stop a line, harm people, or breach a regulatory duty, what they can realistically reduce this year, and what residual risk they are accepting if they do not.
How Do You Manage AI Agent Identity and Authority?
AI agents operating inside OT are exactly the kind of risk a board needs to accept or reject.
Audience question: While AI agents have similarity to employees, they are also different. An agent can change behaviors as its underlying model gets upgraded. An agent’s guardrails may need to change significantly as new model capability gets delivered. An agent moves much faster and has no sense of reputation, career, or penalty for its rationalized misbehavior. An agent identity is tied to a supply chain, a development process, its hosting platform, its tests. How do you bridge the gap?
Gary Tillery, CEO of Skkynet:
Great question and one that highlights the fact that we are still in the infancy in many ways in our learning how to manage organizations that have both human and digital FTE’s in a sense. We are seeing the creation of AI Native companies as well and they are at the forefront of this change and we can all learn from how they are approaching this new operating model. As an example, in an AI-native company the gap is not closed by an HR style policy. It is closed by making the digital FTE or agent a platform object whose identity outlives any model, and whose authority is re-issued only against the current stack. The operating split is simple. Domain teams, or the humans, own the job: the prompt, the tool allowlist, and the eval (evaluation) suite that defines “this agent is still doing its job.” The platform or the agent, owns everything that can change what that job is allowed to touch: identity, credentials, model routing, budgets, runtime policy, traces, and the kill switch.
What Belongs in an Industrial AI Risk Register?
Identity, credentials, kill switch, runtime policy. Where does all of that go?
Audience question: What belongs in an industrial AI risk register that a traditional cyber risk register usually misses? Specifically: AI authority and autonomy, data and source integrity, human-control boundaries, downstream impact.
Matt Morris, VP of Security and Resilience at EverLine:
The fundamental gap is this: a traditional cyber register models threats, an adversary doing something bad. The most likely AI failure in OT involves no adversary at all. It’s an authorized system, operating as designed, making a bad decision with real physical consequence. That’s why I’d argue industrial AI risk belongs closer to process safety than to cyber. Run it like a HAZOP: apply the guidewords (more, less, none, reverse, late, other than) to every AI action and ask what happens.
Specifically, the register needs:
AI Authority and Autonomy
- Autonomy level per use case: observe, recommend, act with approval, act autonomously.
- The action envelope: which setpoints, ranges, and rates it can touch, and what it’s explicitly forbidden from touching. Safety instrumented systems should be off-limits, full stop.
- Credentials and tools the agent holds, and who approved each. Autonomy creeps when someone quietly adds a tool or connection.
- Reversibility window: how long before an action becomes irreversible.
Data and Source Integrity
- Provenance of training and inference data, including historian integrity and time sync.
- Sensor drift and spoofing: the model trusts its inputs more than an experienced operator would.
- Poisoning and prompt injection through ingested content like work orders, vendor manuals, and tickets. That’s a new attack surface cyber registers don’t list.
- Model drift and silent vendor updates. A model update is a process change and should trigger management of change.
Human-Control Boundaries
- Defined approval gates, and a tested override and kill switch.
- Can operators run the plant when the AI is down? Skill atrophy is a real, slow-moving risk.
- Automation bias: will an operator actually catch a confident, wrong recommendation?
- Named accountability for AI-driven decisions. “The model did it” is not an owner.
Downstream Impact
- Consequence mapping to physical outcomes: safety, environmental, equipment, grid or pipeline stability.
- Common-mode failure. The same model deployed across a fleet means one flaw hits every site at once. Traditional registers assess sites individually and miss this entirely.
- Cascading effects into interconnected systems and counterparties.
- Regulatory exposure (NERC CIP, TSA directives, etc.) when an autonomous action changes a compliance-relevant state.
The one-line version for the audience: cyber registers ask “what if someone attacks it?” Industrial AI registers must also ask “what if it works exactly as built and is wrong?”
Gary Tillery of Skkynet and Matt Morris of EverLine provided these answers after the “It Can’t Happen to Me – Until It Does” session at the Industrial AI Summit 2026. The session also featured Ian Bramson of Black & Veatch and Scott Christensen of GrayMatter. Sponsored by Skkynet.
Related from IIoT World
