Skip to main content

To the Frontier and Back Again

· 7 min read
clearseclabs
Cyber Security Research & Training

In September I gave a talk at [un]prompted.au in Sydney called To the Frontier and Back Again. The question behind it was simple. What does vulnerability research look like at the frontier right now, and how much of that can I bring back to models I can run myself?

The frontier half is two Windows system-service 0-days, found with Claude Code and Opus 4.8. The first confirmed root cause landed 1 hour, 16 minutes, and 5 seconds after my first request. The back-again half replays the same hunt on open-weight models: same target, same context, same tools.

Thanks to the [un]prompted.au organizers for a really well-run conference. A lot of the program circled the same thing I was there to talk about: agents, local models, and the feedback loops that make them useful.

John McIntosh presenting To the Frontier and Back Again at [un]prompted.au in Sydney
To the Frontier and Back Again, at [un]prompted.au.

Fast, Complex, and Not Autonomous​

The two bugs are an arbitrary read and a write-what-where reached through a use-after-free. Neither is a bug you stumble into. One gets you past ASLR, the other is the kind of primitive that turns a crash into code execution.

I can't tell you what they are. Coordinated disclosure is still open on one, and naming the component points straight at the unfixed bug.

The setup was Claude Code and a Windows research environment. No custom harness, no MCP server. The speed is real, but it wasn't autonomous. The model needed direction, correction, and help with the tools, and that human work is part of the result. How the hunt actually ran, step by step, is the core of the talk, and it's the loop I teach in Windows Agentic VR.

Validation Is the New Work​

If there's one idea I'd want you to take from the talk, it's this one:

AI finds the leads. We build the test that could prove it wrong. This is the new work.

Why is AI good at coding? The compiler tells it when it's wrong. Vulnerability research doesn't come with a compiler, so you have to build one: a rig that lets the agent test its claims against the real target and feeds the result back into the next pass. It's easy for AI to find new potential leads. The work now is validation: figuring out which ones are real.

Getting a model to validate takes some new habits. Sometimes you have to provoke it. When it tells you the code looks hardened, tell it there's a bug there and to take a second look. A second look often means going back to the disassembly, because the decompiler doesn't always get it right. Sometimes you make it defend a verdict against another agent. And sometimes you refuse its shortcut. The easiest way to make a trigger work is to change a setting on the machine, and then you've proved nothing about the real target.

I contributed judgement. The knowledge to identify the bugs was in the model. The judgement to know where to pivot, and to validate whether a finding was legitimate, was mine.

The audience and stage at [un]prompted.au during To the Frontier and Back Again
The audience at [un]prompted.au.

And Back Again​

Then I replayed the hunt on open-weight models: same binary, same files, same tools. Here's the first pass at rediscovering the read bug, unaided, one draw per model:

Chart titled Unaided, on the real hunt. First draw per model, 1 of 7 found. GLM 5.2 found the bug. GLM 5.3, Qwen 3.6 27B, and Kimi K3 were partial. GLM 5.3 Flash, DeepSeek V4 Flash, and Gemma 4 31B missed.
Rediscovering the read bug with open-weight models, no operator help.

Only one of the seven found it without any hints, and three more got partway there. The other half of the talk is what happened next: how the rest closed the gap, how much help they needed, and whether they could actually prove the bug on the rig.

"Is this model good at security research?" turns out to be four questions:

  • Discovery: can it notice the defect?
  • Judgement: can it tell a lead from a finding?
  • Validation: can it destroy its own claim?
  • Closure: can it produce what a vendor will accept?

You only get those answers by testing a model on a real target.

If you missed it in Sydney, join the newsletter and we'll let you know where it turns up next.


Learn the Loop From the Talk​

The Agentic VR courses teach the methodology from this talk. Not a tour of my harness, but the approach behind the results: scoping a hunt with N-day patch diffs, building a rig that gives the agent real feedback, driving reconnaissance into leads, validating every claim against the disassembly, the debugger, and the live target, and taking a finding through to a report a vendor will accept. We do it with local models and compare against the frontier under the same standard of evidence.

Blue glass building with intersecting grids of windows, the Windows Agentic VR course image
Photo: Étienne Beauregard-Riverin / Unsplash

Windows Agentic VR is the first of them. It runs as a CSL virtual course February 1–4, 2027 (live instruction 09:00–13:00 US Eastern, with the other half of each day for exercises), and as a two-day edition at Black Hat Asia on March 2–3. You'll work real Windows CVEs, build the loop that checks your work, and write a real MSRC report. Read the syllabus or register for the February cohort, where early registration savings run through December 15.

I'm also bringing this work into the closing section of Agentic RE, where the tools and models from earlier in the week come together into a research loop you can evaluate and improve. An Apple Agentic VR course is next on my list. More on that as it takes shape.

Want this for your team? Let's talk about private training.

You won't learn where these models are by watching from the sidelines. Pick a target, build the loop, and see what happens.