The Government Just Confirmed Attackers Are Using AI to Write Exploits Against Power Grids, Water Plants, and Factories

Five federal agencies confirm attackers use AI to write exploit scripts against Siemens PLCs running water, energy, and manufacturing plants.

The NSA, CISA, the FBI, the Department of Energy, and the EPA jointly confirmed on August 19, 2026 that threat actors are using artificial intelligence to write exploitation scripts against Siemens S7 series programmable logic controllers, the industrial computers that run water treatment plants, energy infrastructure, and manufacturing lines across the country. The advisory, tracked as AA26-231A, is among the first joint federal advisories to name AI directly as the capability behind an active campaign against physical industrial equipment rather than against a codebase or a software supply chain.

Sources: Defending Against an Active Threat to Siemens S7 Series PLCs (CISA Advisory AA26-231A)

The advisory does not describe a hypothetical. It describes an active campaign: threat actors pairing two open-source industrial automation libraries, snap7.dll and python-snap7, with AI-assisted scripting to build custom Python tools that read and write directly to PLC memory, configuration data, and ladder logic over S7comm, the Siemens control protocol, on TCP port 102. The agencies' own words for what AI adds to that campaign are direct: "using AI to generate exploitation scripts represents an evolution in threat actor capabilities, dramatically reducing the technical expertise and time required to develop working ICS exploitation scripts and malicious tools."

Sources: Defending Against an Active Threat to Siemens S7 Series PLCs (CISA Advisory AA26-231A), Siemens S7 PLC Threat: What You Need to Know (Tenable)

A PLC is the small industrial computer bolted next to a pump, a valve, a conveyor line, or a turbine, running the logic that decides when that piece of equipment turns on, shuts off, or holds a setpoint. It has nothing to do with a company's application codebase; it is closer to firmware for a single physical process. That is why S7comm, the protocol Siemens designed for engineering software to talk to these controllers, was never built with the internet's threat model in mind, and why an unauthenticated read or write against one of these devices reaches directly into a physical process instead of stopping at a database row.

This is disclosed directly because the argument below favors independent review over trusting either a human or an AI model to get code right on the first pass, and this site's own commercial interest sits in that category: we make TLM Forge, a spec-audit-then-review-then-test discipline for AI-assisted coding, though that interest does not change what five federal agencies said on August 19, 2026.

What AA26-231A Actually Documents

AA26-231A names seven sectors as targets: critical manufacturing, energy, water and wastewater, chemical, food and agriculture, commercial facilities, and potential exposure in the defense industrial base. The energy sector listed there is not a narrow category: CISA describes it as spanning the electricity infrastructure that generates, moves, and delivers power nationally, the plain-language reason a Siemens S7 PLC sitting inside that sector is fair to describe as grid-adjacent equipment, not a loose figure of speech. The advisory itself covers every S7 generation Siemens has shipped, from the S7-200 through the S7-1500, including the F-series safety controllers meant to shut a process down cleanly when something goes wrong. The pattern the agencies describe runs in two stages: reconnaissance first, using commercial internet-scanning services such as Censys and ZoomEye to find PLCs reachable from the open internet, then read operations to map a target's configuration before any write operation, the step that actually changes what a controller does, ever takes place.

Sources: Defending Against an Active Threat to Siemens S7 Series PLCs (CISA Advisory AA26-231A), Siemens S7 PLC Threat: What You Need to Know (Tenable), Energy Sector (CISA)

Once a controller is found, the campaign the advisory documents does not stop at reading configuration data. Reporting on the advisory describes AI-generated tools built to masquerade as legitimate operational technology monitoring software, giving an attacker cover to sit on a network without triggering the alarm a plainly named intrusion tool would. Getting in still relies on old habits, default or weak credentials on internet-reachable controllers, the same failure mode ICS security researchers have flagged for a decade, which is part of why the mitigations below read as basic hygiene rather than a novel defense against a novel threat.

Sources: NSA, CISA, FBI, DOE, and EPA Warn of Active AI-Assisted Attacks on Siemens S7 PLCs (Security Affairs)

The Vulnerability Is Old. The Method Is Not.

None of the underlying weaknesses here are new. S7comm's exposure to unauthenticated reads and writes has been documented in public research for ten to fifteen years. What changed, according to a Cloud Security Alliance analysis of the campaign, is the method: attackers now direct AI models to synthesize working Python clients around python-snap7 rather than hand-writing S7comm parsing logic themselves, a shift the analysis frames as moving activity from targeted operations by specialists toward broad, opportunistic, scanning-driven access closer to commodity internet exploitation than classic industrial espionage. The Cloud Security Alliance framing puts the point plainly: the campaign's most consequential finding is not which PLC family got targeted, since S7 exposure has been public knowledge for years, but that the method of building the tool changed under it.

Sources: AI-Generated Exploits Target Siemens S7 PLCs (Cloud Security Alliance)

Why This Reads Differently Than a Vulnerable-Code Story

Most coverage of AI and code security, including Prompt Injection in AI-Generated Code, assumes the risk lives inside your own repository: a model writes a flawed access check or an injectable query, and that flaw ships to your users. AA26-231A describes the opposite direction. The AI model is not writing the vulnerable production code; it is writing the attacker's exploit code, against a target that was never submitted for anyone's review, and no code review process a defending organization runs will ever see that script before it runs against their equipment. The same capability that helps a developer write a working Python client in an afternoon helps an attacker write one just as fast, against different code, for a different purpose.

Most software engineers reading an advisory like this have never touched a PLC and reasonably assume it does not concern them, since the AI-coding-security conversation they follow is about their own repository, their own dependencies, their own pull requests. AA26-231A is evidence that the assumption undercounts the risk. AI coding assistance is a general capability, not a feature scoped to whichever tool a defender happens to be using, and treating "AI makes writing working code faster" as good news only when it is your own team typing the prompt misses half of what the sentence means.

What Operators Are Told to Do About It

The advisory's mitigations are the standard operational technology hardening list, not a new AI-specific defense, because there is no reliable way to detect "AI wrote this exploit" at the network layer. The traffic looks the same regardless of who or what authored the script that generated it.

Sources: Defending Against an Active Threat to Siemens S7 Series PLCs (CISA Advisory AA26-231A), NSA, CISA, FBI, DOE, and EPA Warn of Active AI-Assisted Attacks on Siemens S7 PLCs (Security Affairs)

• Inventory every internet-facing PLC before doing anything else; a device nobody knows is exposed cannot be defended.
• Remove PLCs from direct internet reachability and segment operational technology networks from IT networks.
• Block TCP port 102 at the network perimeter wherever S7comm access is not operationally required.
• Enforce password protection on every controller and apply Siemens ProductCERT hardening guidance.
• Deploy S7comm-aware monitoring that flags unauthorized read and write operations, not just perimeter intrusion attempts.

Two Different AI Risks, Compared

Laid side by side, the two risks share a cause and split on almost everything else. Both come from the same underlying fact, that an AI model can now produce a working piece of software faster and with less specialist background than a person needed before. What differs is who holds the pen, where the defense has to sit, and whether anyone gets a chance to review the result before it does damage.

The Process Gap This Exposes

TLM Forge exists for the defender's half of this asymmetry, the half an engineering team actually controls: a spec audit before an AI-assisted integration is built, independent multi-agent review of the diff before it merges, phase-gated testing before it ships, and a convergence gate that blocks a release until critical findings hit zero. None of that reaches into an attacker's toolchain; nothing can. What it removes is the excuse that an AI-assisted integration touching a PLC, a SCADA gateway, or any other control-protocol endpoint went to production unreviewed because the code compiled and the demo worked. AA26-231A is a reminder that whoever is on the other end of that connection may already be reviewing their own tools less than you review yours, and getting faster at it. Phase-gated testing is the part of that discipline that maps most directly onto an OT-adjacent integration specifically: a test plan written and reviewed before the integration code exists, run against the actual protocol behavior it targets, catches the class of mistake that a fast, AI-written client and a fast, AI-written exploit script share, code that runs without ever confirming it does only what it was supposed to do.

The durability problem underneath an advisory like this, that operational knowledge about which controllers are exposed, which patches are pending, and which credentials were last rotated tends to live in one engineer's head or a chat thread nobody can find during an incident, is a team and asset-inventory problem outside what MemX is built for. MemX, from the same team behind TLM Forge, is a private, persistent memory layer for an individual's own photos, documents, voice notes, and messages, a narrower and personal kind of durability than an operator's asset inventory, though the underlying failure, information that exists somewhere and cannot be found when it matters, shows up in both settings.

AA26-231A will not be the last advisory to name AI directly as the capability behind an active campaign. What makes it worth reading past the headline is what it does not claim. It neither claims S7comm got newly vulnerable nor that Siemens shipped a new flaw: it says the same PLCs, with the same decade-old exposure, are now reachable by more people, faster, because building the tool to reach them stopped requiring specialist ICS knowledge. That is a statement about attacker capability, not about a product defect, and operators, along with the engineering teams that build the software those operators depend on, should expect to see that statement made again.