They should treat the agent as a governed identity with tightly bounded access, not as a generic automation layer. The practical test is whether the agent’s data access, decision scope and action rights can be limited, reviewed and revoked before it reaches production control paths.
When AI agents touch OT data, what changes first?
The first change is not technical novelty, it is trust boundary. Once an agent can read operational data or influence workflows, it becomes part of the control surface and must be treated as a governed principal with explicit scope, approvals, and revocation paths. That means the security team needs to define exactly which OT datasets, decision points, and actions the agent may see or trigger.
In OT, that boundary matters because data is often coupled to live operations, maintenance windows, safety logic, or production decisions. A read-only agent can still create risk if its outputs are consumed by people or systems that trust them too much, and an action-capable agent can create direct operational impact if its privileges are broader than the task needs.
The practical question is whether the agent’s access can be reduced to the smallest useful set, whether its decisions can be reviewed before execution, and whether the access can be withdrawn without breaking the environment. If those answers are unclear, the agent is already too close to production control paths.
How should teams govern access and authority?
Use the same discipline you would apply to any high-impact identity, but tighten it for operational context. The agent should have task-scoped access, short-lived credentials where possible, and an explicit approval model for actions that affect OT workflows, historian data, maintenance records, or orchestration steps. Treat delegated authority as a design choice, not an implementation detail.
AI Agent Authorisation Guide is useful here because it frames least privilege for agents as per-action authorization, not broad session access. Zero Trust for AI Agents reinforces the operational pattern: verify the principal and the request each time, then remove standing privilege wherever you can.
That governance should extend to identity lifecycle, not just initial onboarding. If the agent is retired, repurposed, or moved to another OT domain, its registrations, tokens, embedded secrets, and downstream permissions need to be revoked or re-bound immediately. Otherwise, the control plane becomes a latent access path.
What should security teams watch for in OT-adjacent agent behavior?
Watch for the difference between observation and intervention. An agent that summarizes OT telemetry, maintenance tickets, or asset states is one thing; an agent that can recommend, submit, approve, or trigger workflow changes is another. The more the agent can bridge from data access to action, the more you need logging, step-up review, and containment around each transition.
That is why agent observability matters even in industrial settings. AI Agent Observability, Audit and Incident Response Guide is relevant because teams need attributable logs, kill-switch design, and a way to reconstruct what the agent saw and did. Threat Modelling AI Agents helps teams map where trust boundaries shift from advisory use into operational control.
OT workflows also make false confidence expensive. If the agent can rewrite tickets, update work orders, or populate plant-facing records, then a prompt error or poisoned input can become an operational mistake rather than a harmless misclassification. Teams should therefore treat write access, not just command execution, as a material control decision.
Risk and Threat Considerations
Once an AI agent can influence OT data or workflows, the main risk is privilege expansion through trusted automation. Even without a direct attack, overly broad access can turn a helper into a pathway for unsafe changes, stale data propagation, or actions that bypass human review.
Failure mechanism: The agent is given persistent credentials, broad workflow permissions, or weakly segmented access, then consumes untrusted inputs or ambiguous instructions that lead to unsafe data writes, escalated decisions, or unintended control-path interaction.
Impact: The result can be production disruption, corrupted operational records, unsafe maintenance actions, or a larger blast radius if the same identity reaches multiple OT systems or environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents touching OT workflows create identity and privilege risks. |
| Recommendation — Limit each agent to task-scoped, least-privilege authorization with per-action checks. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agents and OT services need strong machine-to-machine authentication boundaries. |
| AC-6 — Least Privilege | Bounding agent actions in OT workflows is a direct least-privilege problem. | |
| Recommendation — Authenticate each agent-to-service interaction before allowing OT access. Constrain the agent to the minimum access needed for each OT task. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | OT-facing agents should be continuously verified and granted minimal trust. |
| Recommendation — Apply continuous verification and least privilege to each agent request. | ||
| NIST CSF 2.0 | PR.AA-05 — Least privilege access is managed and enforced | The question centers on enforcing minimal access for a governed agent. |
| Recommendation — Enforce least privilege for agent access to OT data and workflows. | ||
Practitioner Guidance
What to verify: Confirm that the agent’s permissions are narrower than the human role it supports, and that read access, write access, and action rights are separated. If the agent can influence OT workflows, require a clear approval checkpoint before production-impacting actions.
Decision rule: If you cannot revoke the agent quickly without affecting unrelated systems, the access model is already too coupled for OT use. If you cannot explain what the agent is allowed to decide on its own, do not move it beyond a non-production boundary.
Practitioner takeaway: In OT, the question is not whether an agent is useful, it is whether its authority can be bounded so tightly that a mistake, compromise, or bad prompt cannot become an operational change.
Related resources from NHI Mgmt Group
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?