Does every prompt containing a substation name fall under NERC CIP?

Applicability depends on the entity and system, as well as the information and effective standard, so the utility's compliance team must make that determination. Internal policy can still classify facility and asset context as operationally sensitive. A request rule can enforce the stricter internal route without claiming that every mention is regulated information.

Should a control-room assistant use an external LLM gateway?

Architecture and safety owners must approve the design with compliance owners. An authenticated HTTP model call can pass through a request policy point. The operational recommendation remains subject to engineering validation and deterministic safety controls. Operator procedures also apply. OT commands and relay traffic that use other protocols remain outside the gateway.

Can redaction protect an uploaded grid diagram?

A diagram can reveal topology and ratings even after names are removed. Device relationships and contingency context may remain too. Field redaction may be appropriate for tightly bounded text. Detailed diagrams often deserve denial on general routes and access only through a specifically approved service, if the utility permits the use at all.

What evidence should a utility retain for denied traffic?

Retain the supplied identity and calling application, plus the purpose and detected category. Also record the destination, active policy, timestamp, and denial outcome. Link the event to the source work item and follow-up action. Repeated attempts may indicate a training gap or missing sanctioned workflow. They may also indicate deliberate policy bypass.

Shadow AI for Grid Operators: Keeping Operational Data on Approved Model Routes

A transmission planner pastes a substation maintenance narrative and a cropped one-line diagram into an AI assistant to produce an executive summary. The prompt carries asset names and equipment condition, along with outage timing and operator comments. If the browser points to a personal model account, that operational material leaves the utility's approved route as one HTTPS request. No control-room command has changed. The information boundary already has.

Shadow AI for grid operators is an outbound data-path problem. It sits beside operational technology security rather than replacing it. The practical question is which authenticated HTTP model calls carry protected grid context. Security teams also need to know who initiated each call and whether its destination was authorized to receive it.

TL;DR

Grid prompts can expose asset identifiers and outage plans. They can also expose network diagrams, maintenance findings, and operator notes.
NERC lists enforceable CIP standards covering information protection and incident response, plus supply-chain risk management.
DeepInspect governs authenticated HTTP AI traffic routed through it. OT protocols and protective relays need separate controls. The same applies to local models and bypass traffic.
Each managed request needs identity, operational purpose, and data classification. It also needs the destination, policy version, and outcome.

Grid context leaks through small prompt fragments

A user does not need to upload a full network model to expose useful operational context. Three paragraphs from an outage plan can identify a facility and its affected equipment. They can also expose the work window, contingency, and unresolved defect. A screenshot may preserve bus names and ratings after the file title is removed. Maintenance logs can reveal firmware versions and access arrangements. They can also expose recurring failure conditions.

The shadow AI pillar describes unauthorized model use across sectors. Grid operators add a strict separation between business assistance and operational material. Public regulatory text may fit a general research route. Substation notes and topology details require a narrower destination, especially when restoration planning is involved. They also require a named purpose.

I would deny network diagrams on general-purpose drafting routes. Redaction can remove a facility name while leaving enough topology and timing detail to expose the operational scenario. A blocked request is cheaper than debating the residual diagram after it reaches an unknown account.

NERC CIP provides the information-protection backdrop

The North American Electric Reliability Corporation's official Critical Infrastructure Protection standards index lists mandatory standards subject to enforcement. The current index includes CIP-008-6 for incident reporting and response planning, plus CIP-011-3 for information protection. CIP-013-2 covers supply-chain risk management. The index also identifies future-enforcement versions separately.

Scope and applicability require the utility's own compliance analysis. An employee's prompt may contain material outside the formal definitions used by a particular CIP requirement while still carrying sensitive operational value. The request therefore needs two labels. One records the applicable regulatory or internal classification, while the other records the operational sensitivity the utility assigns to the content.

An unknown model provider creates a supplier problem too. Security teams need the endpoint and account details, plus the contract terms. They also need information about subprocessors and retention behavior. Region and incident support complete the evidence.

NIST separates critical infrastructure from ordinary assistance

NIST's Trustworthy AI in Critical Infrastructure profile project began in April 2026 and remains ongoing. NIST says the profile is being developed for AI across information technology and operational technology. Industrial control systems are included. Its scope covers safety and security. Reliability and capacity are also covered, along with efficiency.

That project is a risk-management profile under development, rather than a finished grid control catalog. Its developing boundary still helps operators classify model requests. A workforce assistant drafting a procurement summary has a different consequence path than an application using model output in an operational advisory process. AI governance for energy and utilities establishes those use-case lanes and owners. It also defines the required tests and approval depth.

Shadow AI sits outside that approved portfolio. The unregistered assistant has no use-case owner or tested route. It also lacks a documented handoff to operator review. Finding that traffic comes first. Constraining it allows useful tasks to move into the governed path.

Discovery and enforcement cover different utility paths

Secure web gateways and enterprise browsers can reveal consumer AI domains or unusual uploads on managed devices. Endpoint telemetry and DNS monitoring provide additional discovery paths. Egress analysis does too. Those controls are essential because a personal browser session may bypass the utility's model proxy. Endpoint controls also cover local model applications and copied files.

Vendor-managed AI creates another path. Asset-management and outage-management platforms may add model features behind their own interfaces. Engineering and productivity platforms may do the same. Customer platforms create another route. The utility may have no technical route for redirecting those requests. The control set becomes supplier review and application permissions, supported by data configuration and vendor logs.

An authenticated utility application using an HTTP-based LLM can follow a managed route. At that point, HTTP-layer AI policy enforcement can evaluate the request before disclosure. Discovery controls find paths that bypass managed routing. Inline policy decides on traffic deliberately routed to the enforcement point.

A grid request needs operational purpose and identity

The calling application should supply the natural-person or agent identity, plus the role, business unit, approved use case, and work reference. The prompt classifier adds detected asset names and facility details. It also records network information, credentials, customer data, and maintenance language. Destination context identifies the provider account and endpoint.

A policy can allow an engineer to summarize a public NERC filing and restrict inspection notes to a sanctioned private endpoint. It can deny credentials or detailed diagrams on a general route. The rule should also account for source application and declared purpose. An outage-communications tool and an engineering-analysis assistant should receive separate policy even when they call the same model.

For each request, retain the identity and application, along with the purpose and detected data class. Record the destination, policy version, timestamp, and decision as well. Full prompt retention deserves a separate records decision. A content fingerprint and source reference may provide enough evidence without building another repository of operational material.

The OT boundary must stay explicit

DeepInspect inspects HTTP traffic between authenticated users or agents and LLM endpoints when that traffic is routed through its proxy. Traditional OT protocols and protective-relay communications sit elsewhere, as do industrial control logic and local deterministic controls. A blocked LLM request cannot secure a protocol exchange that never traverses the proxy.

If an operational application calls an LLM over authenticated HTTP for advisory analysis, the model call can enter the managed route. The recommendation still requires engineering validation and safety interlocks. Change procedures and operator authority must also apply before it affects operations. Model-output quality and system safety remain separate assurance tasks.

The architecture diagram should use distinct boxes for the model-request path and OT network, plus vendor-managed inference and local execution. That drawing gives auditors and operators a credible answer about coverage. An oversized box labeled AI security hides the ownership boundaries they need.

Incident evidence starts at the route

A routed denied request records preventive control activity before the model receives the prompt. A permitted request provides the user and destination, plus the policy and classification needed for later reconstruction. An alert should connect the event to the utility's data owner and incident process. It should not remain inside a standalone AI dashboard.

Bypass events require different artifacts. Endpoint and browser telemetry may show the copied file and process, along with the account and destination. DNS or web logs can establish timing. Vendor-managed features require provider records. Investigators should preserve the operational source. They must determine which asset, facility, outage, or work package the data described.

NERC applicability and reporting decisions belong to the utility's compliance and incident teams. The gateway supplies route-level facts for the traffic it saw. It never makes the regulatory determination.

DeepInspect

DeepInspect sits inline between authenticated utility applications or agents and HTTP-based LLM endpoints. The application supplies identity and approved operational-purpose context. DeepInspect classifies the routed prompt and checks the destination and role. It then applies versioned policy before an allowed request reaches the model.

Each decision creates an identity-bound record with detected data categories and destination, plus the policy version, timestamp, and outcome. OT protocols and protective relays remain outside this boundary. Local models also remain outside it. So do vendor-managed inference and personal browser sessions that avoid the proxy. The utility's existing operational and endpoint controls cover those paths, supported by its network and supplier controls.

Book a demo today.