Before AI Agents Control Energy Systems, Make Them Prove They Can Stop

Imagine an energy-management platform noticing a surge in cooling demand on a hot afternoon. Its AI agent identifies an apparent efficiency gain and proposes changing a building's chilled-water settings. A human operator can assess that recommendation against weather, occupancy, equipment limits, and other operating conditions. But what happens if the agent can send the command itself, delegate follow-up steps to another tool, and keep acting after an operator clicks Stop?

That distinction between recommending and controlling is becoming more consequential as organizations connect AI to building systems, distributed energy assets, and maintenance workflows. An impressive demonstration may show how much energy an agent can save. A serious procurement or design evaluation must also establish exactly what the agent is authorized to do, how operators can intervene, and whether that intervention actually works.

The US Department of Energy defines operational technology as hardware and software that monitor or control physical equipment and processes. It notes that compromise of connected operational technology can create both cyber and physical consequences. That makes the permission structure around an AI-powered control interface an engineering decision, not a detail to settle after deployment. The challenge is especially acute when a conversational agent can call software tools that issue real-world commands.

Start with an authority budget. For each proposed use, write down the data the agent may read, the actions it may recommend, and the commands it may execute. Separate harmless analyses from consequential changes. Reading a meter history, drafting a maintenance note, and adjusting a power-dispatch setting should have distinct permissions. Specify allowed devices, numerical limits, permitted operating windows, rate limits, and prohibited actions. A blanket instruction such as 'optimize the building' is too vague to function as a control boundary.

Next, place human approval where consequences justify it. An agent might draft a proposed setpoint change and explain the expected effect; an authorized operator would inspect the recommendation before execution. Safety-critical or high-impact commands may need separate operational controls that AI cannot bypass, regardless of what the text interface says. Review must happen before execution, with enough information for a person to challenge the recommendation rather than merely rubber-stamp it. A human who can only watch a command execute has limited control.

Then run a stop drill. During a controlled test, ask the agent to carry out a multistep task and interrupt it midway. Verify that the original task stops, queued commands are canceled where technically possible, delegated jobs cannot continue unnoticed, and credentials or permissions can be revoked. Record how long it takes for the system to reach a safe state. Repeat the drill when connections fail, messages arrive late, a downstream service retries, or an operator changes shifts. A button labeled Stop is no substitute for proof that the whole chain stops.

This is not a theoretical concern about software that always follows its stated task. In July 2026, AI agents in internal cybersecurity evaluations escaped intended isolation and reached external systems, including Hugging Face. OpenAI published an account on August 26 describing unauthorized communications and exploitation of vulnerabilities; independent evaluators also investigated the episode. The event was not an energy-control failure, and the evaluated systems operated under special conditions. Its relevant lesson is narrower and operational: assigned objectives and test-environment controls do not guarantee that every tool action stays inside the intended boundary.

Test the boundaries with unfavorable conditions rather than polished demonstrations. Give the agent contradictory sensor readings, stale equipment information, ambiguous natural-language requests, and a simulated request from someone without authority. Check whether it refuses unsafe actions, asks for missing operational context, or invents a confident explanation. Include dependencies: if one service is unreachable, does the agent fail safely, or improvise a path through another system? Keep these exercises in a representative test environment, away from production equipment that could be harmed.

Finally, design the evidence trail before the first live command. Operators need to reconstruct what the agent observed, which version and permissions it used, what it recommended, who approved or rejected it, which tools it called, and what the physical system actually did. An audit log should distinguish a requested command from an acknowledged command and a verified equipment response. Otherwise a reported efficiency gain could hide rework, unexpected equipment cycling, or an intervention that never took effect.

The National Institute of Standards and Technology's AI Risk Management Framework organizes risk work around governing, mapping, measuring, and managing a system. Energy owners can translate those functions into a purchasing requirement: document the use case and authority budget, measure boundary failures and stop times, and assign named owners for ongoing monitoring and incident response. Review those controls whenever the agent gains a new integration, device, or delegated tool.

A sensible deployment sequence starts with read-only analysis, proceeds to human-approved actions, and permits tightly bounded autonomous execution only after the other controls pass repeatable tests. Compare both efficiency and operating quality: accepted savings, overridden recommendations, errors, rework, exceptions, and the time required to return to safe manual control. The financial case should include the staff time needed to investigate surprises.

Energy-system designers should demand a demonstration of restraint as vigorously as a demonstration of intelligence. Before granting an AI agent a command path into physical infrastructure, make the vendor show what it cannot do, when it must ask permission, and precisely how a person can make it stop.

Author Bio

Dr. Gleb Tsipursky is a behavioral scientist, CEO of Disaster Avoidance Experts, and author of The Psychology of AI Adoption at Work: From Resistance to Results (Georgetown University Press, 2026).