FERC's 2026 CIP Lessons Are an AI Change-Control Warning
By KEIRSTEN BRAGER
A Federal Energy Regulatory Commission (FERC) staff report on 2026 Critical Infrastructure Protection (CIP) audits found capability beyond what existing reviews had assessed, in phased generation, shared control centers, and artificial intelligence (AI) tools. Read as a change-control problem, it raises the question of which AI updates should reopen an access approval or a CIP-002 categorization.
Overview
FERC staff released Lessons Learned from Commission-Led CIP Reliability Audits on October 13, 2026. It found increasing use of what FERC calls super intelligence tools inside CIP-networked environments and tied the access those tools facilitate to CIP-004-7 Requirements R4, R5, and R6. FERC's examples are ChatGPT, Google Gemini, and Microsoft 365 Copilot, so this article uses AI for the same tools. Patrick Miller's breakdown of the report covers all three lessons, the staff observations, and FERC's considerations for CIP-005, CIP-007, CIP-011, and CIP-013. This article looks at a question the report raises without answering directly, which is how an AI tool's capabilities stay under change control after approval.
Access authorization assumes an approved tool stays roughly the same until its next review, which is seldom true of AI tools. Vendors add features to software already deployed, connectors get enabled, service accounts pick up scope, and model versions change behind the same product name, often without anyone at the utility submitting a request.
The report's second lesson shows the same gap outside access control. In two arrangements, an unregistered parent company or a shared contractor monitored and controlled generation for several registered Generator Operators from a single control center. The aggregate met medium-impact criteria while each Generator Operator rated its own systems low impact, and none of their categorization processes accounted for the aggregate.
The report does not create a new Reliability Standard, and FERC did not attribute the categorization gaps to AI. The connection drawn here is analytical.
From CIP-010 to CIP-002
An earlier Ampyx Cyber post, When AI Changes Without a Change Request, described how vendor feature activations, new data connections, and model updates can alter an AI tool's behavior without entering a utility's change queue, and how a vendor-side model update can do so without touching any CIP-010-4 baseline element. Read alongside the FERC report, an update that expands what a tool can monitor or control across sites and organizations is a categorization question as well as a configuration one.
Pre-implementation impact analysis usually asks whether a change could disrupt operations. For AI, it should also ask whether the change expands what the tool can monitor, recommend, or execute, and if so, how CIP-002 categorization is affected. Most procedures lack an agreed list of AI changes that should enter that process, and Table 1 offers a starting point.
Table 1. AI Changes That Should Reopen an Access or Change-Control Decision
| Change | What it can change | Evidence to keep |
|---|---|---|
| Identity or service account | Who or what can act, and whether the activity is traceable | Owner, approval, role, credential source, review and revocation records |
| Permissions and tool scopes | Can turn read-only help into write, submit, approve, or execute | Before-and-after permissions, application programming interface (API) scopes, access-test results |
| Connected systems and data | Expands the Bulk Electric System (BES), BES Cyber System Information (BCSI), or operational boundary the tool touches | Connection diagrams, destination allowlists, data-flow records |
| Model or API version | Can alter behavior while infrastructure and product name stay the same | Provider, model ID, version date, release notes, validation, rollback decision |
| Human approval points | Decides whether an action stays advisory or becomes operational | Workflow configuration, approver role, exception path, sign-off evidence |
| Vendor-managed features | Adds capability without the utility opening a change request | Contract notice terms, feature inventory, risk review, disablement path |
| Software package or update | Brings new code, dependencies, or agent functions into an approved environment | Source identity, signature or hash, integrity result, test and install records |
Reviews Tied to the Wrong Events
Read as change-control findings, each of the three lessons describes capability that moved past what an existing review had assessed. In the first, inverter-based capacity came online in phases, and one entity operated above the BES threshold for more than a year because it was waiting to finish every interconnection phase before registering. In the second, monitoring and control sat at a shared control center whose aggregate met medium-impact criteria, while each Generator Operator categorized only its own systems. In the third, entities told audit staff that the scope and ability of these tools "may not be fully understood until after the products or services are active."
The registration and categorization procedures in these findings existed and were tied to the wrong events. For AI, the events that reopen review need to be defined before deployment, including an added connector, a wider permission scope, new write or execute capability, a different model version, or another site or Generator Operator served by the same tool.
The Incentive to Classify Low
FERC did not say why the audited entities under-categorized. In Ampyx Cyber's assessment work, registered entities have sought lower classifications to reduce compliance overhead, at the expense of security protections. The FERC report counts approximately 140 requirements and sub-requirements at medium impact against approximately 15 at low impact, so the incentive is easy to understand.
Some of that is legitimate scoping, since CIP-002 is designed to be risk-based and entities should not over-classify. The concern arises when an arrangement is structured around the bright-line criteria rather than the risk. Splitting control across affiliates, routing it through a contractor, or leaving the aggregator unregistered can each produce a lower rating on paper while operational authority stays concentrated in one place.
AI tools may widen that room, since describing a vendor's AI feature as analytics, or as outside the Electronic Security Perimeter (ESP), is easier than bringing it under the standards. Auditors may ask whether a tool is out of scope because of what it does or because of how it was labeled.
Where Existing CIP Controls Fall Short
Applicability depends on the system, its function, and the architecture, and the table below is not a determination that each AI tool falls under every standard. It focuses on the change-control questions each standard leaves open.
Table 2. CIP Controls and the AI Questions They Do Not Answer Alone
| Standard | What it can show | What it can miss |
|---|---|---|
| CIP-002 | Whether monitoring and control by the entity, affiliates, and contractors was assessed in aggregate | A shared vendor platform with AI features can become the aggregation point without anyone re-running categorization |
| CIP-004 | Whether personnel and AI-facilitated access is authorized, reviewed, and revoked | The person stays authorized while the tool's scopes or downstream access change |
| CIP-005 | External access paths and communications crossing the ESP | Approved, encrypted traffic doesn't show what the tool was doing or why |
| CIP-007 | Account inventories, credentials, logging, and event monitoring | A generic account hides whether a person, workflow, model, or vendor took the action |
| CIP-010 | Changes to baseline elements and evidence they were authorized | Model behavior, prompt logic, vendor API updates, and edits reverted before the next baseline check |
| CIP-011 | Repositories and transfers holding BCSI | Prompts, outputs, caches, logs, embeddings, and vendor support records can become unidentified BCSI repositories |
| CIP-013 | Vendor risk at procurement | Features, integrations, and permissions added after the contract |
| CIP-015 | Future visibility into unusual internal network traffic | Can't attribute intent or see actions local to an endpoint. CIP-015-1 is not effective until October 1, 2028. |
An Illustrative Scenario
The following example is hypothetical but mirrors the shared-contractor arrangement described in the report. Four Generator Operators use the same contractor for remote monitoring of their solar and storage sites, and each rates its systems low impact. The contractor's platform, licensed from a software vendor, was approved to analyze performance and alarm data.
The vendor later adds an AI assistant that drafts setpoint recommendations, and a subsequent release lets it push those values through an existing API under a generic service account the contractor manages. No Generator Operator opens a change request, because none of them initiated the update.
During a troubleshooting task, the assistant changes a setting at one site, retrieves additional data, and restores the original value before any baseline comparison. The service account authenticated normally, and no change request or approval exists for the action.
At that point, a single tool at one contractor can write control changes across the generation of four registered entities. The arrangement resembles the aggregation point FERC described, and the action left no record where a utility normally checks. Reconstructing the event would require evidence from the vendor, the contractor, and all four Generator Operators, including:
The AI run ID, model, and version
The service account, its permissions, and authentication records
API calls, commands, and configuration diffs
Network connections and external destinations
The vendor release that added write capability
The human approval record, or proof there wasn't one
Which AI Changes Should Reopen a Decision?
Patrick's article closes with questions on registration timing, shared control, and AI access for the next audit cycle. The questions below focus on change control.
CIP Senior Manager or delegate:
Which AI capability changes require renewed authorization or a new CIP-002 analysis, and who decides?
Is any classification decision resting on how a function is described rather than what it does?
Change management and governance, risk, and compliance (GRC) teams:
Which model, scope, connector, or workflow updates count as a change under the CIP-010 process, and who is notified when a vendor pushes one?
Do contracts require advance notice of new AI capabilities and provide usable audit evidence?
Executive sponsors:
When the organization buys an AI feature, does the budget include the logging, testing, and rollback needed to govern it?
A Readiness Test
Select one AI-enabled tool used in a CIP-networked environment by the utility, an affiliate, or a contractor. Could the organization produce, within one business day, its accountable owner, approved purpose, identities, permissions, connected systems, external destinations, model and vendor version, change history since approval, and rollback path?
The second question is whether it could show every monitoring and control function the tool can reach across company lines, along with the evidence supporting the current CIP-002 categorization. A gap in the first answer means access was approved without durable change control, and a gap in the second means the CIP-002 categorization may no longer reflect the authority the tool has accumulated.
Sources and Further Reading
FERC staff, 2026 Lessons Learned from Commission-Led CIP Reliability Audits, October 13, 2026
Patrick Miller, FERC 2026 CIP Audit Findings: Generator Registration, Aggregated Control, and AI Tool Access, Ampyx Cyber, October 15, 2026
Keirsten Brager, When AI Changes Without a Change Request, Ampyx Cyber, September 25, 2026
Ampyx Cyber, CIP-015-2 Approved: The FERC Order and the Real Compliance Timeline, the source for the October 1, 2028 CIP-015-1 effective date
North American Electric Reliability Corporation (NERC), CIP-002-5.1a, CIP-004-7, CIP-010-4, and CIP-015-1
