The Verifier Is the Vulnerability Research Breakthrough

The impressive part of Quarkslab’s new vulnerability research workflow is not that an AI agent helped find a path to remote code execution.

It is that the workflow was designed not to trust the agent.

In a technical report published by Quarkslab, Julien Lair describes a system that combined a deterministic code graph, static analysis, bounded slices of a large codebase, agent-generated hypotheses, dynamic validation, and human checkpoints. Applied to FreeRDP, the workflow produced two vulnerabilities that could be chained into client-side RCE.

The result is a useful correction to the usual story about AI security research. The model was not the breakthrough. The control loop around it was.

The output problem

Security research agents can produce a lot of plausible work. That is not the same thing as producing useful findings.

Quarkslab describes the central problem directly: a broad search produces more candidates than a researcher can inspect. The cost is not just compute. It is attention. A false positive that names real functions and believable attack paths can still consume hours before someone proves it wrong.

The workflow therefore separates recall from precision. Its deterministic core is intentionally broad. It indexes the target, follows data flow, and applies known vulnerability patterns. The agent layer then investigates the candidates, groups related evidence, and tries to move the survivors toward a proof of concept.

That is a very different architecture from asking a model to read a repository and return a vulnerability list.

Eight stages, with a boundary around each one

Quarkslab describes the pipeline as:

graph → recon → slicing → analysis → triage → poc → chain → exploit

Each stage has a narrower job.

Stage	Responsibility
graph	Index the codebase into a queryable representation.
recon	Map components, exposure, and likely attack surfaces.
slicing	Bound an investigation to a manageable code path.
analysis	Run taint analysis and target specific checks.
triage	Group evidence and classify real, unclear, or noisy candidates.
poc	Test whether a candidate can be reproduced dynamically.
chain	Check whether separate weak primitives form a stronger path.
exploit	Validate the final primitive or chain in an exploitation harness.

The model does not receive an unlimited repository and an unlimited mandate. It receives a bounded slice and a specific question.

That constraint is not a limitation of the system. It is what makes the system inspectable.

Why the deterministic core matters

Quarkslab’s run indexed 13,506 functions, 3,105 types, and 31,705 call edges in the FreeRDP tree. The workflow then created 304 investigation slices.

Those numbers matter less as a benchmark than as an architectural clue. No language model is expected to carry the entire graph in context and reason reliably over it. The graph and slicing layers turn a repository into a sequence of smaller, queryable investigations.

The deterministic layer is also reproducible. The agent layer is not. That asymmetry is acceptable when the system preserves the evidence that connects an output to the code path that produced it.

The important question is not whether the model gives the same answer twice. It is whether an investigator can see why a candidate survived, rerun the relevant checks, and reject it when the evidence does not hold.

The verifier is where a lead becomes a finding

In the FreeRDP example, the first two slices produced 130 findings. Triage reduced them to 36 clusters: 20 real and reachable, 3 latent, 3 mixed, and 10 false positives.

The numbers are reported by Quarkslab, not reproduced independently here. Their significance is the transition between the stages. Static analysis generated candidates. Clustering connected evidence. Dynamic testing decided which paths survived.

For one finding, the system connected an attacker controlled length with a later write operation. One path turned out to be safe because a protocol bound prevented the overflow. A second path through server redirection did not have that restriction. Quarkslab then reproduced the behavior with a malicious server and an AddressSanitizer instrumented client before treating it as a vulnerability.

That sequence is the security boundary.

A model can propose that two facts are related. A verifier must establish whether the relationship exists in the actual program.

What the common intuition gets wrong

The common intuition is that better models will eventually remove the need for this scaffolding.

The evidence points in the other direction. Better models make hypothesis generation cheaper. They do not make nondeterministic output reproducible, and they do not turn a plausible explanation into an observed memory error.

The workflow’s researcher checkpoints are not an admission that the agent failed. They are an explicit division of responsibility. The system searches and compresses the search space. The researcher decides which ambiguity deserves more work and whether the final claim is justified.

That is also why the workflow did not simply rank the most promising code first. The two findings that formed the RCE chain came from slices ranked 166th and 109th out of 304. Ranking provided a map. It did not provide a verdict.

The operator consequence

If you are building an agent for security work, start with the verifier rather than the prompt.

Give the system a deterministic representation of the target. Keep investigations bounded. Preserve the source locations and intermediate evidence behind every candidate. Add a dynamic check that can reject a static story. Put sensitive actions such as exploit execution behind an isolated harness and an approval boundary.

A practical design should make these questions easy to answer:

• Which exact code and commit produced this finding?
• Which deterministic check generated the candidate?
• What did the agent infer rather than observe?
• Which test confirmed or rejected the inference?
• What privilege and network access did the validation harness have?
• Who approved the transition from analysis to exploitation?

If the system cannot answer those questions, adding another model is unlikely to fix the problem.

The uncomfortable truth is that an autonomous security agent is not made trustworthy by making it more autonomous. It becomes trustworthy when its autonomy is surrounded by evidence, isolation, and stopping points.

The model is only one stage in the loop

Quarkslab’s FreeRDP result is best read as a systems paper disguised as an agent demonstration. The model helped explore hypotheses, but the useful output came from the surrounding machinery: graph construction, slicing, static analysis, clustering, dynamic validation, and researcher control.

The future of agentic vulnerability research will not be decided by who has the most confident model output. It will be decided by who can build the shortest path from suspicion to a reproducible fact, without turning the researcher into a human garbage collector for plausible noise.

The verifier is not the last step after the agent. It is the architecture that makes the agent useful.

Sources

• From AI Agents to RCE: Building a Vulnerability Research Workflow, Julien Lair, Quarkslab, September 29, 2026.
• FreeRDP routing token heap overflow advisory.
• FreeRDP USB redirection heap disclosure advisory.