I’ve been hearing the same assumption in industrial circles for quite some time:
“AI hasn’t reached OT yet. We are careful not to enroll any AI tools in our environment.”
While it’s true that most plants have not formally deployed AI agents inside cyber-physical systems (CPS) and operational technology (OT) environments, this doesn’t mean AI-related risk doesn’t apply to industrial control systems (ICS). Because even without a sanctioned rollout, AI may already be operating on devices that have authorized access to critical OT systems and processes.
Modern AI tools can run locally, integrate with installed applications, and function within the permissions of the logged-in user. In industrial environments – where engineers routinely connect to SCADA dashboards, maintenance systems, and remote access portals – this detail matters.
The bottom line: AI does not need to be embedded inside a PLC or control application to influence operations. It only needs to operate within an account that already has access to such environments.
How AI on Authorized Endpoints Introduces Risk
Engineers and technicians are natural problem solvers. An employee might install a local AI agent on their device to help them automate reports, analyze logs, or simply to experiment with new technology. In other cases, AI capabilities may already be embedded within approved productivity software.
The key question is not why the agent is there – it’s what the device can access. An AI agent operates within the same authenticated session as the user. If the device already has authorized access to configuration interfaces, remote access portals, or operational dashboards, the agent inherits that same access.
Neither the employee nor the AI tool needs to be malicious for problems to arise. The risk comes from the inherited privilege. When an AI agent gains the same operational reach as a trusted user, its actions can affect systems far beyond the device itself.
The Real Risk of AI in OT
Industrial control systems are cyber-physical by design. Digital commands trigger mechanical movement, pressure changes, and energy release. When AI agents function inside OT environments using legitimate credentials, even well-intentioned actions can produce physical consequences.
Let’s consider two examples:
Scenario 1: When a Helpful Assistant Makes the Wrong Call.
An engineer instructs an AI agent to help make his laptop run faster. The agent decides that removing large, unused files is the best way to improve performance and promptly deletes several folders.
What the AI cannot recognize is that some of the deleted files are not actually unused data. They are located on a D: drive shared network accessed through the engineer’s remote session and contain archived OT production records required for compliance reviews and operational investigations.
From the system’s perspective, deleting the files is a legitimate action. The engineer had permission to access the files, and they appeared inactive. But the AI agent lacks the operational context to understand that those records contained crucial historical production data.
No attacker took part in this incident – just a well-intentioned tool acting on authorized access without realizing the operational consequences.
Scenario 2: When Fixing One Problem Creates Another
After a routine software update, a technician suddenly loses the ability to connect to a remote engineering system needed for maintenance work. To resolve the issue quickly, she asks an AI agent for help restoring the connection.
The agent identifies the recent software update as the likely problem and recommends reverting to the system’s previous configuration. The technician removes the software update as recommended, and the connection returns.
But once again, the AI agent cannot see the broader context. The update it advised removing addressed a serious security vulnerability affecting remote connections. By rolling the system back, the endpoint becomes operational – but it is also exposed to the very risk the update was meant to prevent.
The New Reality of Shadow AI Access
The examples above illustrate a challenge many OT teams have yet to account for: Shadow AI access. Shadow AI access occurs when AI tools operate through legitimate pathways into operational systems, but without formal oversight or governance.
When AI operates through shadow access paths, it amplifies risk in three critical ways:
- Inherited Privilege at Machine Speed: If a technician has the permission to delete a file or roll back a patch, their AI assistant inherits that same reach.
- Lack of Operational Context: AI tools lack the safety-critical "why" behind OT security protocols. They prioritize the immediate digital task (like improving performance) without understanding the physical or regulatory consequences.
- Automated Scaling: Because AI tools function within the permissions of the logged-in user, well-intentioned changes can scale across connected SCADA dashboards and configuration interfaces in seconds.
Why Access Control Is the Most Effective Safeguard
While traditional OT security measures like perimeter defenses and asset detection remain essential, they cannot stop an AI agent that is already operating within an authenticated session.
In our new age of shadow AI access, the best safeguard is strong identity and access management built on zero-trust principles. Industrial organizations can begin by reinforcing core security practices outlined in frameworks such as ISA/IEC 62443. Least-privilege access, role-based permissions, and segmentation between zones and conduits all help limit the blast radius of both human error and malicious activity.
These same controls can also help organizations govern the identities and permissions that AI tools inherit when operating within trusted user sessions, even as regulations work to catch up with new AI-driven risks.
Ultimately, the most pressing risk to the modern plant may not be the AI systems organizations choose to integrate, but the AI access paths that already exist.
