AI can accelerate infrastructure attacks. It did not create the weakness

There are three different stories hiding inside the debate about AI and critical infrastructure. One concerns systems that attackers have demonstrably compromised. Another concerns reported use of AI to make industrial attacks easier. The third imagines autonomous technology causing catastrophe without meaningful human direction.

Collapsing those stories into one dramatic narrative makes for poor policy. Confirmed incidents, attributed claims and hypothetical futures require different evidence. More importantly, they point towards different interventions.

The immediate lesson from recent US operational technology incidents is not that AI has suddenly made essential services fragile. It is that AI could make long-tolerated weaknesses cheaper and faster to exploit. The sensible response is therefore to treat AI as a stress test for infrastructure governance, not as an excuse to overlook exposed equipment, constrained operators and weak recovery planning.

Keep the incidents separate

On 30 July 2026, the FBI and US Environmental Protection Agency said water and wastewater utilities in at least seven states had reported attacks against directly internet-facing Rockwell Automation Allen-Bradley MicroLogix 1100 and 1400 programmable logic controllers. Some of the activity degraded water operations.

According to the agencies, attackers changed PLC network addresses and passwords, causing operators to lose monitoring and control. Reported consequences included loss of water pressure and flooding. The severity depended partly on what each controller managed and whether the operator could switch to manual operation.

These were real compromises with operational effects. They were not, on the available evidence, confirmed examples of AI-assisted attacks. Vox explicitly noted that the recent water incidents it discussed had not been definitively linked to AI. Nor does the official notice establish a new vulnerability in the Rockwell products or identify the attackers.

A separate development involved Siemens S7 controllers. Siemens ProductCERT said a US government advisory issued on 19 August concerned a potential active threat against the S7 family. CyberScoop reported that the multi-agency advisory described threat actors using AI-generated exploitation scripts, reducing the expertise and time required to develop tooling for industrial controls.

That claim matters, but so do its limits. The underlying advisory has not been directly reviewed, so the AI-script claim remains attributed to the agencies through CyberScoop. Siemens said, as reported by CyberScoop, that the described techniques involved possible misconfiguration rather than a new S7 vulnerability. The confirmed Rockwell incidents and the reported Siemens activity concern different products, and no relationship between the campaigns has been established.

This evidence ledger is not pedantry. If every operational technology incident becomes an AI incident, policymakers may end up buying answers to the most fashionable part of the story while neglecting the conditions that made the attack possible.

AI changes the economics

The strongest interpretation supported by the available evidence is that AI may alter the economics of an attack more than its underlying failure mode. If generated scripts become reliable enough to use with limited expert correction, actors who previously lacked specialist industrial-control knowledge could attempt more opportunistic attacks. That remains a conditional risk: the available reporting does not quantify any increase in attack volume, success or harm, and it does not show that generated tooling works reliably across different industrial environments.

Yet even a limited reduction in time or expertise would matter when equipment is directly exposed. AI does not need to become an autonomous mastermind to make a dangerous contribution. It only needs to help more people work faster against systems that were already reachable.

That is precisely why the infrastructure layer deserves more attention than the novelty of the tool. In the July water incidents, the FBI and EPA described attackers remotely changing settings on public-facing controllers. Their recommendations included removing PLCs from direct internet exposure, brokering necessary remote access through secured gateways and firewalls, restricting communications, strengthening credentials, reviewing logs and checking project files against known-good versions.

Those recommendations are strikingly conventional. That does not make them obsolete. It shows that the core problem is less cinematic than the rhetoric around AI: essential equipment can remain too easy to reach, while the capacity to detect interference and restore safe operation can vary between operators.

The answer is not indiscriminate disconnection. Remote connectivity may support legitimate maintenance and operations. The better principle is mediated access: systems should communicate only through controlled paths, with strong authentication, restricted connections and useful logging. Connectivity should be a managed operational decision, not the accidental consequence of leaving a controller publicly reachable.

Cybersecurity is also a funding question

The EPA says more than 97 per cent of the 156,000 public water systems in the United States are small systems serving 10,000 or fewer people. It also says small systems can face distinct financial and operational challenges.

That does not quantify a cybersecurity spending gap, and it should not be presented as proof that every small utility is insecure. It does, however, expose the weakness in treating national resilience as a series of purely local purchasing decisions. Telling an operator to deploy secure gateways, maintain logs, replace end-of-life assets, preserve known-good configurations and rehearse recovery is easy. Finding the money and expertise to do all of those things consistently is harder.

Critical-infrastructure cybersecurity is therefore partly a public-finance problem. New mandates without funding and technical assistance could leave small operators carrying obligations they cannot implement well. Conversely, public funding aimed only at fashionable AI detection products could miss more basic exposure and recovery work.

If resources are limited, governments should help operators reduce direct exposure, mediate remote access, manage equipment through its full lifecycle and practise recovery. The official guidance does not establish which combination is most cost-effective in every environment. But it does support a broader policy judgement: security requirements and the capacity to meet them must be designed together.

Manual operation is a modern control

The July incidents also demonstrate why resilience cannot stop at prevention. The operational consequences varied partly according to whether utilities could move to manual operation. The FBI and EPA consequently recommended retaining and regularly testing manual capability, fail-safe mechanisms, backups, standby systems and recovery plans.

Manual fallback is sometimes treated as nostalgia for an analogue past. It is better understood as a contemporary resilience control. When digital monitoring or remote control becomes unavailable, an operator needs a safe way to continue, contain the disruption or restore service. A manual process that nobody has rehearsed is not much of a fallback, just as a backup that has never been tested is not yet a recovery plan.

This principle also changes how success should be measured. Preventing every attempted intrusion is unrealistic as a policy objective. Essential systems should instead be difficult to reach, limited in what an intruder can change, able to fail safely and recoverable when networked controls are unavailable.

Do not replace one false certainty with another

Focusing on human-directed, AI-assisted attacks does not prove that longer-term autonomous AI risks are imaginary. The available evidence provides no comparative probability or expected-harm estimates for those categories, so declaring one the only legitimate concern would simply substitute one unsupported certainty for another.

AI-specific monitoring and safeguards may also deserve investment if generated tooling becomes faster, more adaptable and more reliable. Traditional controls are not a reason to ignore changes in attacker capability. They are the foundation that limits the consequences while institutions assess those changes with better evidence.

The mistake is to turn the debate into a contest for the title of the real AI catastrophe. Near-term misuse and hypothetical autonomous harm have different evidence, timescales and remedies. Governments and companies can address both without pretending that a reported AI-generated script proves an autonomous takeover, or that concern about future autonomy excuses present-day operational exposure.

Responsibility must also extend beyond individual utilities. Asset owners operate the systems, but public funders influence whether small operators can modernise them. Equipment vendors shape secure configuration and lifecycle support. Service providers can affect how remote access is deployed. If AI companies materially lower barriers to harmful activity, they too should face scrutiny over safeguards. This is an argument about shared responsibility, not a claim that the reviewed evidence establishes legal liability for any party.

AI could increase the number and pace of attempts against industrial systems. It did not invent directly exposed controllers, end-of-life equipment or the need to test recovery plans. The practical test is not whether an attack carries an AI label. It is whether an essential service can keep operating safely, or recover quickly, after someone gets through.

Manual fallback makes resilience a systems question, not merely a choice of security tool. Let that broader perspective shape your next step with The Hack Academy’s online cybersecurity training programme: self-paced learning, practical exercises alongside theory, and listed subjects including cybersecurity fundamentals and networking.