Dominic Jainy stands at the forefront of the modern shift in vulnerability research, bridging the gap between high-level artificial intelligence and the gritty, bit-level reality of software security. With a deep background in machine learning and blockchain architecture, Jainy has spent years observing how traditional security tools struggle to keep pace with the sheer volume of code being generated in our current development landscape. His expertise is particularly relevant now, as we see a pivot toward “agentic” security—systems that don’t just flag potential issues but possess the autonomy to investigate, verify, and prove their findings through concrete evidence. In this discussion, we explore the evolution of fuzzing technology and how new platforms are tackling the blind spots that even the most advanced large language models continue to miss.
The conversation covers the fundamental shift from manual harness creation to automated, AI-driven selection of security-critical functions. We delve into the technical limitations of LLM-based code audits, specifically why predictive reasoning often fails when faced with the complexities of compiled code and memory management. The dialogue also explores the mechanics of structure-aware mutation, the importance of reproducibility in developer workflows, and a detailed look at recent zero-day discoveries in mature open-source projects.
Traditional coverage-guided fuzzers often require manual harness creation and constant triage. How does an agentic approach specifically automate the selection of security-critical functions, and what steps are taken to ensure that an AI-generated harness successfully reaches its intended target without human intervention?
The most significant barrier to widespread fuzzing has always been the “harness tax,” the exhausting requirement for a specialist to manually write code that exposes a specific function to the fuzzer. In an agentic approach, we move the burden of judgment from the human to an AI agent that analyzes the codebase to identify untrusted-input paths—essentially finding the doors that an attacker might actually knock on. Instead of testing every single function, the system intelligently selects security-critical targets where parsers and processing logic interact with external data. Once a target is selected, the AI generates the harness, but it doesn’t just stop there and hope for the best; it enters a verification phase where it confirms the harness actually reaches the intended code path. By running this in a self-contained environment, the system can iterate on the harness until it achieves reachability, effectively eliminating the manual back-and-forth that used to take days or even weeks. This automation allows an evolutionary engine—like the one we’ve been refining since 2018—to finally scale across an entire codebase rather than being restricted to a few high-priority files. We have seen this result in a persistent mode where execution is about 51 times faster than traditional methods that spin up a new process for every single input.
LLM-based code audits often struggle with predicting the behavior of compiled code, such as integer widths or allocator logic. When identifying zero-day vulnerabilities in mature codebases, why is it necessary to observe millions of concrete executions rather than relying on the pattern-recognition capabilities of large language models?
While large language models are incredibly impressive at recognizing known bug patterns like an unchecked memcpy, they are fundamentally predictive and lack “ground truth” regarding how code actually behaves once it is compiled and running on specific hardware. To find a true zero-day in a mature codebase—code that has already been scrubbed by static analysis and human reviewers—you have to look for the things no one expects, which is where running 1 million to 10 million concrete inputs becomes essential. A fuzzer doesn’t guess; it observes real outcomes, such as a sanitizer reporting a heap read exactly one byte out of bounds, which is an objective reality rather than a statistical probability. If you tried to match this scale with an LLM, you would be looking at consuming roughly two billion tokens for a single target, and even then, the model might still hallucinate the behavior of complex struct layouts or specific build flags that it can’t see in the source. In our recent research, we saw this in action with a libxml2 harness that reached 13,600 code regions in a 5-million-execution run; that kind of granular coverage feedback provides a signal for deeper search that code review simply cannot replicate. The “unexpected” is the fuzzer’s playground, as we saw with the YAML hash overflow in the Crystal standard library, where the function was logically correct for trees, but the fuzzer found a self-referencing anchor cycle that triggered a SIGSEGV.
Structured inputs often fail early at the parsing stage when subjected to byte-level mutation. How does a structure-aware evolutionary search bypass these initial sanity checks to reach deeper, more vulnerable logic without requiring a per-target grammar?
The frustration with traditional byte-level mutation is that it’s like trying to write a poem by randomly hitting keys on a typewriter; you’ll almost never get past the first line of a “sanity check” because the formatting is broken. To solve this, we use a format-agnostic parsing layer that transforms a seed input into a typed tree of fields, allowing mutations to happen at the field level rather than just the byte level. By mutating the fields of a valid structured input, we ensure that the vast majority of test cases survive the initial framing and validation checks, allowing the testing budget to be spent on the complex logic hidden deep inside the application. Every “organism” in this evolutionary population carries a genome—a specific, ordered list of these mutations—and through successive epochs, the system keeps the changes that improve coverage and reverts the ones that don’t. This approach is incredibly powerful because it doesn’t require us to write a new grammar file for every target; instead, every new format we add to the parsing layer improves the testing capability for every target that uses it. We saw this bear fruit in the Fider project, where a 436 KB PNG was mutated to trigger a decompression bomb that expanded to 562 MB, a bug found in just 12 minutes despite the project being previously benchmarked by several AI pentesting vendors.
The ability to deliver a “byte-exact payload” in a pull request seems like a major shift for developer experience. Can you elaborate on why this reproducibility is so critical when dealing with high-priority issues like those found in TwelveMonkeys or RIOT OS?
Reproducibility is the bridge between a security “finding” and a developer “fix”; without it, a vulnerability report is often just an item for an engineer to argue about or ignore. When our system identifies a crash, it doesn’t just send a log; it delivers the file, the function, and the exact byte-level payload required to trigger the fault, often within a pull request. In the case of the TwelveMonkeys DDS reader, a tiny 38-byte file was enough to force a multi-gigabyte allocation, and having that exact file meant the maintainers could verify the CWE-789 vulnerability instantly in their own environment. For RIOT OS, we found an off-by-one error where a NUL byte landed one past the buffer, a classic CWE-193 that is notoriously difficult to catch in manual review because the bounds check actually runs after the write. By replaying every single finding in a fresh container before filing it, we ensure that the developers aren’t wasting time on “ghost” bugs or environment-specific flukes. This level of proof allowed us to publish ten findings across eight projects—including htop and universal-ctags—in just the first month of the tool’s availability, because the evidence was undeniable and actionable on day one.
Given that your research showed 45% of tested projects had High or Critical issues, even those in programs like Google’s OSS-Fuzz, what does this tell us about the current state of “mature” code and the efficacy of existing testing regimes?
The fact that 37% of the vulnerable projects we identified were already part of the OSS-Fuzz program is a sobering reminder that even the best existing testing regimes have gaps, usually caused by the difficulty of maintaining comprehensive harnesses over time. Mature code isn’t necessarily “safe” code; it’s just code where the obvious, pattern-based bugs have already been fixed, leaving behind a residue of subtle, structural defects that require a high-volume evolutionary search to uncover. We found an out-of-bounds read in the htop /proc/PID/stat parser and a null-pointer access in universal-ctags, both in codebases that are widely used and have been scrutinized for years. These aren’t just theoretical risks; they are outage-level defects and memory-safety issues that often sit on untrusted-input paths that DAST or static analysis simply cannot reach effectively. It highlights a critical need for security teams to move beyond just looking where bugs are expected to be and to start using agentic tools that explore the “everything else.” When a 35-byte GIF can trigger an 8 GB allocation attempt in a library like scrimage, it’s a clear signal that our current input validation and resource capping strategies are failing in ways that only a fuzzer can reliably expose.
What is your forecast for the future of Agentic Application Security?
I believe we are entering an era where the concept of a “security scan” will be replaced by a continuous, autonomous conversation between AI agents and the code itself. In the next few years, we will see security agents that don’t just find a bug and stop, but will automatically generate a fix, verify that the fix doesn’t break existing functionality, and then fuzz the fix itself to ensure no new edge cases were introduced. The traditional silos of SAST, DAST, and manual fuzzing will collapse into a single agentic workflow that lives entirely within the development lifecycle, operating without the need for a running application or complex cloud infrastructure. As AI continues to write a larger share of our production code, the only way to stay ahead of the vulnerabilities it creates—many of which will be unique and lack known patterns—is to have AI-driven security that can observe and prove behavior at a scale no human team could ever match. We are moving toward a “zero-trust” development model where every line of code is treated as a potential vulnerability until an agentic fuzzer has run millions of executions against it and failed to break it.