AI Agents in OT: Governance Rules from the Industrial AI Summit 2026
A panel at the Industrial AI Summit 2026 proposes concrete controls for AI agents in OT systems: unique identities, audit trails, zero trust, and no autonomous agents at Purdue level 0. These are panel opinions, not a standard.
On October 1, 2026, IIoT World published a summary of a panel held at the Industrial AI Summit 2026 on how to govern AI agents in OT systems. The speakers were Scott Christensen (GrayMatter), Gary Tillery (CEO of Skkynet) and Ian Bramson (Black & Veatch), moderated by Matt Morris (EverLine). A note of caution: the article is marked as sponsored by Skkynet, although it states that it is editorially independent, and it discloses that it was summarized with the help of AI tools. What follows are expert opinions, not a standard, and no survey data is provided.
The problem: one agent per vendor
A plant with 20 or more vendors risks ending up with one AI agent for each, every one with its own access model, its own integrations and its own risk profile. Because OT systems are tightly interconnected, a change made by one agent can affect downstream systems.
Audit trails: a generic login is not enough
According to the panel, every agent should have unique credentials, just like a human user. Without them, forensic analysis cannot determine which agent made a change. The log should record:
- who initiated the action;
- the permissions the agent held;
- the data that informed the decision;
- how the change was executed;
- the outcome.
The data chain should be traceable from where the data was generated, to where it was modified, to where a setpoint was recommended, much like supply chain traceability. The record must also show where execution took place and who, or what, authorized it.
Access and architecture
Agents should be managed like employees: role-based, least-privilege access, credentials held in vaults, network segmentation and continuous monitoring. The panel calls for zero trust: no agent is considered trustworthy on any network, and every action requires justification. Any failure should be contained within the segment where the agent operates. Every outbound data flow must be a managed path; more connectivity means more open ports, and, in the speakers' view, the air gap is a myth.
A few clear principles
No single framework covers both OT security and AI agents. The suggestion is to combine IEC 62443 with AI-specific principles, limiting them to 5–10 core principles. The ones cited are:
- least privilege for every agent;
- no autonomous agents at Purdue model level 0;
- mandatory tracking of identity and access for every action;
- assessment of consequences before commissioning;
- analysis of data flows before introducing AI.
Regulated industries, especially in Europe, should expect more prescriptive requirements.
Three questions for Monday morning
- Tillery: if connectivity were interrupted, what would keep running, and who decided that?
- Christensen: do we back up the data, but also the process, meaning configurations and ladder logic?
- Bramson: where is the AI risk register for OT, who owns each risk, and with what priority?
What this means for those working in the field
For those who program PLCs, run SCADA or look after OT systems and are being asked to open up plants to vendors' agents, the panel's contribution is a practical checklist. It ties AI to very concrete topics: backing up configurations and ladder logic, and data integrity in audit trails. A realistic first step is to inventory which agents already touch the plant, check whether they have distinct identities and which data paths they open, and write the risk register. All of this remains, as noted, a set of good practices proposed by a panel: it should be adapted to your own context and to the applicable regulatory requirements.