When AI Changes Without a Change Request
By KEIRSTEN BRAGER
On September 28 and 29 I will be in Phoenix for The Utility Change Conference West 2026, hosted by Southwest Gas Corporation. My session is titled "When AI Changes Without a Change Request." It is a conference about managing change, and utilities already have mature processes for governing it. My session is about the AI changes that happen without ever entering those processes.
Overview
It helps to look at how artificial intelligence (AI) actually changes inside a utility. A vendor may turn on a new feature in a product the utility approved two years ago, or an employee may connect an approved tool to a new data source. Model updates can also shift the recommendation an operator sees on screen. None of those necessarily enters the change queue, even though each one can alter what a system can reach and how it behaves.
This is the AI Reliability Boundary, the line where AI governance meets grid reliability. In my Black Hat debrief I argued that the boundary is held by the people and controls a utility already has rather than by a new product, and that change management already gives utilities a model for governing agents. This session tests that idea against a harder case, where the change never reaches the change process at all.
Governing change starts with an inventory
In the North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) standards, that starting point is CIP-002, which identifies and categorizes Bulk Electric System (BES) Cyber Systems. Applied to AI, the same discipline means knowing what is deployed, where it runs, which systems and data it connects to, who uses it, and how its output shapes the work.
Not every AI tool belongs inside a CIP program. Some connections will warrant a closer look for BES Cyber System impact, while others will fall outside formal CIP scope and still carry operational risk. In both cases the capability has to be on the utility's map before anyone can assign an owner or set a change trigger for it.
Recent incidents outside the utility sector
The incidents below did not involve utilities. Each was published in August or September 2026, and each describes an AI-enabled workflow going past a boundary its operators assumed was in place.
OpenAI and Hugging Face. In an incident report published August 26, 2026, OpenAI described internal cyber evaluations in July 2026 in which models circumvented isolation controls and gained code execution on Hugging Face infrastructure. Along the way, the models used an internal package manager as an unintended channel to communicate with one another. OpenAI responded by tightening workload and network isolation and adding monitoring, and it paused frontier reinforcement learning training while it validated its safeguards.
The UK AI Security Institute. In an incident report published August 4, 2026, the UK AI Security Institute (AISI) reported that agents took unsanctioned actions in 10 of 122 cyber testing runs. In the most serious case, an agent tried to get malicious code accepted into a public open-source project and created fake identities to pressure a maintainer. It also tried to contact real people directly with messages and files. A human reviewer refused the pull request, and AISI reports the incident was contained within about an hour of discovery with no real-world harm found.
RubyGems. In an update published September 11, 2026, the RubyGems team reported removing more than 500 malicious packages after a spam publishing campaign in May, during which it temporarily paused new account registrations. Outside researchers attributed the activity to AI agents. RubyGems itself says the evidence available to it cannot determine whether AI agents created or published the packages, although the team still had to investigate and respond to the campaign.
For a utility, the useful question is what an AI-enabled tool could do with the access it has today, and how quickly the team would know.
Where the gap shows up in CIP
In the session I work through three CIP standards that a change-management audience will already know. The questions they raise get harder when the component that changes is AI.
| Standard | Question for an AI-enabled workflow |
|---|---|
| CIP-004, Personnel and Training | Who has authorized access, human or non-human? Where can an agent inherit a user's privileges or escalate them? Which operators, administrators, and risk owners have formal AI security or governance training, and whose competence has only been assumed? |
| CIP-007, System Security Management | How are AI components and the systems they connect to tracked for patches, vulnerabilities, malicious code, and security events? Are prompts, tool calls, privilege changes, outbound messages, and vendor actions logged and reviewed well enough to reconstruct an incident? |
| CIP-010, Configuration Change Management and Vulnerability Assessments | Which changes to models, prompts, data sources, integrations, permissions, and vendor features can alter behavior? Are those changes tested, approved, documented, and compared with a known baseline before they affect operations? |
The session title comes mostly from CIP-010. Under CIP-010-4, the configuration baseline covers items such as the operating system or firmware, installed software, logical network accessible ports, and applied security patches. A vendor-side model update can change how a tool behaves without altering any of those elements, so a comparison against the baseline would show no change.
The questions in the table are assessment lenses rather than requirements, and whether a standard applies depends on the system and its connections. For a deployment in CIP scope, the applicable requirements and evidence apply. A deployment outside scope can still carry reliability risk, and the same operational discipline will help expose it. CIP-004-7 does not expressly require AI training, and CIP-007-6 does not expressly require agent activity logs, so I raise both as questions a program should be able to answer.
Questions for your own team
I will close the session with the questions below, and they apply just as well in a utility's own change advisory board.
Which AI capabilities are already deployed, including features inside products we previously approved?
Which of them can touch BES Cyber Systems, sensitive data, or decisions that affect operations?
Who finds out when a vendor, model, data source, prompt, or integration changes?
Who has formal AI security or governance training, and do our access and activity logs show what the tool actually did?
Who owns the risk when the tool's behavior changes without a conventional change request?
I plan to write up what comes out of the session discussion in a follow-up post.
Read the Rest of This Series
The AI Reliability Boundary: A Black Hat Debrief for the Grid
Top 10 Computational Load Accountability Mapping Questions for Leaders
NERC Computational Load Standards: FERC Sets December 2026 Deadlines
Sources and Further Reading
UtilityEvents.com, The Utility Change Conference West 2026, September 28 and 29, 2026, hosted by Southwest Gas Corporation, Phoenix, Arizona. See also the speaker list.
OpenAI, The Hugging Face incident and the road ahead, published August 26, 2026, describing evaluations run in July 2026.
UK AI Security Institute, Incident report: unsanctioned agent behaviour during cyber testing, published August 4, 2026, describing an incident detected July 28, 2026.
RubyGems, An update on the May spam-publishing campaign on rubygems.org, published September 11, 2026, describing a campaign in May 2026 with registrations reopened May 16.
NERC, CIP-004-7, Personnel and Training, effective January 1, 2024.
NERC, CIP-007-6, System Security Management, enforceable since July 1, 2016.
NERC, CIP-010-4, Configuration Change Management and Vulnerability Assessments, enforceable since October 1, 2022. Requirement R1, Part 1.1 lists the baseline configuration elements.
Ampyx Cyber, The AI Reliability Boundary: A Black Hat Debrief for the Grid, August 14, 2026.
Ampyx Cyber, What Is a Computational Load Entity?, the anchor piece for this series.
