In a September 24, 2026 post on its official blog, GitHub Security Lab open-sourced Fuzzing Taskflow, an LLM-driven fuzzing pipeline: give it a GitHub repository address and it automatically identifies entry points, writes test harnesses, fires up AFL++, reads coverage reports, improves test cases, and finally triages every crash into a vulnerability report — with no human watching.
One command, and the pipeline runs itself
The usage is almost comically simple for a security tool. The code is open on GitHub (organization GitHubSecurityLab, project seclab-taskflows-fuzzing): open a Codespace and run ./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz, and the agent handles the rest — installing AFL dependencies, cloning the repo, finding the most test-worthy functions in the code, and generating fuzz targets for them.
Author Antonio Morales adds an explicit warning in the post: this pipeline runs afl-fuzz, clang, and arbitrary build commands chosen by the LLM directly on the host machine, with no container isolation in between. A prompt-injected agent could theoretically do anything your user account can do, so it must run in throwaway environments — a Codespace or a disposable VM — and never with elevated privileges.
The agent decides, the tools execute
Fuzzing Taskflow is built on GitHub Security Lab's Taskflow Agent framework; the whole pipeline is expressed as a series of taskflows executed end to end by the agent. The architecture has three layers: shell scripts chaining the phases, a set of YAML taskflows describing each phase's prompts, and a set of MCP tools doing the actual work — running AFL, compiling harnesses, storing crashes, reading coverage reports.
The design draws a clear division of labor: the LLM agent holds decision power — what to test, what kind of harness to write, which coverage gap to chase next — while MCP tools expose only execution primitives. The agent never calls AFL or clang directly; it assembles the pipeline from these building blocks. All phase state lives in a SQLite database; phases never pass in-memory data directly.
The default model is Claude Sonnet 5, chosen because it passed the team's full internal testing without tripping safety guardrails; to switch models, edit src/seclab_taskflows_fuzzing/configs/model_config.yaml.
Coverage feedback loop is the core
The two most grinding steps of manual fuzzing are reading coverage reports to find uncovered branches and writing new harnesses for them. Fuzzing Taskflow hands both to the agent: each round gives every harness an AFL run-time budget, replays the queue afterward to produce real line and branch coverage, reads off the uncovered branches, then picks an action — add a seed aimed straight at that branch, extend the harness to call another API, auto-add the magic numbers guarding the condition into the AFL dictionary, or judge it a cold error path and skip.
The time budget doubles each round: 30 seconds, 60 seconds, 120 seconds, up to about 32 minutes. When does it stop? A "plateau detector": two consecutive rounds with absolute line-coverage gains below 1% means diminishing returns — move to the next target instead of burning compute on the last fractions of a percent.
For structured inputs (JSON, XML, regex, PNG, and the like), the pipeline ships four complementary mechanisms: pre-seeded format dictionaries plus custom mutators, source-level dictionaries auto-generated by scanning string constants in the target's source, dynamically growing dictionaries keyed to coverage, and corpus splicing operators.
Crash triage, the most annoying part, is automated too
Finding a crash is only half the job; triage usually costs more time. After fuzzing, the pipeline runs three steps automatically: minimize each crash with afl-tmin, replay under ASan to capture stacks, and deduplicate by "stack-top hash"; then replay all historically known crashes against the new binary to see whether upstream fixes already resolved them; finally, the agent reads the harness source and the crashing function, traces back along the call chain, and writes a Markdown report per crash.
Each report carries a verdict: genuine vulnerability, library_hardening, a bug in the harness itself, OOM, timeout, assertion failure, or duplicate. Telling "a real bug" apart from "the harness was written wrong" is exactly the judgment that used to require a human sitting down and tracing code line by line. Each report also includes a root-cause analysis (with file and line numbers), a reachability argument, an exploitability assessment, a "needs human review" unified-diff fix suggestion, and a regression-test sketch.
Once running, a live dashboard on port 8765 shows each harness's heartbeat, coverage trends, crash heatmaps, and iteration timelines.
Open-source maintainers can give it a try
The most direct beneficiaries are C/C++ open-source maintainers who "know they should fuzz but have no people for it": after onboarding to OSS-Fuzz, writing harnesses, watching coverage, and triaging crashes still took humans — the agent now picks that part up. Of course, Morales himself concedes the agent's verdict is only "a well-prepared starting point," not a final answer — that's why the fix suggestions in the reports are marked "needs review."
Notably, GitHub isn't the only one pushing AI into code security. We previously reported on Cursor's Security Reviewer, which takes the "scan every PR" route; GitHub's pipeline takes the "deep fuzzing" route. One guards incremental code, the other guards legacy code — they complement each other neatly.
