AI Agents in OT: How Shadow AI Creates Operational Security Risk

AI agents can create risk in operational technology (OT) environments even when an organization has never formally deployed AI into its control systems. If an AI tool runs on an authorized engineer’s or technician’s device, it may be able to operate within the same authenticated session and permissions that user relies on to access OT systems.

This reality challenges an assumption our team continues to hear in industrial circles: “AI hasn’t reached OT yet. We make sure not to enroll any AI tools in our environment.”

And it’s true that most plants have not formally deployed AI agents inside cyber-physical systems (CPS) or OT environments. But that doesn’t mean AI-related risk stops at the OT boundary. 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 a logged-in user. In industrial environments, where engineers and technicians routinely connect to SCADA dashboards, maintenance systems, configuration interfaces, and remote access portals, this distinction matters.

Simply put, AI does not need to be embedded inside a PLC or control application to influence operations. It only needs to operate through an identity or device that already has access.

Can AI Agents Access OT Systems Without Being Formally Deployed?

Potentially, yes.

Engineers and technicians are natural problem solvers. An employee might install a local AI agent to automate reports, analyze logs, troubleshoot a problem, or simply experiment with a new tool. In other cases, AI capabilities may already be embedded within approved productivity software.

Instead of asking whether AI has been officially deployed in the OT environment, ask a more practical question: What can the device running the AI tool already access?

If an engineer’s endpoint has authorized access to remote access portals, operational dashboards, or shared production data, an AI tool operating within that user’s session may be able to act within those same permissions.

Neither the employee nor the AI tool needs to be malicious for this to create risk. The risk comes from inherited privilege. When an AI agent can act through the operational reach of a trusted user, its actions may affect systems far beyond the endpoint where the AI tool is running.

Why AI Agents Can Create Serious Risks in OT Environments

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 AI Assistant Makes the Wrong Decision

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 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 important historical production data.

No attacker was involved — just a well-intentioned tool acting through authorized access without understanding the operational consequences.

Scenario 2: When AI Troubleshooting Fixes One Problem but 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.

What Is Shadow AI Access in OT?

These examples illustrate a challenge many OT teams have yet to account for: shadow AI access.

Shadow AI access is the use of legitimate user, device, or session permissions by an AI tool without formal oversight or governance of the AI itself.

In other words, the AI does not necessarily need its own identity. It may operate through the access already granted to a trusted engineer, technician, administrator, or endpoint.

This creates a major blind spot for security and operations teams that evaluate AI risk only by asking whether AI has been formally deployed into the control environment.

In the case of shadow AI, the AI may not be “inside” the OT system in the traditional sense. But if it can act through a device or authenticated session that has OT access, that distinction becomes much less meaningful.

Shadow AI access can amplify risk in three significant 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 may 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 may operate within the permissions of the logged-in user, well-intentioned changes can scale across connected systems, dashboards, files, or interfaces in seconds.

How Can Security and Operations Teams Reduce Shadow AI Risk in OT?

One of the most effective ways to minimize shadow AI risk is to restrict what trusted identities and devices can reach in the first place.

If AI tools can inherit or act through an authorized user’s permissions, then controls that limit unnecessary human privilege can also limit the potential reach of AI operating through that identity.

Industrial organizations should reinforce several core access-control practices.

Enforce Least-Privilege Access

Users should have only the permissions required to perform their jobs.

If an engineer does not need the ability to modify a particular system, delete a particular class of production data, or access a particular configuration interface, that access should not be available by default.

Reducing unnecessary privilege reduces the potential blast radius of both human error and AI-assisted actions.

Strengthen Role-Based Permissions

Access should reflect a user’s operational responsibilities rather than providing broad permissions simply because someone is a trusted employee.

Clear role-based access controls can help prevent a single authenticated session from having extended reach across multiple operational systems.

Segment Critical OT Systems

Segmentation between zones and conduits can help prevent one authorized endpoint or session from reaching systems beyond what is operationally necessary.

These principles are already familiar to organizations implementing frameworks such as ISA/IEC 62443. And rather than making these controls obsolete, AI makes disciplined implementation of them even more important.

Treat Trusted Identities as a Security Boundary

OT security programs have traditionally focused heavily on keeping unauthorized users out. AI agents introduce a new question: What happens when a trusted identity is used in a way the organization did not anticipate?

Security teams should consider not only whether a user is authorized but also what that identity can access and what tools may be capable of acting through the resulting session. In addition, they should maintain visibility and control throughout each session, including the ability to terminate a connection in real time if unusual activity is detected.

AI in OT Is Ultimately an Access-Control Problem

The most pressing AI risk facing modern industrial organizations may not come from the AI systems they intentionally deploy. Instead, it likely comes from AI tools already operating on trusted devices and inside authenticated user sessions.

This is why organizations shouldn’t wait for a formal AI-in-OT project before considering the security implications posed by AI agents and other AI-powered tools.

As we’ve seen, AI agents in OT can create operational risk without ever being directly deployed into a PLC, SCADA system, or control application. If the AI can act through a trusted identity with OT access, the risk already exists.

The practical response is not to abandon existing OT security principles in favor of a new AI-specific security strategy. It’s to apply those principles more rigorously: least privilege, role-based access, microsegmentation, controlled identities, and zero-trust thinking.

In a new reality where AI can act through trusted users and devices, strong access controls remain one of the most effective ways to prevent a well-intentioned AI action from becoming a security, compliance, or operational incident.

Frequently Asked Questions about AI Agents and Shadow AI in OT