Build the Tooling, Don’t Be the Tooling

[ Abstract ]

Applied AI, self-improving loops, and a security tool that gets better every time it fails.

I keep telling people to build the tooling instead of being the tooling — use AI to build systems that do the work deterministically, not to hand-crank the work through a model every time. I went and did exactly that on a deliberately unglamorous security problem: when you find a vulnerability, who do you actually tell?

The tool I built resolves any asset — a domain, an IP, a package, a container, a piece of firmware, whatever you can point at — to a real security-reporting channel, live from primary sources, never hardcoded. This talk isn't really about the tool. It's about how it improves itself. Every lookup that comes back wrong or empty is a coverage gap the system captures, clusters, and closes, behind a gate that lets a fix ship only if it adds zero false positives against a frozen corpus. The thing gets more accurate the more it fails. Antifragility as an actual engineering discipline, not a slide.

I'll show the build in brief — what AI genuinely accelerated, and where it confidently lied to me — then spend most of the fifteen minutes on the loop itself: how a tool that rewrites its own resolution logic stays trustworthy, and what breaks when it doesn't.

The icing: the reason a problem this old keeps getting worse is also AI. AI-generated vuln reports, AI-generated code, AI-widened attack surface, the slopdemic burying maintainers in plausible nonsense. Offense scales with compute; defence still scales with committees. Building AI that keeps defensive tooling ahead of an AI-driven problem is the whole game — this is one worked example of doing it honestly.