GitHub Security Lab's Fuzzing Taskflow lets an AI agent hunt for bugs in C/C++ code automatically

What GitHub announced

On September 24, 2026, the GitHub Blog published a post by Antonio Morales introducing a new workflow called Fuzzing Taskflow. According to the post, it is built on the GitHub Security Lab Taskflow Agent, the framework GitHub uses to write security automation driven by large language models (LLMs), the kind of AI model behind today's chatbots. The author describes Fuzzing Taskflow as an autonomous fuzzing workflow for C/C++ projects.

Fuzzing is a way of testing programs by feeding them large volumes of automatically generated inputs to uncover crashes and potential vulnerabilities. The author notes that continuous fuzzing is no silver bullet. Even projects that have been enrolled in OSS-Fuzz, a continuous fuzzing program, for years can still hide serious bugs. The reason is that someone still has to watch the coverage (how much of the code the tests actually reach). That person also has to write new harnesses, small pieces of test code that feed inputs into a specific part of the program, for code that is not being reached. Finally, they have to triage the crashes that turn up, sorting them to find the real, distinct bugs. Fuzzing Taskflow is an attempt to hand this manual work to an AI agent.

Read the full description

Sources are collected, independently checked, then reviewed by Jev.

As GitHub describes it, users simply point the workflow at a GitHub repository. It then does the following: - identifies suitable entry points - analyzes the build system - writes harnesses - runs the AFL++ fuzzing tool - reads coverage reports - improves the harnesses - triages every crash - writes a vulnerability report for each unique bug The post says the tool lives in the GitHubSecurityLab/seclab-taskflows-fuzzing repository. It uses Claude Sonnet 5 by default because that model passed all of the team's internal tests, and users can switch models through a configuration file.

How it works: the AI decides, the tools execute

According to the post, the architecture has three layers: - a shell driver, a script that chains the stages together - one taskflow YAML file per stage, which is essentially a set of prompts telling the agent what to do at each step - a set of tools, called MCP tools, that the agent calls to actually do the work The author says the design principle he values most is a clear division of labor. The LLM agent makes the decisions and the MCP tools carry them out. The agent never calls AFL or the clang compiler directly. All state is stored in a SQLite database.

The post also notes that each harness is built twice. An .afl build does the actual fuzzing. A .cov build later replays AFL's test queue to produce real line-by-line and branch coverage reports for the source code.

The coverage feedback loop and stopping condition

The author says that checking coverage and improving coverage used to be manual steps for him. For example, he would read LCOV coverage reports to find uncovered branches, meaning paths through the code that no test had reached. Fuzzing Taskflow hands both steps to the agent. According to the post, in each iteration the agent can choose one of four actions: - add seed inputs, which are starting sample inputs, aimed at uncovered branches - edit the harness to call more APIs - automatically expand the AFL dictionary, the list of special values the fuzzer can insert into inputs - skip gaps not worth pursuing

The time budget doubles with each iteration, from 30 seconds to 60, 120, 240, 480 and 960 seconds, roughly 32 minutes per target. The workflow also uses plateau detection, which means it stops when progress levels off. Once two consecutive iterations each gain less than a configurable threshold (by default 1% absolute line coverage), it concludes that returns are diminishing and moves on.

Structure-aware inputs

The post says the workflow offers four complementary mechanisms for generating structure-aware inputs, meaning test inputs that respect the format a program expects rather than random bytes. For recognized formats, it ships prebuilt AFL dictionaries and custom mutators, which are pieces of code that alter inputs in format-aware ways. These formats include JSON, XML, regular expressions, PNG and length-prefixed binary TLV. For unrecognized formats, it scans the target project's own .c/.h files and extracts string literals and 32-bit numeric constants to use as splicing tokens.

What it means in practice for general readers

• For open-source maintainers: GitHub presents this kind of tool as a way to reduce the manual monitoring and triage work in fuzzing, but each project still needs to judge how well it works for them.
• For everyday users: fuzzing aims to find bugs before software ships. If more projects can test at lower cost, the software people rely on may become more reliable over time. This is an inference, however, because the post provides no data on effectiveness.
• For AI safety: GitHub's own warning shows that letting an AI agent run commands directly carries risks such as prompt injection, and isolated environments remain a basic requirement.
• Source of information: everything above comes from GitHub's own blog, a single source, and has not yet been independently verified.

Frequently asked questions

Browse the latest news in this topic

• Tech news