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 the governance problem is the same
Exposed PLCs and privileged AI agents fail in the same way: they are allowed to act because they are already trusted, not because each action has been deliberately scoped. That makes runtime authority the real control point. For operational technology, the issue is often reachable control interfaces and shared access paths; for AI, it is tool access that can cross business boundaries without enough restraint.
The governance lesson is that connectivity and authentication are not enough. A system can be legitimate and still be too powerful. If a PLC or agent can execute high-impact actions without an explicit per-task policy, the organisation has delegated operational risk to the network path itself rather than to a control decision.
That is why OT identity and access patterns matter in the field, especially where vendor access, remote administration, or shared accounts still exist. The same logic appears in OT and ICS Identity and Access Guide: if the thing that can change the process is already reachable, governance must focus on who can act, when, and under what constraints.
How excess authority becomes damage
Once a trusted runtime path exists, the attacker or failure mode does not need to defeat the whole environment. They only need to inherit one legitimate channel. In OT, that may mean a reachable PLC, vendor session, or engineering interface. In agentic systems, it may mean a privileged agent that can call tools, access production data, or chain actions across systems.
The practical risk is blast radius. A high-trust control path turns a single compromise, prompt, misuse, or stale permission into a broad operational event. The problem is not merely that the system is connected, it is that the connection also confers authority. That is why AI agent governance has to separate possession of a session from permission to execute an action, as described in the AI Agent Authorisation Guide.
In both cases, the control objective is to narrow the action surface. The PLC should not be reachable as a general-purpose administration endpoint, and the agent should not hold standing rights that outlive the task. When those boundaries are missing, compromise is often just a matter of reusing trust the organisation already granted.
What governance has to change
Governance has to move from asset ownership to action governance. For PLCs, that means treating remote reachability, segmentation, vendor access, and maintenance windows as governance decisions, not just network settings. For AI agents, it means defining task scope, approval boundaries, and tool permissions before deployment, then reviewing them as the business process changes.
The same principle applies across both environments: scope before speed. A privileged runtime should be able to do less by default, not more. That is the design logic behind Zero Trust for AI Agents, where verification and explicit policy are applied to each action rather than assuming a trusted session can keep acting freely.
Teams also need a clearer inventory of where authority exists. In OT that includes engineering workstations, maintenance channels, and controller access. In agentic environments it includes tool grants, delegated credentials, and any service that can execute side effects on the agent’s behalf. A useful benchmark is whether the system can be paused, reviewed, or contained before it can make the next change.
Risk and Threat Considerations
When a PLC or AI agent is exposed with broad authority, compromise becomes easier to turn into real-world impact. The risk is not only unauthorised access, but unauthorised action through a trusted path, which can produce process disruption, data loss, unsafe commands, or uncontrolled downstream execution.
Failure mechanism: The environment grants runtime authority to a system because it is connected and authenticated, then allows that authority to persist across multiple actions without re-scoping, re-approval, or containment.
Impact: A single compromised session, misused credential, or overprivileged agent can trigger high-impact changes across production, because the trust boundary has been converted into an execution path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Exposed PLCs and privileged agents both need scoped authority to limit runtime damage. |
| IA-9 — Service Identification and Authentication | PLC and agent trust depends on authenticated non-human system-to-system access. | |
| SA-9 — External System Services | Remote PLC access and third-party tool access both create governance risk through external trust relationships. | |
| Recommendation — Apply AC-6 to restrict each runtime path to the minimum action set it needs. Use IA-9 to authenticate machine and service interactions before any privileged action. Apply SA-9 to govern external connections, responsibilities, and access conditions. | ||
Practitioner Guidance
What to verify: Confirm that any PLC reachable outside a tightly controlled operations path, and any AI agent with tool access, has explicit action scoping rather than broad ambient permission. If you cannot show the policy decision that limits each action, assume the control is weaker than it appears.
Decision rule: If a system can change production state, treat reachability as insufficient evidence of trustworthiness. Require per-task scoping, segmentation, and a defined approval path before you allow it to operate across environments.
Practitioner takeaway: The real governance control is not whether the system is authenticated, it is whether its runtime authority is narrow enough that one trusted path cannot become one large incident.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org