Does CIP-013-2 apply to every AI vendor used by a utility?

CIP-013-2 applies to defined entities and facilities, plus covered systems and impact categories. The responsible entity should determine whether the AI product or service falls within its covered supply-chain plan. Other utility information and services can remain sensitive or subject to different obligations even when CIP-013-2 falls outside the facts.

Which AI vendor changes should trigger reassessment?

The approved record should name its triggers. A new model family or endpoint can change the basis for approval. The same applies to a new region or subprocessor, a changed retention mode or administrator path, and a changed incident term or material service configuration. Traffic records can surface a changed route immediately, while vendor management decides the required review.

Should a utility retain every prompt and response?

Retention should follow the utility's evidence need, legal duties, information-protection rules, and records schedule. Full content may create another repository of grid and engineering material, plus customer and vendor material. Many reviews can use classifications and fingerprints, controlled references and route metadata, plus policy details and outcomes instead.

Can an AI gateway control vendor-internal inference?

Only when the vendor routes that authenticated HTTP model call through the gateway. A model call made entirely inside a vendor's environment remains outside the utility's proxy. Contracts and architecture documentation must cover that path. Subprocessor records and vendor audit exports belong with the ongoing assurance for it.

AI Vendor Risk in Energy and Utilities Needs a Route-Level Record

A transmission-planning agent sends equipment findings and an outage narrative to an external model endpoint. The request crosses an HTTPS boundary under a service credential, while the provider processes operational context that may never appear in the utility's vendor file. NERC CIP-013-2 requires covered entities to identify and assess supply-chain cyber risk from vendor products or services for specified high- and medium-impact BES Cyber Systems and associated systems. AI vendor risk energy and utilities becomes concrete at the route carrying the data.

I want to keep the NERC scope precise, connect DOE's wider AI supply-chain concern to model vendors, and define the record that joins supplier approval to actual use.

TL;DR

CIP-013-2 applies to named entities and covered high- and medium-impact BES Cyber Systems, rather than every utility AI purchase.
DOE identifies compromise of the AI software supply chain as one risk category for critical energy infrastructure.
Supplier evidence establishes approved conditions; a request record proves which identity sent which data class to which model route.
Inline policy can block an unapproved endpoint or route a permitted request before utility data reaches the provider.

CIP-013-2 sets a bounded supply-chain duty

CIP-013-2 requires each covered responsible entity to develop one or more documented supply-chain cyber risk management plans for high- and medium-impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems and Physical Access Control Systems. Requirement R1 calls for procurement processes that identify and assess cyber risk from vendor products or services, including vendor transitions.

The plan must address applicable vendor incident notification and coordinated response, plus access removal and vulnerability disclosure. Software integrity and authenticity belong in the process too, as does coordination of vendor-initiated remote access. Requirement R2 requires implementation, while Requirement R3 requires review and approval by the CIP Senior Manager or delegate at least once every 15 calendar months.

CIP-013-2 reaches a model provider only when the responsible entity and system, along with the service and facts, fall within its applicability. AI governance for energy and utilities provides the wider portfolio structure. The CIP analysis should remain attached to the covered system boundary.

DOE puts AI supply-chain compromise on the risk register

The Department of Energy's critical energy infrastructure AI assessment identifies four broad risk categories: unintentional failure modes, adversarial attacks against AI, hostile applications of AI, and compromise of the AI software supply chain. DOE also calls for regularly updated, risk-aware guidance as sector use develops.

A utility can use that framing beyond the narrower CIP-013 scope. A model provider may process engineering notes and customer records. It may also process procurement material and source code. Operational-advisory context can be included too. Its model versions and subprocessors can change. Retention settings and regions can change too, as can incident channels, while the approved vendor name stays fixed.

My opinion is that a green supplier status without an approved endpoint is unfinished work. The vendor row can stay green while an engineer selects a different model alias in a gray dropdown. Supplier review needs a technical route definition that policy can evaluate.

The approved service needs exact route attributes

The vendor record should identify the contracted service and tenant, along with the endpoint and permitted model families. It should record the region and retention mode, plus subprocessor terms and administrator access. Incident contacts and change-notice commitments belong in the record with the assessment owner and review date. It should also identify the utility data classes and use cases approved for that route.

Those conditions differ by workload. Public tariff drafting may fit one external service. A request containing protected system information, outage details, vulnerability material, or restricted customer data may require a private deployment or a refusal. The provider's corporate assurance pack lacks the request content and caller needed for that decision.

The physical test is simple: place the data-flow diagram beside the supplier register and trace one red line from the authenticated application to the exact model hostname. If the line ends at a vendor logo, the route definition is too vague. AI vendor risk management covers the procurement layer behind that diagram.

Request evidence proves use inside approved conditions

A useful decision record carries the authenticated person or agent and the calling application. It records the business purpose and asset or programme context supplied upstream, plus the request classification. The provider endpoint and tenant appear with the resolved model version and region. The record also contains the policy version and outcome, followed by the reason and timestamp. A protected content reference can support later correlation without creating another plaintext repository of utility data.

That record gives security and vendor management a shared object by linking each call to the conditions in the supplier file. It also records requests stopped before transmission. Denied requests matter because they reveal work that needs a sanctioned route or a revised process.

The evidence needs an independent write path. An application can omit an event or fail after receiving a model response. A separate decision point can commit the policy result as traffic passes. AI audit log chain of custody describes the integrity requirements for that record.

Inline policy enforces the reviewed boundary

An inline policy point evaluates the request while it remains under the utility's control. It can match identity and purpose against the approved provider and endpoint. The match can also cover the tenant and model, along with the region and data class. A permitted request proceeds to the reviewed model route. Another request can be redacted or refused. It can also be routed to a private model.

Coverage must stay explicit on the utility's architecture diagram. DeepInspect can govern authenticated HTTP traffic deliberately routed through it. Vendor-internal inference inside an asset-management platform can bypass that path. Local models and OT protocols sit elsewhere, as do protective-relay commands and industrial control logic. Browser sessions that avoid managed routing need browser and endpoint controls, backed by egress controls. Shadow AI in energy and utilities covers those discovery and bypass paths.

Vendor qualification and CIP applicability remain with the utility's accountable teams. System safety and engineering validation remain there too, alongside contract negotiation and incident reporting. The gateway supplies policy enforcement and evidence for one named traffic boundary.

DeepInspect

DeepInspect is a stateless proxy for authenticated HTTP traffic between utility users or agents and LLM endpoints. It evaluates identity and supplied work context, followed by request classification and provider route. It also evaluates the tenant and region, plus the model version and policy, before transmission. The decision can permit, redact, route, or block the request.

Each decision creates a signed audit record with the caller and application, followed by the supplied context and classification. It records the destination and policy version, plus the outcome and reason. The timestamp completes the record. DeepInspect covers traffic routed through this HTTP boundary. CIP scope and supplier qualification remain with the utility, as do OT security and engineering safety, plus vendor contracting and regulatory reporting.

Book a demo today.