In August 2026, the U.S. National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), and other bodies warned of activity that uses AI-generated scripts to conduct reconnaissance on industrial control devices and develop attack capabilities. In September, researchers used AI assistance to port attack code for control devices to a different model, and OpenAI announced a $1 billion initiative to support the defense of critical services. For those protecting power and water systems, the misuse of AI is no longer just a future hypothetical. Still, there is a wide gap between attackers preparing faster and defenders being able to safely fix equipment that is in operation.
Separating AI involvement from actual damage
The joint U.S. government warning covered PLCs in Siemens' S7 series. A PLC is an industrial computer that controls the operation of pumps and various machines. Technology that monitors and controls physical equipment, including such devices, is known as OT (operational technology).
Attackers gathered public information and searched for poorly protected devices reachable from the internet. Authorities observed reconnaissance and capability development using AI-generated scripts disguised as legitimate monitoring tools, and assessed this as preparation for future operational disruption. Targets include the energy and water and wastewater sectors. However, this is not a report that AI autonomously shut down a power grid.
The U.S. government's observation of AI-assisted attacks, the reports of damage to water facilities, and Forescout's experiment on real hardware are not consecutive pieces of evidence from a single incident.
| Source and date | Target and what was confirmed | What it does not show |
|---|---|---|
| Joint U.S. government warning, August 2026 | AI-assisted reconnaissance and attack capability development targeting Siemens S7 equipment | A demonstration of AI causing a large-scale blackout |
| CISA notice, July 30 | Settings on exposed water-sector PLCs were altered, leading to boil-water advisories and manual operation | AI involvement in this damage; the notice does not state it |
| Forescout experiment, September 1 | With researcher support, known attack code was ported to a different WAGO model | Attacks without experts, or intrusion into an actual power plant |
Sources: summary and technical explanation of the joint U.S. government warning, CISA's notice for the water sector, Forescout's experiment report. The classification is by each source's target and the stage reached; it is not a comparison of damage scale or performance.
According to the water-sector notice, attackers changed passwords and IP addresses, interfering with operators' ability to work. Actual damage to real facilities and confirmed AI involvement must be judged separately. Blurring that distinction risks overstating the AI threat while pushing back work on already exposed devices.
Building an attack does not mean running it safely
In an experiment published on September 1 by Forescout's research division, Vedere Labs, attack code exploiting a known vulnerability in WAGO PLCs was ported to a different model, the 750-831. The target firmware was V01.04.16. The researchers used Claude, but they had to help with analysis and keep correcting wrong directions.
The final remote code execution development stage alone cost $535.74 in API usage and took 8 hours 32 minutes of session time. That was part of work spanning several days, and does not represent the total time or the cost including labor for the whole experiment. In an attempt to add further remote control functionality, the device became permanently unusable. This is an experiment report published by the company itself, not a controlled trial proving that the approach is faster or cheaper than human-only work.
The result also matters for those using AI for defense. If a model misunderstands a device's state and makes a change that should never be run, equipment can fail even when the request is legitimate. The ability to generate attack code cannot simply be read as operational safety.
At the same time, it is risky to treat today's heavy effort as a permanent barrier. If the required expert intervention shrinks, attempts against similar models could multiply. The question raised by this experiment is not only "can anyone attack quickly?" but also whether vulnerabilities once rated low because they were hard to exploit can keep the same priority.
Equipment time lies between discovery and remediation
The U.S. National Institute of Standards and Technology (NIST) OT security guide SP 800-82 Rev.3 calls for testing and validation before patching. Section 5.2.5.2 of the guide, published in September 2023, recommends verifying in a test environment where possible, updating during scheduled maintenance windows, and preparing a recovery plan. Continuous operation and short maintenance windows limit how often updates can happen, and operating systems that are no longer supported may not be patchable at all.
Even if AI finds vulnerabilities in a short time, this work remains. Only after confirming that a patched device runs as planned, and that it can be rolled back if something goes wrong, can a decision to apply it to production be made. The speed at which attackers can increase attempts and the speed at which defenders can confirm equipment safety are not governed by the same conditions.
That is why treating fix-code generation alone as the achievement overlooks the work that remains on site. As the pile of fixes awaiting validation grows, decisions about which to test first and which equipment can be taken offline become heavier. To take advantage of AI's processing speed, staff and test environments are needed for the steps after discovery too.
There is also room to reduce exposure on equipment that cannot be updated right away. In its water-sector notice, CISA recommended eliminating direct internet exposure of PLCs and routing necessary remote connections through gateways such as VPNs. It also called for backups of known-good configurations. Cellular modems installed by maintenance contractors and possibly missing from asset registers deserve particular scrutiny.
A facility that looks closed on paper can have its defensive assumptions undermined if the actual communication paths differ. Whether or not AI products are deployed, the work of understanding which paths can be used to operate the equipment cannot be skipped.
What $1 billion in support can and cannot close
On September 3, OpenAI announced Daybreak for Frontline Defenders. The $1 billion covers access subsidies for defensive AI as well as training, technical support, and partnerships. Starting in the United States, the initiative set a goal for the access subsidies to be used over the next six months. It does not mean that cash for equipment upgrades has already been distributed.
In a pilot with MS-ISAC, the information-sharing organization supporting the U.S. public sector, the plan is to help public-sector and water-sector staff verify findings, prioritize them, and carry out remediation. The effort to assist with actual work rather than merely hand over a model fits the constraints of the field.
But more usage quota does not increase the time during which equipment can be taken offline. To evaluate the scale of the support, it is necessary to check not only the amount invested but also whether dangerous connections were eliminated and whether fixes were applied safely. API usage volume and infrastructure safety are different measures of success.
There is also a difference in roles between supporting companies and equipment operators. AI companies can help with analysis and drafting fixes, but when those changes are applied to real equipment depends on the operating conditions of the facility. Technical support that bridges the two has value, but concluding that access to models alone solves the problem would drop that point of contact.
Can equipment keep running if the AI is turned off?
In a contribution to the World Economic Forum on September 11, Robert M. Lee, CEO of industrial security firm Dragos, pointed out that AI is moving from an advisory role into the control loops of physical equipment. A control loop is the chain of measuring a state and operating machinery in response to the result.
Lee asks whether operations can continue when AI or related data becomes unavailable, and whether causes can be investigated when something goes wrong. These are his views and a hypothetical scenario, not a report of damage from an AI service outage. Even so, they offer material for choosing defensive AI.
For example, reading settings and proposing fixes has a different failure impact from writing to a device and changing its behavior. There is no need to extend speed gains from the former into unconditional write authority for the latter. How far to automate and at which operations a human should confirm should be decided by the impact on equipment and whether the change can be undone.
Returning every operation to manual work would not solve the problem either. What is needed is a design that defines what can be observed and which operations are permitted, so that the decision to stop the AI and the continued operation of equipment can coexist. Only when the ability to find problems quickly is accompanied by preparation for testing, recovery, and fallback operation can defensive AI help keep power and water supplies stable.