Hack all the things.
That was my brain for a few weeks.
Not in the hoodie-in-a-dark-room sense. More like: what if I aimed a disciplined AI harness at every codebase, every stale corner, every boring integration point, and every “surely someone has looked at this before” assumption I could find?
There was, inevitably, a soundtrack: Dual Core’s “All the Things”.
So I built a loop around that impulse.
The harness was mostly a contract file and a rhythm: It started as a simple AGENTS.md, but quickly evolved into a full AI harness, persistent state in Git, one action per iteration, fresh agents with no memory, explicit coverage, adversarial refutation, severity ceilings, and ship gates. Less “ask the model if this looks vulnerable” and more “turn vulnerability research into a production line with a lot of skepticism baked in.”
Each loop picked one target, one class, one hypothesis. Run the boring scanners first. Read the source. Promote only the candidates that survive a second look. Then make another agent try to kill the finding before I let myself believe it.
It was not magic. It was better than magic: it was repeatable.
The Fun Came Back Link to heading
The strange part was how it felt.
I spent nights with Claude and Codex, thrifting through source code like old records in a dusty shop. Rails configs. Kubernetes control planes. Java middleware. Flutter apps. OpenStack APIs. C parsers. Some nights were nothing but dead ends. Other nights a thread would tighten, a harmless-looking default would turn into an attack path, and suddenly it was 2:30 in the morning and I could not be dragged away from the computer.
It felt like being 15 again, discovering my first XSS.
That feeling is hard to explain if you have not had it. It is not just “finding a bug.” It is the moment the system stops being a product and becomes a puzzle. You see two assumptions that were never meant to meet. You pull on the gap between them. Something moves.
AI did not remove the skill from vulnerability research. It removed a lot of the drudgery around the skill.
It could build the harness. It could grep the repo. It could summarize the route table. It could compare the patch against the previous release. It could draft the report. It could run the boring “is this actually reachable?” checks ten different ways. It could keep going after I would normally have become tired of my own curiosity.
What remained for me were the fun parts: choosing the angle, noticing the weirdness, deciding whether the evidence was strong enough, and refusing to file garbage.
What Fell Out Link to heading
The reach surprised me.
OpenProject became my first target and proof point. One line of research led to a public advisory for a hardcoded default Rails secret combined with unsafe cookie serialization. Another pass found a cache deserialization path that reached full application compromise in a vanilla Docker harness. That was when the experiment stopped feeling small.
The fuzzing lane taught the opposite lesson. Native parsers produced plenty of crashes and promising false starts, but most died when the harness reproduced them, minimized them, and checked attacker reach. That is exactly what a serious process should do.
Across a major European airline and a large hosting provider, the same harness moved from web and mobile APIs into managed cloud infrastructure, producing concrete findings up to critical class while also killing claims that did not survive verification.
That last part matters. The harness did not just find bugs. It also found where the system held.
The most security-sensitive target was Swiss Post’s e-voting system. During its 2026 public intrusion test, I found a high-severity availability vulnerability that could exhaust voting-server memory and poison a cache after restart, blocking legitimate voting on the affected instance. Swiss Post fixed it in release 1.6.1 and published my finding as #YWH-PGM2323-1597.
The Important Shift Link to heading
The old bottleneck in vulnerability research was attention.
Not intelligence. Not tools. Attention.
Someone had to spend the evening reading the unglamorous code path. Someone had to compare two releases. Someone had to inspect the deployment chart, the default config, the generated client, the old API namespace nobody opens anymore. Someone had to turn “this feels weird” into “here is the exact boundary, here is the proof, here is the impact, here is what would falsify it.”
AI makes that attention cheaper.
Not free. Not automatically correct. Cheaper.
That changes the economics of security review. A human researcher can now keep several investigation threads alive without drowning in mechanical work. A company can run deeper adversarial passes on code that would never make it into a manual audit. Open-source projects can have their old defaults, examples, and deployment recipes read with the same suspicion as their shiny new features.
But there is a trap here too: if you remove the drudgery, you can also remove the brakes.
It becomes very easy to generate ten plausible findings and file five mediocre ones. That is not research. That is spam with stack traces.
The harness only became useful when it became adversarial toward itself. Every candidate needed a refuter. Every non-critical close needed a severity ceiling check. Every report needed to survive the question: what would make this not a bug?
That is where the human still matters most.
What This Means Link to heading
There is a bigger follow-up here, and I will probably write it separately.
Because if one person with a custom AI harness can spend a few nights and produce this much signal across open source, airlines, cloud providers, and native libraries, then businesses need to update their threat model.
Not because “AI hackers” are magically better.
Because the cost curve changed.
The boring corners are no longer protected by being boring. The old API nobody remembers, the default secret in a container image, the half-fixed SSRF guard, the one peripheral service that skipped the gateway authorization check, the Kubernetes feature that seemed safe because it needed three steps to abuse: those are exactly the places an AI-assisted researcher can now afford to inspect.
The defensive answer is not panic. It is also not banning AI-generated code or pretending manual annual audits are enough.
It is to build the same kind of loop on the inside: continuous, skeptical, source-aware, exploit-aware, and honest about uncertainty. Let agents do the grind. Make humans own the judgment.
For me, the lesson was simpler.
AI made vulnerability research feel playful again. It turned the work from “read 20,000 lines and try not to go numb” into “follow the thread and see where it goes.”
That is dangerous in the best possible way.
I sat down thinking I would run a few experiments.
Then the old meme took over.
Hack all the things.