GitHub open-sources an AI agent that writes and runs fuzz tests

GitHub's Security Lab has released an AI agent pipeline that fuzzes C and C++ projects from start to finish: it finds entry points, writes the test harnesses, runs the fuzzer, reads the coverage and triages the crashes. The code is open source under the MIT licence.

The post, by Antonio Morales and published on Thursday, September 24, comes with an unusual instruction for a developer tool. Because the pipeline runs "arbitrary build commands chosen by the LLM directly on the host, with no container in between", GitHub asks people to run it only inside a disposable environment, such as a Codespace or a throwaway virtual machine, without elevated privileges.

Why fuzzing still needs a person

Fuzzing means firing huge numbers of malformed inputs at a program to see what breaks. It sounds automatic, and the post opens by saying it is not: continuous fuzzing "is not a magic solution that solves all your problems". Even projects enrolled for years in OSS-Fuzz, Google's free fuzzing service for open-source code, can still hide critical bugs, it says, because someone has to watch coverage, write harnesses for code nobody reaches and triage what crashes. That human work is what the agent takes on.

How the pipeline works

The taskflow installs AFL++ and clang, clones the target and picks functions to test. It runs AFL++ in rounds whose time budgets double each time, from 30 seconds up to 960 seconds, about 32 minutes per target, and between rounds it reads the coverage reports and improves its harnesses. Every crash is minimised, replayed under AddressSanitizer to capture a stack trace, and deduplicated. GitHub uses Claude Sonnet 5 by default "because it passed all of our internal tests without issues"; the model can be swapped in a configuration file.

What it found

The repository reports results on five well-known libraries: xz, cJSON, jansson, libexpat and oniguruma. Three of them, xz, cJSON and libexpat, produced no crashes, which the README calls expected because those projects are heavily fuzzed upstream. In oniguruma, a regular-expression library, the agent found two real out-of-bounds reads in the code that formats warnings: a one-byte read past the end of a pattern that ends with a backslash. The other crashes were sorted into buckets such as harness bugs and library hardening.

That is a modest haul, and GitHub presents it modestly. "Treat the verdicts as a very well-prepared starting point for a human, not as final result," the post says.

The warning is the real news

The line developers should remember is in the README: "A prompt-injected agent could in principle do anything your user can". A fuzzing agent has to read other people's code and build scripts, which is exactly where hostile instructions could hide. So the team whose job is finding security bugs is telling you, plainly, that its own agent is an attack surface and needs a fence.

The fence it describes is specific: disposable environments such as Codespaces or throwaway VMs, no elevated privileges, and network access scoped to what git, apt and the build system need. That advice applies well beyond fuzzing, to any agent you let run commands on a machine you care about.

What to watch: whether maintainers of heavily fuzzed projects adopt it, whether GitHub ships a container by default, and how many real bugs it turns up beyond the five reference libraries.