I already wrote about pointing AI agents at vulnerability research on a desktop workstation. Nine libraries, a few weeks, three findings, a lot of lessons about what agents can do and what they still invent. That campaign answered one question: does the loop work?
It works. So the next question is different. Can you point the same orchestration model at OT/ICS protocol stacks — the parsers that sit between a network and a physical process — and get anything worth disclosing?
Short answer: yes. And the only interesting part is how.
What I’m actually building
I’m not running “a fuzzer.” Anybody can launch AFL++. The work is the system around it: agents that pick surfaces, write and smoke-test harnesses, watch coverage plateaus, rotate campaigns, triage crashes, de-dupe, and shove only the interesting stuff in front of a human. I sit at the end of that pipe and decide what’s real, what’s a harness artifact, and what gets disclosed.
Fuzzing is maybe 20% of the effort. The other 80% used to be me. Now most of that 80% is agents, and I’m the gate. That’s the whole thesis. If you’ve read the earlier note on agentic vuln research, this is that system applied to a nastier domain.
OT libraries are a different animal than libtiff. Protocols like PROFINET, EtherNet/IP, EtherCAT, IEC 61850, Modbus — these run on controllers, gateways, and SCADA-adjacent kit. A bad parser here isn’t a crashed photo viewer. Different risk universe. Same orchestration problem.
Receipts, not headlines
Lab only. Open-source targets. Authorized. No crash inputs, no stacks, no per-library finding attribution on the public dashboard. Maintainers first. You’ve heard that speech.
As of October 9, 2026 (CT), roughly nine and a half days into the OT campaign:
- ~142 billion executions
- ~1,031 fuzzer-hours
- 18 libraries
- 970 raw crashes (mostly duplicates — don’t get excited)
- 16 candidates reproduced in isolated reruns
- 4 live service-path findings — the ones that reproduce against a normal network-facing service, not just a harness
Four live findings from a short run on two boxes. That’s the number I care about. The 970 is noise until something reproduces and survives triage.
Two hosts on purpose. One ARM Mac Mini, one x86 Linux box with 24 cores. Crashes don’t always transfer across architectures — endianness, alignment, the usual. If you only fuzz one arch you’re half-testing. Right now the Mini is on p-net (PROFINET), the Linux box is on libiec61850. Different speeds, different surfaces, same orchestrator deciding what to keep running and what to retire.
Crash density clusters. A handful of libraries produce almost everything; most of the rest are quiet after billions of execs. Quiet isn’t failure. Quiet means either the code is solid or the harness isn’t hitting the interesting paths yet. Agents can tell those apart better than I can when I’m staring at a coverage graph at 2am. Sometimes. Sometimes they still need a shove.
What still breaks
Harness quality still varies. Coverage on some targets is pathetic because the surface isn’t built yet — open62541 at ~2% after billions of execs is a harness problem, not a “this library is bulletproof” claim. Stability dips (looking at you, CANopenNode) mean nondeterminism eating trust in the coverage numbers. Triage still invents confidence it hasn’t earned. Exploitability and disclosure still need a human. All of that is known failure mode, not a surprise.
Smart targeting beat brute force on the desktop campaign. Same bet here. Quality of harness and quality of orchestration beat throwing GPUs at a bad pipeline. The interesting next step is growing the loop — denser surfaces, more of the OT stack in parallel, more time on the last-mile work that turns crash piles into disclosures — without pretending the agents don’t still need a human at the gate.
So
I don’t need another chart of execs. I need the orchestration that produced four live service-path findings in under two weeks on two boxes to keep running, keep getting sharper, and keep disclosing to maintainers first.
Live counters are on the dashboard. The numbers above are a snapshot from October 9, 2026 (CT). Findings still go to maintainers first.
The fleet’s running. The interesting part is the orchestration.
Drew Stelly is a security researcher working on AI security, vulnerability research, and digital forensics.
Responsible disclosure: Findings from this campaign are disclosed to maintainers first. The public dashboard publishes totals and coverage, not crash inputs, stack traces, or per-library finding attribution.