GitHub Security Lab releases an agent that writes and improves fuzz harnesses
Serguey Asael Shinder2 min readGitHub Security Lab has published the Fuzzing Taskflow, an autonomous fuzzing pipeline for C and C++ projects built on its Taskflow Agent framework, described in a post on the GitHub Blog on 24 September. Given nothing but a repository's owner/repo slug, the pipeline picks entry points, works out the build system, writes harnesses, runs AFL++, reads coverage reports, improves the harnesses, triages crashes and writes a report for each unique bug.
The design separates judgement from execution. An LLM agent decides what to fuzz, which harness to write and which coverage gap to chase; a set of MCP tools does the actual work - compiling a harness, running AFL for a time budget, storing a crash - and all state lives in a SQLite database rather than being passed between stages in memory. Each harness is built twice: once with AFL's instrumentation and AddressSanitizer plus UBSan for fuzzing, and once with clang's source-based coverage so the queue can be replayed into a readable line-and-branch report. The agent reads the uncovered branches after each round and chooses whether to write a new harness, add magic constants to AFL's dictionary, or skip a cold error path. Time budgets double each round from 30 seconds up to 960, and the loop stops when two consecutive rounds each gain less than one percentage point of line coverage. The post says it uses Claude Sonnet 5 by default, because that model passed the team's internal tests, and the model is configurable.
The author is explicit about the risk: the taskflow runs afl-fuzz, clang and build commands chosen by the model directly on the host, with no container, and a prompt-injected agent could do anything the user can. The advice is to run it only in a disposable environment such as a Codespace or throwaway VM, without elevated privileges.
What it means
The pitch of the post is that the expensive part of fuzzing was never running the fuzzer; it was the human loop around it - noticing coverage has stalled, writing the next harness, triaging what comes out. Automating that loop is what makes fuzzing plausible for projects that never had a person to spare for it.
The warning is the part to take seriously. A fuzzing agent reads the target repository's build files and source, and the repository is exactly the input an attacker controls. Pointing an agent that executes build commands at an untrusted project is running that project's code with extra steps. The recommended setup - isolated, unprivileged, disposable - is the only sane one, and teams adopting tools like this should treat any repository they did not write as hostile input to the agent, not just to the fuzzer.