Intel / blog

AI-powered fuzzing with the GitHub Security Lab Taskflow Agent

Source: github.blog
Author: Antonio Morales
Date: Published Sep 24, 2026

From the Daily Brief

Fuzzing finds memory-safety bugs well, but writing harnesses for each target is slow, skilled work, and that bottleneck has kept continuous fuzzing out of most C and C++ projects. GitHub Security Lab's Antonio Morales describes a pipeline built on the Lab's Taskflow Agent that automates the whole loop. The agent identifies entrypoints in a repository, writes AFL++ harnesses for them, reads the resulting coverage reports to decide what to improve, and triages the crashes it finds into vulnerability reports. The team describes it running with no human babysitting. The design choice worth copying is the feedback loop: coverage reports give the agent an objective signal about whether its harness is reaching new code, which is harder to game than a model's self-assessment. Maintainers of native-code projects can use this as a template for adding fuzzing coverage they previously could not staff, while still reviewing reported crashes before filing them upstream.

Read the 2026-09-25 Brief →

Context

GitHub's Fuzzing Taskflow uses an to decide how to extend automated testing into code that earlier runs missed. Fuzzing repeatedly feeds varied inputs into a program to uncover failures. The pipeline reads coverage reports, then can alter the test or supply new inputs aimed at untested branches.

This automates part of the human work around the fuzzer: deciding what to exercise next and preparing crash analyses. The article treats generated vulnerability judgments and patches as material for human review. It also specifies disposable execution environments because agent-selected build commands run on the host without an intervening container.

Key takeaways · AI-distilled

The pipeline separates judgment from execution: the agent decides what to fuzz and which coverage gap to chase, while tools such as compile_harness and run_afl_for do the work. Stages share state only through a SQLite database, not in memory.
Each harness is built twice: an AFL++ binary with address and undefined-behavior sanitizers for fuzzing, and a clang coverage binary that replays AFL's queue to produce real line and branch coverage the agent can read.
Per harness, fuzzing rounds double from 30 seconds up to 960 seconds (about 32 minutes per target). By default the loop stops once two consecutive rounds each add less than 1% line coverage, so the agent does not burn compute on diminishing returns.
For unfamiliar input formats, the pipeline mines string literals and 32-bit constants from the target's own C source into a mutator and dictionary, then appends tokens found in guards (memcmp, strncmp, case values) near still-uncovered lines.
Crashes are minimized, deduplicated by a normalized stack-top hash, and written up with a verdict (vulnerability, harness_bug and others) plus a suggested patch. The author warns verdicts can be wrong and the tool runs LLM-chosen commands on the host, so use a throwaway VM.

Terms in this piece · Glossary

AI agent — An AI system that doesn't just answer once but works toward a goal in a loop — taking actions, reading the results, and deciding what to do next.
agent harness — The scaffolding around a model that turns it into a working agent — the loop, the tools it can call, and the rules for when to stop.
LLM — A large language model — the neural network behind tools like Claude and ChatGPT, trained on huge amounts of text to predict what comes next.
MCP — The Model Context Protocol — an open standard that lets any AI assistant plug into any tool or data source without custom integration code.

Read the source github.blog