Washington said it out loud

On 19 August the NSA, CISA, FBI, Department of Energy and Environmental Protection Agency jointly published AA26-231A, “Defending Against an Active Threat to Siemens S7 Series PLCs.” The language is unusually flat for a five-agency document: this is not a theoretical risk — it is an active threat.

The mechanics are worth stating precisely, because the precision is the story. Threat actors are combining open-source industrial automation libraries — snap7.dll and python-snap7 — with AI coding assistants to build custom tools that impersonate legitimate OT monitoring software. Those tools give read and write access to PLC memory, configuration data and ladder logic over the S7comm protocol. Targets are located through internet-wide scanning services, Censys and ZoomEye named directly.

Sectors named: Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, Commercial Facilities. The advisory adds that S7 Series controllers are deployed in the Defense Industrial Base and could be targeted there as well. Targeted models span the S7-200 through S7-1500 lines, for most CPU variants.

The agencies did not attribute. Iranian operators are suspected in related reporting on water-sector intrusions across at least twelve states, including the late-July incident that disrupted more than thirty community water systems in Minnesota. The advisory itself stays silent on origin, and so does this brief.

Read the mitigations again

Every hardening step in AA26-231A is sound. Patch to current. Remove PLCs from direct internet reachability. Block TCP 102 at the perimeter. Restrict TIA Portal and STEP 7 engineering access to authorized workstations. Deploy ICS-aware intrusion detection. Watch for anomalous S7comm traffic, unauthorized write operations, off-hours engineering connections, and Python processes importing snap7.dll.

Sort those into categories and the shape becomes visible. Four are perimeter. One is patching. Three are detection. None of them evaluates whether a particular write to a particular controller was authorized at the moment it executed.

That is not a criticism of the authoring agencies. It is a description of what exists to recommend. There is no widely deployed control that sits in front of a PLC write and asks whether this instruction, from this origin, against this target, carrying this physical consequence, holds current authority. So the advisory recommends keeping the attacker away from the controller and watching for the write after it happens.

A PLC write is not an access-control event. It moves a valve. The consequence class is physical and, in the water and chemical sectors, potentially irreversible. Detection that fires after the write is a forensic record, not a control.

The paragraph your counsel should read

Buried in the mitigation guidance is a directive that changes the legal posture more than the technical one. The advisory instructs organizations that rely on systems integrators or third-party managed service providers to share the document with those parties and request implementation — because the asset owner may not realize that their systems are exposed and at risk.

Read that as a security recommendation and it is unremarkable. Read it as a notice event and it is not.

Before 19 August, an operator whose integrator held standing remote write access to production controllers could plausibly say the exposure was invisible to them. Five federal agencies have now published, in writing, that this is a known and recurring pattern, and told owners to go ask. The window in which not knowing is a defensible position is narrower this morning than it was on Tuesday.

This is the same structure as the vendor-concentration problem the Irregular disclosure surfaced earlier this month: a single third party holding effective authority across environments the principals do not fully see. Different sector, same failure. The difference is that this one now carries a government document with a date on it.

The layer nobody is governing

Also on 19 August, Stripe confirmed it has agreed to acquire OpenRouter. Terms undisclosed. What matters is not the price — it is that the routing layer just became infrastructure owned by a payments company.

OpenRouter routes requests across more than 400 models from more than 80 providers, scoring each request on task complexity, price, speed and reliability, then sending it to whichever model fits. Named customers include NVIDIA, Zoom and Lovable. Patrick Collison framed the logic plainly: tokens are the central currency for companies building with AI, and the value is in routing requests intelligently.

Now the part CISOs should sit with. A CNBC investigation published 7 July found that Chinese-origin models have carried at least 30% of the token volume US companies route through OpenRouter every week since 8 February, peaking at 46%. The trailing twelve-month average was 11%. In the first half of 2025 it was 4.5%.

With that caveat honored: model selection has become a price optimization executed automatically, per request, by a component most organizations do not inventory, cannot name, and have never included in a third-party risk review. The jurisdiction the reasoning ran in is now a runtime variable.

Every control passes and the outcome is still wrong

Set the two threads against each other. On Tuesday, Amazon’s Bedrock AgentCore Payments reached general availability and the Rain Agentic Payments Alliance launched with twenty-six founding members, Visa, Mastercard, Fiserv, Circle and Shift4 among them. Agents that hold payment authority are now a supported product category with rails behind them.

Now run a purchasing agent through a workflow and put a router underneath it.

Nothing breaks. Every control does exactly what it was built to do.

Then one business fact changes. The merchant. The jurisdiction. The underlying customer case the purchase was authorized against. The delegated objective itself.

This is the scoping problem from Issue 51 in a commercial register. The defender holds logs showing successful actions by legitimate identities. There is no anomaly signal, because nothing anomalous occurred at any layer that produces signal. The authentication was real. The authorization was real. The purpose stopped being real somewhere in between, and no component owns that question.

The PLC case and the payment case are the same failure at different consequence classes. One moves money. One moves a valve.

Three numbers your carrier is going to want

Cyber underwriting questionnaires have converged on a stable set of questions: who has access, is MFA enforced, how is privileged access managed, what is the backup posture. Every one of those is an identity or recovery question. They were written for a threat model in which the compromise is a credential.

None of them asks which model executed a consequential action, in which jurisdiction it ran, under what declared purpose it was admitted, or whether the target was verified before the effect landed.

That gap was arguable last week. After AA26-231A it is documented. Foreseeability of AI-assisted attack against physical-consequence systems is now a matter of federal public record with a date attached — and the same advisory tells asset owners to go verify their integrators. Underwriters read advisories. Brokers read them faster, because their clients call.

Three questions

1. If an integrator’s remote session wrote to a controller at 2 a.m. tomorrow, which system would refuse it — and if the answer is “our detection would catch it,” how long after the write?
2. Can anyone in the room name the model that executed your highest-consequence automated workflow last week, and the jurisdiction it ran in? If not, who would we ask?
3. Our renewal questionnaire has no field for any of this. When the carrier adds one, what do we write?