AI Agents in Energy and Utilities: Control System Boundaries

Utilities are giving AI agents real tools in customer service, outage management, field operations and engineering, and each tool is a possible path from a language model towards the systems that run the grid, the gas network or the water works. This guide is about one design goal: letting agents do useful work in the business and OT-adjacent layers while keeping them structurally unable to reach control systems. It covers where agents are appearing in electricity, gas and water utilities, the boundary they must not cross, what NERC CIP access and information requirements mean for an agent, architecture and identity patterns, threats, rollout and monitoring. It is for utility security, OT and IT architecture teams and the business owners commissioning agents.

Key takeaways

Draw the line at the control system boundary, not at the model. An agent may read data that has been pushed out of OT; it should have no tool, credential or network path that lets it write into an Electronic Security Perimeter or a control zone.
LLMs do not make safety decisions. The December 2025 joint AI-in-OT principles from CISA and partners say AI such as LLMs "almost certainly should not be used to make safety decisions for OT environments", and call for limiting active control without a human in the loop.
OT-adjacent systems are the real frontier. Outage management, work order, historian replicas and engineering document stores sit one hop from control systems, so agent tools there need propose-only design and human approval.
Retrieval indexes can hold BES Cyber System Information. An agent that can search network diagrams, IP plans or substation configurations is a BCSI storage and access question under NERC CIP-011 and CIP-004 R6.
Agents are non-human identities with an owner. Each needs its own identity, scoped read-only credentials by default, a revocation path that works in minutes and logs you can tie back to a person.

Where agents are arriving in utilities

Most utility agent projects start well away from the control room, but the useful ones quickly ask for data or actions that sit closer to it. Map every agent against how far it is from a control system before anything else.

Use	Systems the agent touches	Distance from control systems	Main risk
Customer service: billing queries, payment plans, move in and move out	CRM, billing (CIS), payment platforms	Far: business network only	Customer data disclosure, wrongful disconnection or account changes, prompt injection through customer messages
Outage communications and restoration estimates	Outage management system (OMS) read views, customer notification	Near: OMS may be fed from ADMS or SCADA	Agent tools that reach from OMS into switching or ADMS functions
Field work orders and crew dispatch	Work and asset management, GIS, mobile workforce tools	Near: work orders drive physical switching by crews	A manipulated work order acted on in the field
Engineering and protection document search	Drawings, relay settings files, substation configurations, procedures	Near: contents describe control systems	BCSI disclosure through retrieval; hallucinated or altered procedures
Operations analytics: load forecasts, asset health, alarm summaries	Historian replica, data lake fed from OT	Near: data pushed out of OT	Requests for a live pull or write path back into OT
Energy trading and scheduling support	Trading, scheduling and market systems	Medium: market actions affect dispatch	Unauthorised or erroneous market actions
Security operations triage	SIEM, OT monitoring consoles, ticketing	Near: may read OT network monitoring data	Containment actions that disrupt OT if the agent can act

The general patterns for AI in industrial settings, including authority levels, safety independence and model drift, are in the AI in OT and Industrial Systems Guide. Utility security programme structure is in the Electric Utility Cybersecurity Programme Guide.

The boundary agents must not cross

It helps to name three zones and decide, per agent, which it may read from and which it may act in.

Enterprise zone: CRM, billing, ERP, email, collaboration and the agent platforms themselves. Agents may read and act here within normal least privilege.
OT-adjacent zone: OMS, work and asset management, GIS, historian replicas, the OT DMZ, engineering document stores and OT security monitoring. Agents may read curated data here; any action must be a proposal that a qualified person approves in the system of record.
Control zone: SCADA, EMS, ADMS control functions, DERMS dispatch, substation automation, PLCs and safety systems, and for NERC-registered entities the assets inside an Electronic Security Perimeter. Agents have no tool, no credential and no network route here.

The joint principles for the secure integration of AI in OT, published on 3 December 2025 by CISA with the Australian, Canadian, German, Dutch, New Zealand and UK cyber agencies, the FBI and the NSA AI Security Center, give the architectural direction: "Encourage push-based architectures where data is pushed out of the OT network", use one-way transfer patterns and audited staging buffers where data must reach business networks, "such that the AI system is not a persistent attack path into OT". They also ask for failsafe mechanisms that revert AI-enabled processes to traditional automation or manual operation. For the hardware option, see the Data Diodes and Unidirectional Gateways Guide; for zone design, the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

What NERC CIP means for an agent

For North American entities with high or medium impact BES Cyber Systems, several CIP requirements decide how far an agent can be allowed to go. None of them mentions AI agents, so treat the mapping below as questions for your CIP compliance team and Regional Entity, not settled interpretation.

Requirement	What it says (summarised)	Agent design consequence
CIP-005-7 R1.1 to R1.3	Applicable Cyber Assets sit inside a defined ESP; external routable connectivity goes through an identified Electronic Access Point; inbound and outbound permissions each need a documented reason, with deny by default	An agent platform outside the ESP has no permitted route in unless you document one; the simplest compliant design is that none exists
CIP-005-7 R1.5	Detect known or suspected malicious inbound and outbound communications	Agent-related traffic at the ESP boundary, if any, falls under the same detection
CIP-005-7 R2.1 to R2.3	Interactive Remote Access goes through an Intermediate System, is encrypted to it and requires multi-factor authentication	An agent must never be given a person's Intermediate System session or MFA, and must not drive a remote session on a person's behalf
CIP-005-7 R2.4 and R2.5	Methods to determine and disable active vendor remote access, including system-to-system	A vendor-hosted agent or AI feature with any connection to applicable systems is vendor remote access you must see and be able to cut
CIP-004-7 R4.1 to R4.3	Authorise electronic access based on need; verify quarterly that access has authorisation records; verify privileges every 15 calendar months	Agents should not hold electronic access to BES Cyber Systems; if any automation does, it needs the same authorisation and review evidence
CIP-004-7 R6.1 to R6.3	Authorise provisioned access to BCSI before provisioning; verify every 15 calendar months; remove on termination by the end of the next calendar day	An agent indexing BCSI gives its users a route to BCSI; restrict the index to people already authorised, or keep BCSI out of it
CIP-011-3 R1.1 and R1.2	Identify BCSI and protect it in storage, transit and use, including off-premise BCSI through technical and administrative methods such as encryption and vendor service risk assessments	Embedding stores, prompt logs and model provider caches that hold BCSI are BCSI storage locations, on or off premises

Interactive Remote Access is defined around a person initiating access, so an automated agent connection would not fit it neatly; design so the question never arises. The wider standard set is covered in the NERC CIP Guide, and European obligations in the Energy Sector Cyber Regulation Map.

Architecture patterns that keep agents out

Pattern	How it works	Use it for	Watch for
Pushed replica	OT pushes selected historian tags or alarm summaries through a one-way path or audited staging buffer to an enterprise data store the agent reads	Analytics, alarm summaries, asset health	Requests for "live" data that reintroduce a pull connection
Propose, do not perform	The agent drafts a work order, switching request or outage message; a qualified person approves it in the system of record, which then acts	Field work, outage restoration, customer messages with consequences	Approval fatigue; approvers rubber-stamping long agent outputs
Curated retrieval	A separate document index built from material classified as non-BCSI, with BCSI held in a different index restricted to authorised users	Engineering search, procedures, training	Misclassified drawings and settings files leaking into the open index
Read-only API gateway	Agents reach OMS, GIS or asset systems through a gateway that exposes named read operations only	Status lookups, crew location, asset history	Vendor APIs where read and write share one token
Bounded enterprise action	Agents act directly only on enterprise records with limits (for example payment plan changes within policy) and human review above a threshold	Customer service	Actions with safety meaning, such as disconnection of vulnerable or medically dependent customers, which should always route to a person

Two tool rules hold across every pattern. First, no agent tool library contains functions that speak an industrial protocol or call SCADA, EMS, ADMS or DERMS control APIs. OWASP LLM06:2025 Excessive Agency names excessive functionality, excessive permissions and excessive autonomy as the root causes of damaging agent actions; removing control functions from the library addresses all three at once. Second, the gateway enforces scope, not the prompt: a system prompt that says "never switch anything" is not a control. See the AI Agent Tool and Plugin Security Guide and the Human-in-the-Loop for AI Agents Guide.

Where identity fits

Every utility agent adds non-human identities: the agent's own identity, API keys for model providers, service accounts on OMS or GIS connectors and tokens for vendor platforms. ATT&CK for ICS lists T0859 Valid Accounts as both a persistence and lateral movement technique, so an agent credential that works in OT-adjacent systems is attack surface in its own right.

One identity per agent: never reuse an operator's account, a shared integration account or a vendor's support account for an agent. See the Agent Identity and Access Guide.
Read-only by default: connectors to historian replicas, OMS and GIS are read-only and scoped to the data the use case needs.
No OT credentials in agent reach: engineering workstation, jump host and Intermediate System credentials are never stored where an agent runtime, its memory or its retrieval index can read them.
Delegation is recorded: when an agent acts for a dispatcher or customer service adviser, logs carry both the agent identity and the person, so CIP and incident evidence can attribute actions.
Fast revocation: disabling an agent's identity and gateway access should take minutes and be rehearsed. See the AI Agent Kill Switch and Containment Guide.

Threats mapped to controls

Threat	Utility example	Reference	Control
Indirect prompt injection	A customer email or vendor document instructs the agent to change an account or reveal outage crew locations	OWASP LLM01:2025; MITRE ATLAS AML.T0051	Treat inbound content as untrusted; tool scope enforced at the gateway; approval for consequential actions
Excessive agency	An outage agent given a vendor API token that can also issue switching commands	OWASP LLM06:2025	Read-only gateway; no control functions in the tool library
BCSI disclosure	An engineering assistant returns substation IP plans to a contractor not authorised for BCSI	CIP-011-3 R1; CIP-004-7 R6; ATT&CK for ICS T0882 Theft of Operational Information	Separate BCSI index limited to authorised users; BCSI classification before indexing
Agent credential theft	A model provider key or connector token taken from an agent host and reused	ATT&CK for ICS T0859 Valid Accounts	Vaulted, short-lived credentials; anomaly alerts on agent identities
Vendor AI remote path	A vendor's AI feature in an OT product opens a cloud connection into the plant	ATT&CK for ICS T0822 External Remote Services; CIP-005-7 R2.4 and R2.5	Procurement disclosure of AI features and data flows; route through your remote access controls
Manipulated advice acted on	An altered procedure or work order is carried out by a crew	ATT&CK for ICS T0831 Manipulation of Control	Propose-only design; procedures from controlled document sources; human verification

The joint principles also ask OT vendors to disclose how AI is embedded in their products, including by providing an SBOM, and to disclose if they discover the AI can give improper advice. Put those clauses into utility procurement for any product with agent or AI features.

Rolling out an agent safely

Classify the use case. Record the zone the agent reads from and the zone it acts in, its worst credible consequence and its business owner. Reject any design whose action zone is the control zone.
Check the data. Have the CIP or information owner classify every source the agent will index. Keep BCSI out of general indexes.
Build the gateway first. Expose only named read operations and proposal endpoints; give the agent its own identity and vaulted credentials.
Pilot in shadow mode. Run the agent on real inputs while people do the work, compare outputs and record errors, injections caught and approvals that would have been needed.
Test adversarially. Include indirect prompt injection through customer messages and documents, requests for BCSI, and attempts to obtain control-zone actions. Record the results as change evidence.
Go live with approval gates. Start with every consequential action approved by a person; relax only within the enterprise zone and only on evidence.
Keep rollback simple. Disabling the agent's identity and gateway route returns the process to manual work; rehearse it and confirm teams can operate without the agent, in line with the principles' failsafe expectation.

Decision guidance

Small cooperatives and municipal utilities: agents usually arrive inside vendor CRM, billing or OMS products. Focus on procurement disclosure, turning off write features you do not need, keeping vendor connectivity behind your own remote access controls and making sure document assistants exclude network and substation material.
Large investor-owned utilities and system operators: build a central agent gateway, a register of agents and their credentials, and a standard review for any agent touching OT-adjacent systems, with CIP evidence produced as part of the review.
Water and gas: NERC CIP does not apply, but the same zone model does. Use your sector's OT obligations and the joint principles as the baseline; see the Water Utility Remote Access and Identity Guide.

Detection and measurement

Boundary monitoring: alert on any connection attempt from agent platforms or their hosts towards OT DMZ or control zone addresses, which should never happen. See the OT Network Security Monitoring Guide.
Agent identity behaviour: alert on agent credentials used from unexpected hosts, at unusual volume, or against operations outside their declared scope.
Retrieval monitoring: log which documents each answer drew on, and alert when BCSI-labelled material is returned to a user without BCSI authorisation.

Metrics:

Agents with a documented read zone, action zone, owner and consequence assessment: target 100 percent.
Agent tools or credentials able to reach the control zone: target zero.
Indexed documents classified before ingestion, and BCSI found in general indexes: target 100 percent and zero.
Time to disable an agent's identity and gateway route in exercises: target minutes.
Share of consequential agent proposals approved by a person: track, and investigate falling rejection rates as possible rubber-stamping.

Common failure patterns

Granting a vendor token with write scope because read was "not available": the agent inherits switching or control functions nobody intended it to have.
Indexing the engineering share wholesale: relay settings, network diagrams and IP plans become searchable by anyone who can use the assistant.
Relying on the system prompt as the boundary: prompt injection and model error ignore instructions; only gateway scope and network design hold.
Treating an IT-side agent incident as harmless to operations: in the Colonial Pipeline attack, operational technology was not reached directly, yet the pipeline was shut down as a precaution after a compromise that began with one unused VPN account. A compromised agent with broad enterprise access can force the same decision.
Letting agents act on vulnerable customers without review: automated disconnection or payment decisions for medically dependent customers carry harm that billing rules alone do not capture.

Framework mapping

Framework	Reference	Agent control
NERC CIP	CIP-005-7 R1, R2; CIP-004-7 R4, R6; CIP-011-3 R1	No agent route into the ESP; vendor remote access visibility; BCSI access and storage
NIST CSF 2.0	PR.AA-05, PR.IR-01, GV.SC-05, DE.CM-09	Least privilege for agents, zone protection, AI supplier requirements, runtime monitoring
NIST SP 800-53 Rev. 5	AC-6, AC-17, SC-7, CP-12, SI-4	Least privilege, remote access, boundary protection, safe mode fallback, monitoring
OWASP Top 10 for LLM Applications 2025	LLM01, LLM02, LLM06	Prompt injection, sensitive information disclosure, excessive agency
MITRE ATT&CK for ICS v20	T0859, T0822, T0831, T0882	Agent credentials, vendor remote paths, manipulated control, theft of operational information

Practitioner checklist

Register every agent with its read zone, action zone, owner and worst credible consequence.
Confirm no agent tool, credential or network route reaches SCADA, EMS, ADMS, DERMS or any ESP.
Feed agents from pushed replicas or staging buffers, never live pulls from OT.
Make OT-adjacent actions propose-only, approved by a qualified person in the system of record.
Classify documents before indexing and keep BCSI in a separate, authorised-only index.
Give each agent its own identity with vaulted, read-only credentials by default.
Require vendors to disclose AI features, tools, data flows and SBOMs, and to route connectivity through your remote access controls.
Alert on any agent connection attempt towards OT addresses.
Rehearse disabling each agent and running the process manually.

AI Agents in Energy and Utilities: Keeping Agents Away From Control Systems