GitHub Security Lab Open-Sourced an LLM That Babysits AFL++ So You Do Not Have To

Continuous fuzzing still needs a human to write harnesses, stare at coverage gaps, and triage crashes. GitHub Security Lab’s answer is Fuzzing Taskflow: an MIT-licensed, LLM-driven pipeline on top of their Taskflow Agent that takes an owner/repo, installs AFL++, writes harnesses, runs coverage feedback loops, and emits markdown vulnerability reports with suggested patches marked “review required.” Default model: Claude Sonnet 5. Default deployment advice: disposable Codespace or throwaway VM, because the agent runs build commands on the host with no container seatbelt. Finally, an AI security tool that admits it can wreck the machine.

Antonio Morales spelled out the design on the GitHub Blog (September 24, 2026). The GitHubSecurityLab/seclab-taskflows-fuzzing repo remains active (pushes into mid-October 2026). Stars are still early; the interesting part is the architecture, not the vanity counter. If your C/C++ project has never been fuzzed, this is a fast on-ramp. If it has been in OSS-Fuzz for years and still hides bugs in the unread corners, this is a coverage nag that does not sleep.

What it actually does

One driver script:

./scripts/fuzzing/run_fuzzing.sh OWNER/REPO
# example
./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz
# smoke test
./scripts/fuzzing/run_fuzzing.sh DaveGamble/cJSON

From there the agent:

• Installs AFL++ and clones the target
• Picks entrypoints and analyzes the build system
• Writes harnesses
• Builds each harness twice: .afl (afl-clang-lto with ASan/UBSan) and .cov (clang coverage mapping)
• Runs AFL with doubling time budgets: 30s → 60s → 120s → 240s → 480s → 960s (~32 minutes per target at the top end)
• Replays the queue for real line/branch coverage, then chooses seeds, harness edits, or dictionary enrichment
• Stops on plateau: two consecutive iterations each under 1% absolute line-coverage gain (configurable)
• Minimizes crashes with afl-tmin, ASan-replays, dedupes by stack-top hash, writes per-crash reports

Architecture without the keynote

Three layers, cleanly separated on purpose:

1. Shell driver (run_fuzzing.sh) chains stages
2. Taskflow YAMLs (prompts) per stage
3. MCP tools for execution primitives: compile harness, run AFL, store crash, read coverage

The LLM decides. The tools execute. State lives in SQLite (fuzz_context.db), not in a vibes-based chat transcript. That split matters. An agent that shells out to afl-fuzz directly is a prompt-injection piñata. An agent that can only call typed tools is still dangerous (host builds!), but at least the blast radius is designed.

Structure-aware mutators (the part that is not just “wrap AFL in ChatGPT”)

The pipeline ships format-aware dictionaries and custom mutators for JSON, XML, regex, PNG, and length-prefixed TLV. Unrecognized formats get a source-derived dictionary: string literals and 32-bit constants scraped from the target’s own headers, plus coverage-driven enrichment after each iteration when uncovered guards look like strncmp, memcmp, or magic case values. Corpus directories persist across iterations and campaigns under <workspace>/corpus/harness_<id>/, minimized with afl-cmin so you do not rediscover yesterday’s paths from scratch.

Triage verdicts (read them like a junior analyst, not gospel)

Each unique crash report gets one of:

• vulnerability
• library_hardening
• harness_bug
• OOM
• timeout
• assertion_failure
• duplicate

Reports include root-cause notes with file:line references, reachability arguments, exploitability assessment, a suggested unified diff, and a regression-test sketch. GitHub’s own disclaimer: suggested patches are review required. The model gets things wrong. If you merge agent diffs blindly into production crypto parsers, you are the vulnerability.

Operational warnings the blog does not bury

• No container boundary for LLM-chosen build commands. Codespace or throwaway VM. No sudo cosplay.
• Model guardrails: some frontier models refuse useful fuzzing output. Sonnet 5 is the default because it passed their internal tests. Swap models in src/seclab_taskflows_fuzzing/configs/model_config.yaml.
• Live dashboard on port 8765 with coverage sparklines and crash heatmaps. Cute. Still not a substitute for reading the report.
• No published bug-count benchmark in the launch materials. Do not cite imaginary leaderboard wins.

When to reach for it vs OSS-Fuzz vs hand harnesses

• Greenfield C/C++ library: Taskflow is a strong first pass to get harnesses and a corpus.
• Already in OSS-Fuzz: use it to chase coverage gaps the standing jobs ignore, then upstream harnesses the boring way.
• Hard real-time / weird build systems: budget human time. Agents stall on cursed make/cmake jungles.
• Memory safety rewrite fantasies: a crash report is not a migration plan. Nice try though.

Quick start checklist

1. Open a disposable Codespace from github.com/GitHubSecurityLab/seclab-taskflows-fuzzing
2. Confirm you are not logged into anything you care about on that environment
3. Run ./scripts/fuzzing/run_fuzzing.sh DaveGamble/cJSON as a smoke test
4. Watch port 8765; read the markdown reports; verify any “vulnerability” verdict by hand
5. Promote surviving harnesses into your real CI / OSS-Fuzz integration after review

Sloth take

Fuzzing’s bottleneck was never CPU. It was people willing to read LCOV and write another harness on a Friday. Handing that loop to an agent is obvious and overdue. Shipping it with an explicit “this will execute model-chosen builds on the host” warning is refreshingly adult compared to the rest of the AI-pentest toy aisle. Use the disposable VM. Read the diffs. Do not let the dashboard sparkline become your vulnerability management program.

If your product security backlog is mostly “we should fuzz that someday,” Dark Edge Consulting can help turn someday into a calendar.

What “review required” means in practice

Treat agent verdicts like a sharp intern’s draft. Verify reachability from a public API. Confirm the crash is not a harness lie. Check whether the suggested patch changes behavior for valid inputs. Add the regression test the report sketched, then run your real suite. If you cannot explain the bug in one paragraph without the LLM present, you are not ready to merge.

Prompt injection and supply-chain awkwardness

The target repository is attacker-controlled content from the agent’s point of view. A malicious project could include build scripts or comments aimed at steering the model. That is one more reason for disposable environments and unprivileged users. Do not mount production secrets into the Codespace. Do not fuzz untrusted repos on a laptop with your AWS keys in ~/.aws.

Fitting this next to OSS-Fuzz and CI

Ideal flow: Taskflow discovers harnesses and crashes on a branch, humans graduate stable harnesses into continuous fuzzing (OSS-Fuzz, ClusterFuzzLite, or internal AFL/libFuzzer jobs), and the agent becomes an occasional coverage explorer rather than the system of record. Leaving production fuzzing solely to a chatbot with a stopwatch is how you get a demo, not a program.

Related pieces in the Lab’s toolkit

Fuzzing Taskflow sits on seclab-taskflow-agent, the broader framework for LLM-driven security automation via taskflow YAML plus MCP tools. If you are already writing internal agent workflows for code review or variant analysis, the same separation-of-tools pattern applies. If you are not, do not boil the ocean. Run the fuzzing script on one library you maintain and learn what the reports look like before you reorganize your company around agents.

Sources

• GitHub Blog, Antonio Morales, “AI-powered fuzzing with the GitHub Security Lab Taskflow Agent” (Sep 24, 2026)
• GitHubSecurityLab/seclab-taskflows-fuzzing (MIT)
• GitHubSecurityLab/seclab-taskflow-agent