Both become dangerous when a system is allowed to act simply because it is already connected and authenticated. In each case, the real failure is excess authority at runtime. A PLC reachable from the internet and an AI agent able to call tools across production both need explicit scoping, because the attacker only has to inherit one trusted path to cause damage.
Why exposed PLCs and privileged AI agents fail for the same reason
Both problems start with trust that is inherited instead of earned. A PLC exposed to the internet can be acted on because it is already reachable and authenticated; a privileged AI agent can do the same when it inherits broad tool access. The governance issue is not the system type, it is allowing runtime authority to substitute for explicit scoping.
That is why the risk model is nearly identical across operational technology and agentic software: once an actor sits inside a trusted path, the environment often treats the request as legitimate. If the path is over-broad, the attacker or malfunctioning agent does not need to break the whole control plane, only to reuse the authority already granted.
What runtime authority means in OT and AI agent governance
In OT, a PLC should be reachable only through tightly defined zones, conduits, and operator workflows. In agentic systems, a tool-capable agent should be constrained by task scope, action scope, and approval boundaries. In both cases, the question is not whether the component is connected, but whether every action it can take is justified by the minimum access required to do the job.
That distinction matters because authentication proves who or what is on the path, not whether the path should exist for every command. A privileged connection can still be unsafe if it allows write, execute, or control operations without a separate decision layer. This is where governance fails most often: teams confuse having a trusted session with having a safe one.
For readers who want the OT side of that comparison, OT and ICS Identity and Access Guide is the most direct reference for shared accounts, vendor remote access, and segmentation in industrial environments. For the agent side, AI Agent Authorisation Guide shows how least privilege, per-action decisions, and just-in-time access change the control model.
Why scoping beats connectivity as a control principle
Connectivity is only a transport property. Governance depends on scope, meaning the system must define what the actor may do, on which assets, under which conditions, and for how long. A PLC with a narrow, monitored command path is materially different from one that can accept arbitrary remote control; an AI agent with a single approved tool invocation is materially different from one that can chain production changes without fresh authorization.
This is why blast radius is the right mental model. When access is over-broad, compromise does not need to be creative, it only needs to be opportunistic. The damage comes from the authority already embedded in the path, whether that path is a remote engineering session or an agent session with production-grade tools.
That governance pattern is also why zero standing privilege is so useful here. If the component should not be acting continuously, the default state should be inert, with elevation granted only for a bounded task and then removed. Zero Trust for AI Agents captures the same principle for tool-using software, and it maps cleanly to industrial control governance as well.
Risk and Threat Considerations
Exposed PLCs and privileged AI agents create the same exposure because both can be abused through trusted access rather than through a classic exploit chain. If the adversary or faulty automation inherits a legitimate path with write or execute authority, the result can be direct operational damage, unsafe actions, or lateral movement into higher-value systems.
Failure mechanism: Excess authority at runtime lets a connected entity issue commands, invoke tools, or change state beyond what the current task requires. In OT that can mean remote manipulation of process logic; in agentic environments it can mean destructive or exfiltrating tool use under an authenticated session.
Impact: The environment treats a dangerous action as routine, which can lead to production disruption, unsafe process changes, data exposure, or chained compromise across dependent systems. The governance failure is especially severe because the trusted path can hide the abuse until the operational effect is already underway.
Practitioner Guidance
What to prioritise: Treat authority scoping as the primary control objective, not merely network reachability or login success. For PLCs, confirm that remote access is zone-bound, time-bound, and operator-approved; for AI agents, confirm that each tool can be invoked only within an explicit task boundary.
What to verify: Ask whether a session can still cause material change after the original purpose has ended. If the answer is yes, the control is too broad. The useful test is whether a compromised session can do more than the minimum work needed for the approved task.
Practitioner takeaway: The safest design is not “authenticated and connected”, it is “connected only when necessary, and only with the smallest authority that still lets the task succeed.”