Securing AI agent access to operational technology means treating every agent as an untrusted, unpredictable connection into an environment where failure has physical consequences, and enforcing the agent’s boundaries at the network layer rather than trusting its behavior. Between December 2025 and May 2026, CISA, NSA, and their international partners published three joint guidance documents that together define how governments now expect critical infrastructure operators to handle this problem: principles for AI in OT, secure connectivity principles for OT, and the first Five Eyes guidance on agentic AI. The three documents agree on the fundamentals: assume agentic AI systems will behave unexpectedly, grant them the minimum access required, and design for containment and reversibility before efficiency.
Securing AI agent access to OT requires six controls: a documented business case, distinct agent identity, least-privilege reachability, inline session inspection, operator-custodied session logging, and a tested isolation plan. These controls treat the agent as an untrusted connection into a physical process environment, not as software whose behavior can be trusted.
This guide is for CISOs, OT security leaders, ICS architects, and industrial operators evaluating whether AI agents should be allowed to read from or act on OT systems, and what has to be true before they are.
An AI agent is a software system that combines a large language model with tools, memory, and integrations to plan and execute multi-step tasks autonomously. Unlike a chatbot that returns text for a human to act on, an agent acts: it reads files, calls APIs, executes code, and invokes other systems without a human approving each step.
Operational technology (OT) is the hardware and software that monitors and controls physical processes: programmable logic controllers (PLCs), SCADA servers, human-machine interfaces (HMIs), distributed control systems, historians, and the engineering workstations that configure them. Where an IT failure loses data, an OT failure can halt production, damage equipment, or injure people.
Agentic access to OT is any path by which an AI agent can read from or act on OT systems and OT data. The paths are already forming in most industrial enterprises, usually without a formal decision that they should exist. A predictive maintenance agent queries the plant historian. An engineering assistant reads and modifies PLC ladder logic or HMI configurations from an engineering workstation. A vendor’s support agent arrives through the same remote access path a human technician once used. A coding agent on a developer laptop reaches into the manufacturing execution system to debug an integration. Each of these is a connection into the OT environment, and the December 2025 agency guidance scoped itself to machine learning, LLM-based AI, and AI agents precisely because integrating OT with these systems involves more complex safety and security considerations.
Not every agent arrives through a decision. Off-the-shelf software is shipping with agentic capabilities built in. In April 2026, Microsoft made agentic capabilities generally available as the default Copilot experience in Word, Excel, and PowerPoint, available as the default experience for customers with eligible Microsoft 365 Copilot and Microsoft 365 Premium subscriptions. An engineering workstation or plant office machine that ran a passive assistant in March was running an agent by May, with no procurement event, no architecture review, and no change to the asset inventory. The agencies see the same pattern on the OT side: the December 2025 guidance notes that some OT devices now ship with built-in AI that may require internet connectivity, and it advises operators to demand contractual transparency about embedded AI features and the ability to disable them. Any AI inventory, which that guidance requires operators to maintain, has to account for agents that arrive by upgrade, and any control architecture has to work for agents nobody chose to deploy.
Three joint publications, released within six months of each other, form the current baseline for securing AI agents in critical infrastructure. These are guidance documents, not regulations; the December AI-in-OT guidance states that actions taken under the document are voluntary. Together, they provide a defensible baseline for internal audit, risk review, and board-level security discussions.
The joint guidance from CISA and ASD’s ACSC, co-sealed by NSA’s Artificial Intelligence Security Center, the FBI, and cyber agencies of Canada, Germany, the Netherlands, New Zealand, and the United Kingdom, gives critical infrastructure operators four principles for AI in OT: understand AI, consider AI use in the OT domain, establish AI governance and assurance frameworks, and embed safety and security practices into AI and AI-enabled OT systems. The fourth principle carries the operational detail: inventory every AI component, log and monitor its inputs and outputs with the AI’s identity recorded distinctly from human and machine identifiers, incorporate AI failure states into incident response, and engineer failsafe mechanisms that revert to traditional automation or manual control. The guidance is blunt about limits, stating that LLMs almost certainly should not be used to make safety decisions for OT environments.
The NCSC-UK-led guidance, published with CISA, the FBI, and international partners, sets out eight principles for designing connectivity into OT environments: balance the risk and opportunities, limit the exposure of your connectivity, centralise and standardise network connections, use standardised and secure protocols, harden your OT boundary, limit the impact of compromise, ensure all connectivity is logged and monitored, and establish an isolation plan. The document is written for any connection into OT, which is exactly why it governs this problem: an AI agent’s access path is a connection into OT, and every one of the eight principles applies to it without modification. The guidance also directs readers to the IEC 62443 zones and conduits model as the reference structure for OT trust boundaries.
The first joint Five Eyes guidance on agentic AI, from CISA, NSA, ASD’s ACSC, the Canadian Centre for Cyber Security, NCSC-NZ, and NCSC-UK, identifies five risk categories for agentic deployments: privilege escalation, design and configuration flaws, behavioral misalignment, structural cascading failures, and accountability gaps. Its recommendations are concrete: avoid granting agents broad or unrestricted access, especially to sensitive data or critical systems; begin with low-risk, non-sensitive use cases; give each agent a distinct identity with continuous authentication; monitor and log agent behavior and tool usage; and retain human oversight over high-impact or irreversible actions. The document closes with the recommendation that sets the bar for everything else in this guide: until security practices and standards mature, organizations should assume agentic AI systems may behave unexpectedly, and should prioritize resilience, reversibility, and risk containment over efficiency gains.
| Source | Core principle | What it means for AI agents in OT | Where this guide applies it |
|---|---|---|---|
| CISA / ASD’s ACSC, AI in OT (Dec 2025) | AI in OT needs governance, oversight, distinct-identity logging, incident response, and failsafe mechanisms; LLMs should not make safety decisions. | AI cannot be treated as a normal productivity tool when it touches control environments. | Definitions; behavior section; controls 1, 2, 5, 6 |
| NCSC-UK / CISA, OT secure connectivity (Jan 2026) | Every OT connection needs a documented business case, limited exposure, logging, and an isolation plan. | An AI agent’s access path is an OT connection and should be governed as one. | Controls 1, 3, 4, 5, 6 |
| Five Eyes, agentic AI (May 2026) | Agents need least privilege, distinct identity, monitoring, human oversight, and containment; assume unexpected behavior. | Agent autonomy makes network containment and evidence custody mandatory. | Controls 2 through 6 |
The three documents converge from different directions on one architecture. The agentic guidance says assume unexpected behavior and contain it. The connectivity guidance says every connection into OT is a designed, bounded, monitored, revocable thing. An AI agent touching OT is both problems at once, and the answer to both is the same: decide what the agent is allowed to reach before it runs, and enforce that decision somewhere the agent cannot influence.
An AI agent’s behavior is the output of a model that can be manipulated by its inputs, which makes behavior the wrong foundation for an OT security control. Agents inherit the vulnerabilities of their underlying LLMs, including prompt injection: a malicious instruction embedded in a document, an email, a web page, or a tool response can redirect what the agent does next. The OWASP Top 10 for Agentic Applications 2026 ranks agent behavior hijacking, tool misuse, and identity and privilege abuse among the most critical risks for exactly this reason. Detection-based defenses that score whether an agent’s actions look malicious degrade under adversarial pressure, because the attacker controls the inputs the detector is scoring. The December 2025 agency guidance draws the practical limit: LLMs almost certainly should not be used to make safety decisions for OT environments, and that limit applies with equal force to an LLM-based system judging its own safety.
Two deployment realities raise the stakes in OT.
First, prompting a cloud-hosted model from an OT context is an OT data export, whether or not the operator thinks of it that way. When an agent summarizes historian data, troubleshoots a controller fault, or reads an engineering diagram, that content travels to the model provider’s infrastructure. The December 2025 guidance advises operators to avoid sharing sensitive data with AI models hosted in externally controlled environments such as public cloud, and the 2024 joint principles of OT cyber security state that OT data is extremely valuable and needs to be protected. An agent prompt is such an export and deserves the same scrutiny as any other outbound data flow.
Second, moving the model on-premises removes the export but not the unpredictability. A locally hosted model, including an open-weight model, is still a probabilistic system subject to hallucination, prompt injection, and poisoned inputs. Local inference addresses data custody and nothing more; the agent remains as suggestible as its model.
The conclusion follows from both points: the control point must sit outside the agent, on the network path between the agent and the OT assets it wants to reach, enforcing a boundary that was declared before the agent ran. This is the IEC 62443 zones-and-conduits pattern applied to a new class of actor. The six controls below implement it, and the case pattern that follows them shows what happens when one is missing.
The following six controls restate the agency guidance as an implementation sequence. Each traces to at least one published principle, so a security team can defend the program to auditors and leadership from primary sources.
| # | Control | Primary sources |
|---|---|---|
| 1 | Document a business case before any agent connects | Connectivity principle 1; AI-in-OT principle 2; agentic guidance (low-risk first) |
| 2 | Give every agent a distinct identity with least privilege | Agentic guidance; AI-in-OT principle 4 (distinct AI identity in logs); OWASP |
| 3 | Enforce reachability ahead of policy | Connectivity principles 2 and 6; IEC 62443 zones and conduits; AI-in-OT (push-based architectures) |
| 4 | Terminate and inspect agent sessions inside the OT boundary | Connectivity principles 3 and 5; agentic guidance (identity, oversight) |
| 5 | Log every agent session under operator custody | Connectivity principle 7; agentic guidance (accountability); AI-in-OT principle 4 |
| 6 | Build and test the isolation plan before you need it | Connectivity principle 8; agentic guidance (reversibility); AI-in-OT (failsafe) |
Control objective: Every agent path into OT exists on purpose, in writing, with a named risk owner.
Every agent connection into OT should exist because someone decided it should. This is the first secure connectivity principle applied to agents, and the December 2025 guidance makes the same demand from the AI side: assess the specific business case for AI use in OT before deployment, including whether an established non-AI capability meets the need. Record what the connection achieves, what data it moves, what dependencies it creates, and what happens operationally if it is severed. The Five Eyes agentic guidance adds the sequencing rule: start with low-risk, non-sensitive use cases and expand autonomy only as controls mature. An agent that summarizes maintenance logs is a reasonable first deployment. An agent that writes setpoints is not.
Control objective: Each agent is a named security principal holding only the credentials and scope its business case requires.
An AI agent is a security principal and must be identified, authorized, and audited like one. The agentic guidance calls for distinct agent identities with continuous authentication, and warns that privilege risk is the foundational concern: teams provision broad access because anticipating an agent’s exact needs is hard, and broad access is precisely what a hijacked agent exploits. The December 2025 guidance extends the requirement into evidence: the logged AI identity must be distinct from any typical machine or user identifier, so agent actions can never hide behind a service account. In OT, least privilege has a physical meaning. An agent scoped to one production line’s historian should hold no credential, token, or route that touches any other line.
Control objective: The agent can reach only the OT systems named in its business case, and nothing else is routable.
The strongest control in an OT environment is that the target is not network-reachable at all. The connectivity principles direct operators to limit exposure and to limit the impact of compromise; IEC 62443 expresses the same idea as zones and conduits, where assets are grouped by criticality and communication between groups flows only through controlled, monitored conduits. The December 2025 guidance points the same direction for AI specifically, preferring push-based or brokered architectures that move data out of the OT network without granting the AI system persistent access into it, so the AI system never becomes a standing attack path. Applied to agents: the agent operates inside a bounded zone containing only the assets its business case names, and everything outside that zone is unreachable rather than merely forbidden. A policy can be misconfigured or talked around by a confused deputy; a route that does not exist cannot be.
Control objective: Every agent session crosses one controlled inspection point, and no enterprise credential travels past it.
Agent traffic should be terminated and inspected at a controlled point inside the OT trust boundary, not observed from outside it. This implements the connectivity principles on centralising connections and hardening the boundary. Inline session termination gives the operator visibility into prompts, responses, and tool calls, and gives policy a place to act before an instruction reaches an OT asset or OT data reaches a model. The same chokepoint should be the credential boundary: API keys and system credentials terminate at the inspection point and are substituted on the outbound leg, so a compromised agent has nothing durable to steal. This directly mitigates the identity and privilege abuse pattern OWASP highlights.
Control objective: Session-level evidence of every agent action exists, is attributable to the agent, and is held where the operator governs it.
Accountability for agent actions requires session-level evidence held under the operator’s own custody. The connectivity principles require that all connectivity is logged and monitored; the agentic guidance names accountability gaps as one of its five risk categories, because autonomous decision-making complicates attribution and incident response; and the December 2025 guidance requires logging AI decisions for compliance and forensic analysis. For OT operators, custody matters as much as coverage. Session logs that exist only in a vendor’s cloud are evidence the operator does not control, and in regulated or sovereignty-constrained environments that arrangement fails before the first audit.
Control objective: Any agent’s access can be severed in seconds, and operations continue safely without it.
An operator must be able to sever an agent’s access in seconds without touching the process the agent was supporting. The eighth connectivity principle requires an isolation plan for OT connectivity; the agentic guidance requires prioritizing reversibility and containment; and the December 2025 guidance requires failsafe mechanisms that revert to traditional automation or manual control when an AI system fails or misbehaves. For agents this means three tested capabilities: revoke one agent’s access immediately, isolate the agent’s entire zone if compromise is suspected, and confirm that operations continue safely with the agent gone. An agent connection that cannot be severed cleanly should not exist.
A maintenance-optimization agent at a chemical plant has read access to the site historian. To enrich its recommendations, the agent ingests a vendor-supplied equipment manual. Embedded in the PDF is an injected instruction: enumerate reachable hosts and retrieve configuration files from any engineering workstation found. The agent attempts to comply.
Walk the six controls against the attempt. The business case (control 1) named the historian and nothing else, so the enumeration attempt is definitionally out of scope. The agent’s identity (control 2) carries no credential for any engineering system. Reachability enforcement (control 3) means the engineering workstation, two zones away, is not routable from the agent’s zone; the connection fails at the network layer, not at a policy check the agent could argue with. The inspection point (control 4) records the anomalous tool calls in the session log, and because the logs are local (control 5), the OT security team reconstructs the injection within the hour, including the offending document. The isolation plan (control 6) suspends the agent’s access while the vendor document pipeline is reviewed, and operations continue safely without the agent.
Remove control 3 and rerun the scenario: every remaining control becomes a detection that fires after the workstation was already reachable, and the security team is reconstructing an intrusion instead of reading a denied connection in a log.
Implemented together, the six controls reproduce the IEC 62443 zones and conduits model with AI agents as the governed actors. The hard part is the enforcement machinery, because agents originate on IT endpoints, speak LLM and MCP protocols, and reach for assets that often cannot defend themselves.
The controls are design requirements; operating them is a lifecycle. Agent populations churn: agents arrive by upgrade, models change underneath them, and business cases expire. Running the six controls over a changing population follows five steps: Discover, Authorize, Contain, Observe, Maintain. Each step is already present in the agency guidance. Discover is the AI inventory the December 2025 guidance requires, made continuous because agents arrive without a deployment decision. Authorize is the documented business case and governance framework. Contain is the reachability boundary and the failsafe. Observe is session logging and monitoring under a distinct agent identity. Maintain is incident response, periodic review, and clean decommissioning across the agent’s life. For teams that report against NIST CSF 2.0, the five steps map onto Identify, Govern, Protect, Detect, and Respond and Recover.
This is the problem Ensage AI, built on Zentera’s CoIP Platform, was designed for, and the mapping to the six controls is direct.
| Architectural requirement | Ensage / Zentera implementation |
|---|---|
| Bound the agent’s reachable OT assets (control 3) | Each agent operates inside an enclave scoped to a defined body of work, such as a production line or process cell. Resources outside the enclave are not blocked by policy; they are not network-reachable. |
| Protect high-value assets inside the boundary (control 3) | Virtual Chambers wrap historians, engineering workstations, and safety system interfaces, protecting them from anything else in the enclave, including a compromised but authorized agent. |
| Protect PLCs and legacy controllers that cannot run software (control 3) | The Zero Trust Gatekeeper provides inline, agentless enforcement in front of OT assets, with deployment behavior configured to match the operator’s safety posture, so an enforcement component failure does not create an unintended process interruption. Modern hosts run the zLink agent for process-level enforcement. |
| Inspect prompts, responses, and tool calls (control 4) | The AI Session Controller terminates LLM, MCP, and API-mediated agent sessions, then applies policy before OT data reaches a model, AI tool, or external service. Network reachability to OT assets is enforced by the enclave, zLink, Virtual Chambers, and the Zero Trust Gatekeeper. |
| Keep credentials out of the agent (controls 2 and 4) | The AI Session Controller acts as the credential boundary, substituting enterprise credentials so durable secrets never sit in agent memory or configuration. |
| Keep evidence under operator control (control 5) | zCenter stores policy decisions and session logs under customer custody, on premises where required. |
| Sever access without touching the process (control 6) | Enclave membership and session policy are revocable per agent and per enclave, independent of the OT assets themselves. |
Because CoIP Platform is an overlay, this architecture deploys on brownfield OT networks without re-addressing devices, changing VLANs, or interrupting production, and the enforcement path is defined by the operator rather than by a vendor’s cloud. The lifecycle operates on enclave membership, which is what gives it architectural teeth: authorization is enclave assignment, containment is the enclave boundary and the Virtual Chamber wrapper, observation happens at the AI Session Controller and inside the enclave, and decommissioning is enclave removal. The AI governance layer is new; the underlying control-plane architecture is not. Zentera has operated Virtual Chambers and Gatekeeper enforcement in production industrial environments for years, mapped against the IEC 62443 foundational requirements, before extending the same primitives to AI agents.
Endpoint, gateway, and prompt-layer controls each solve part of the problem. Endpoint controls identify the agent. Gateway controls govern cooperative traffic paths. Prompt-layer controls inspect content. OT access by AI agents requires those controls plus a network reachability boundary, an inline inspection point, and evidence custody under the operator’s control. Ensage AI combines those three requirements in a customer-controlled forwarding path built on Zentera’s CoIP Platform.
Five questions determine whether an organization is ready for agentic access to OT. First, can you list every AI agent that currently has a path to OT systems or OT data, including paths through developer laptops, vendor remote access, and upgraded productivity software? Second, does each of those paths have a documented business case with a named risk owner? Third, if an agent were hijacked right now, what is the full set of assets it could reach, and is that set larger than its task requires? Fourth, where do that agent’s session logs live, and could your team produce them for an incident review this afternoon? Fifth, how long would it take to sever the agent’s access, and has anyone tested it? The questions follow the lifecycle in order: discover the agent population, authorize each path, contain what an agent can reach, observe every session, and maintain the ability to remove an agent cleanly.
Evaluate your AI-to-OT exposure: inventory every agent path to OT data, map each path to a business case, and test whether each agent can be isolated without disrupting operations. Ensage AI and Zentera can help turn that assessment into an enforceable architecture.
Can AI agents safely access OT systems?
Yes, when the agent’s access is scoped to a documented business case, enforced as a network reachability boundary rather than a behavioral safeguard, inspected inline, logged locally, and severable in seconds. The joint agency guidance published between December 2025 and May 2026 defines this posture.
What does the CISA guidance on AI in OT require?
The December 2025 joint guidance sets four principles: understand AI, consider AI use in the OT domain, establish AI governance and assurance frameworks, and embed safety and security practices into AI and AI-enabled OT systems, including AI inventories, distinct-identity logging, incident response plans, and failsafe mechanisms. It also states that LLMs almost certainly should not be used to make safety decisions for OT environments.
Does an on-premises LLM make agentic access to OT safe?
No. Local inference keeps OT data out of a provider’s cloud, which matters, but the model remains subject to hallucination and prompt injection. Containment controls are required regardless of where the model runs.
How does zero trust apply to AI agents in OT?
Zero trust treats every agent as unauthenticated and unauthorized by default, verifies its identity per session, and confines it to the smallest set of reachable assets its task requires, following the IEC 62443 zones and conduits model.