The AI Agent Missed 457 Times Because It Could Not Tell Which Targets Would Work. Your PLC Answers That Question On Request.

Two things were published this week. Separately they are interesting. Together they describe a problem that does not exist yet and probably will.

One. Unit 42 reconstructed a campaign in which a Chinese-speaking actor wired DeepSeek's Hermes agent to a Telegram channel and the FOFA asset search engine, gave it one initial task, and let it run. It attacked more than 460 targets and confirmed three. The Langflow and n8n attempts failed because the exposed systems did not meet the exploits' configuration requirements.

Two. CISA warned that attackers reached internet-exposed PLCs at more than thirty Minnesota water utilities. Thousands of industrial controllers are reachable on the public internet — roughly 4,100 Rockwell, 4,100 Siemens and 2,000-plus Schneider by the Censys figures cited alongside the alert.

The link between them is not the water sector. It is the number 457.

The agent's problem was not capability. It was choosing.

Break the loop into stages and the shape is obvious.

Discovery is solved — an asset search engine returns every host running a product, instantly, for free.

Exploitation is solved — public exploit code, fetched and delivered in minutes rather than hours. That is the part everyone wrote about.

Triage is not solved. Of the 460 hosts the agent found, it had no way to know which ones ran a version and configuration its exploits would actually land against. So it tried them all. It was wrong 457 times.

That is not an AI failure. It is the oldest reason exploits fail — real deployments differ from the lab — and it turns out to constrain a tireless machine exactly as it constrains a person. Autonomy solved the labour problem and did nothing about the precision problem.

Which means the cost of the next capability jump is not better models. It is a source of pre-flight ground truth about targets.

Industrial controllers publish exactly that

Here is a real identity response from a US Allen-Bradley controller, unauthenticated, returned on request:

Product name `1756-L61/B LOGIX5561`. Firmware revision major `20`, minor `11`. Plus vendor, device type, serial number, and in many cases the controller's internal LAN address.

Exact model. Exact firmware.

That is stage two. That is precisely the datum that answers will this exploit fire against this host before a single packet of the exploit is sent. And it is already indexed by the same asset search engines the agent queried in stage one — FOFA has it, Shodan has it, Censys has it.

An agent that filters on disclosed firmware does not attack 460 hosts and miss 457. It attacks the eleven that match, and its conversion rate stops being embarrassing.

What I am not claiming

This has not happened. The observed campaign used seven IT-side vulnerabilities — Langflow, n8n, Citrix NetScaler, Apache Tomcat, Marimo Notebook, PAN-OS, Windows IKE — and did not touch industrial protocols or water utilities. There is no evidence that operator used ICS identity data for triage, and no evidence any autonomous agent has been pointed at a PLC.

We are describing how two documented trends compose, not reporting an attack. If that distinction gets lost, this piece becomes the thing we spend our time correcting other people for.

But the composition is not speculative in any interesting way. Both halves exist, both are public, and the connective tissue — an asset search engine that indexes firmware strings — is a commercial product with a free tier.

Why this changes the priority of a boring recommendation

"Your controller discloses its model and firmware" has always been a footnote. It reads like a privacy nicety. Against a human attacker with finite afternoons it very nearly is one: a person picks a handful of targets and researches them properly anyway.

Against a loop that costs pennies per attempt and lacks only a way to choose, it is the whole ballgame.

CISA's current mitigations for the water attacks are all about reachability — remove it from the internet, put a VPN in front, allow-list source addresses, change default passwords. Every one is correct and every one should be done first. None of them addresses what the device volunteers once something does reach it.

So add one check to the list:

Ask your own controller to identify itself, from outside your perimeter. Modbus on 502, EtherNet/IP on 44818, S7comm on 102. Read what comes back. If it returns a firmware revision, a project name, an engineering workstation name or a filesystem path, that is pre-attack research you are publishing on request.

Where the product allows it, suppress or genericise those fields. Where it does not — and for many controllers it does not — that is an argument for the reachability controls, not against them. You cannot stop a Logix controller describing itself. You can stop strangers asking.

The honest summary

The autonomous attacker that exists today is not very good. A 0.65% hit rate against 460 targets is three compromised organisations and a lot of wasted packets.

The reason it is not very good is a solvable problem, and industrial control systems are the population where the solution is lying in the open — because a PLC's job is to answer questions about itself, and nobody ever expected the thing asking to be a machine with unlimited patience.

Confidence capped at 95%. Campaign details, target counts and failure reasons are from Unit 42's published research. Exposure figures are from CISA's alert and cited Censys data. The identity response quoted is from passive third-party scan data on a real US host, read 31 July — we sent no traffic to it. The composition argument is ours and is explicitly forward-looking: no observed campaign has combined these, and we do not claim one has.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com