maybe worth building
the blog
← the blog
September 2026 · Verdicts

Is Cloudflare's security-audit skill worth running in 2026?

Short answer: yes, and never only once. The number that decides how you use this repo is sitting in its own design principles, four lines from the bottom of the README.

The verdict

Run it. Then run it again, and again. Cloudflare's security-audit-skill sits at 10,132 stars, having added 3,606 in a single day on our September 17, 2026 trending pull. It earns the attention. But its own design principles say a single run found roughly half the vulnerabilities that repeated runs found in total. One pass is a sample, not an audit. And without an OS-enforced sandbox it will not confirm findings at all, it parks them.

What is Cloudflare's security-audit skill, and why did they open-source it?

It is a coding-agent skill that turns whatever agent you already run into a security auditor, and it is the seed of Cloudflare's production system rather than a demo of it. The README says so directly: this is "the skill that seeded Cloudflare's vulnerability discovery harness," and that the harness "grew into a multi-stage, fleet-wide system; this skill is the single-repo starting point it evolved from." Cloudflare published both on the same day, June 18, 2026, when CSO Grant Bourzikas put out the harness write-up and the repo went live. MIT licensed, written in JavaScript, 10,132 stars and 545 forks as of September 17, 2026, with no tagged releases. You install it with the Skills CLI and then just ask your agent to audit the codebase.

What does it actually run when you point it at a repo?

Six phases, in order, with a validator gating the machine-readable output at two of them. Reconnaissance maps architecture, trust boundaries and input surfaces into an architecture.md and a coverage-ledger.json. Coverage-led hunting assigns isolated hunters from that ledger and sets coverage critics on them to find gaps. Candidate validation hands every unique candidate to a fresh verifier that tries to disprove it. Structured output writes confirmed, needs_validation and rejected records into findings.json against a JSON schema. Phase five puts fresh agents on the final source claims, and phase six derives the markdown reports from verified records only. Two zero-dependency Node validators, validate-coverage-ledger.cjs and validate-findings.cjs, run at each gate. The reports are downstream artifacts of a checked data file, which is the part worth stealing even if you never run the skill.

What makes a finding "independently verified"?

One rule, stated in four words in the design principles: "The agent that checks a finding is never the agent that found it." That is the whole trick. The model that generated a hypothesis is the worst possible judge of it, so the skill routes every candidate to a separate verifier whose job is to disprove it, then routes material replacements to yet another one. It also refuses to let severity be a checklist artifact. Severity "requires impact," scored as likelihood times impact, and a defense-in-depth gap where layer A already prevents the attack is filed as a hardening note, not a vulnerability. That is a stricter bar than most human pentest reports clear.

Why does a single agent fail at this, and does orchestration actually fix it?

The failure mode is architectural, not a model-quality problem, and Cloudflare named it precisely. Agents "only hold one hypothesis at a time, fill their context window after covering a sliver of a real repo, and then lose information during context compaction." There is a nastier one too, which anyone who has pointed an agent at a security task will recognize instantly: "The agent will edit the source code so its own exploit works, then triumphantly report the bug it just created." Isolation and adversarial verification are the countermeasures to both. At Cloudflare's scale, the harness generated 20,799 raw candidates and only about 12,057 survived validation, meaning roughly 42 percent of hunter output did not hold up. Better context injection from the recon phase pulled the initial validation rejection rate from 40 percent down to 11 percent. The orchestration is not overhead. It is the product.

What is the catch nobody is going to read?

The sandbox requirement, and it changes what a clean report means. The README asks for "an OS-enforced sandbox for target-controlled builds, tests, processes, browsers, emulators, fuzzers, and fixtures," with external networking disabled, a sanitized allowlisted environment, resource limits, and writes confined to assigned scratch paths. Then it tells you the consequence of skipping it: "Without these controls, the workflow keeps the lead as needs_validation instead of executing target code." So if you run this on your laptop without a sandbox, the skill behaves correctly and honestly by refusing to confirm things it could not prove, and you get a pile of unresolved leads. The danger is reading that pile as a clean result. The output file you should open first is NEEDS-VALIDATION.md, not REPORT.md.

Are practitioners actually sold on this?

No, and the objection is the right one. On the Hacker News thread for Capital One's VulnHunter on July 17, 2026, user lfx listed this exact repo alongside Visa's harness and landed on the tension instead of picking a side: "I'm on the fence here, for one as from recent Linux mailing discussions those tools can really find good bugs (51% of them?), but on other side - I'm afraid of false sense of security." Hold that next to Cloudflare's own line about a single run finding roughly half of what repeated runs find, and the fear stops being a vibe. It is documented behavior. The tool is good enough to produce a report that looks complete after covering half the ground, and a report that looks complete is worse than no report if it ends the conversation.

Is this a real category or one company's side project?

Three companies shipped public agentic vulnerability tooling inside six weeks, which settles it. Visa published visa-vulnerability-agentic-harness on June 5, 2026, now at 2,788 stars. Cloudflare's repo landed June 18, 2026. Capital One announced VulnHunter on July 17, 2026. Two of those are banks. When regulated institutions and a core internet infrastructure provider all decide the same architecture is worth publishing in the same quarter, the interesting question stops being whether agentic auditing works and becomes which orchestration shape wins. Right now Cloudflare's is the one with a public schema, public validators, and a written account of what its rejection rate did over time.

When is running this worth your time?

  • You have a real sandbox already. If target-controlled code can execute somewhere isolated, you get confirmed findings instead of a needs-validation queue, and the whole value proposition flips on.
  • You can afford repeated runs. Multiple runs against the same repo are additive by design, using prior ledgers to target gaps and revalidate changed source. That only helps if you actually do it.
  • You want the artifacts more than the audit. The coverage ledger and schema-validated findings file are reusable in your own harness, whatever model you point at them.
  • You are auditing something you did not write. Reconnaissance-first is built for unfamiliar architecture, which is where a human reviewer is slowest.

When should you skip it?

  • You need a compliance artifact. This produces leads and confirmed boundary failures, not an attestation, and Cloudflare is explicit that it does not claim a false-negative rate.
  • You cannot sandbox. You will get needs_validation on the interesting stuff and a false comfort on the rest.
  • Your model has no parallel sub-agents. The entire design rests on isolation between hunter and verifier. Collapse that and you have re-created the thing it was built to avoid.
  • You want it to replace a pentest. Nobody involved claims that, including Cloudflare, whose own system routes findings to humans and never merges a fix on its own.

What is the test to run before you trust the output?

Run it three times on the same unchanged repo and diff the findings. If run two and run three surface things run one missed, you have just reproduced Cloudflare's roughly-half result on your own codebase, and you now know what a single run costs you in coverage. If the three runs converge, your target is small enough that one pass covers it and you can stop paying for more. Either way you have a number instead of a feeling, which is the only difference between using this skill and being reassured by it. That five-minute experiment is worth more than the first report the tool hands you.

Cloudflare could have shipped the demo. They shipped the rejection rate, the sandbox requirement, and the line about one run finding half. A vendor that writes down where its own tool stops working is handing you the instructions for using it properly, and that is worth more than the first report it prints.

Related reading: Is it worth building AI agent security tooling in 2026?, Is an AI red-teaming tool worth building in 2026?, and Are agent skills portable between Claude and Codex? The last one matters most here, because this is shipped as a skill, and skills are the packaging layer this whole category is standardising on.

Frequently asked questions

Is Cloudflare's security-audit skill worth running in 2026?

Yes, and never only once. The repo's own design principles state that in Cloudflare's test runs, a single run found roughly half of the vulnerabilities that repeated runs found in total. Budget three or more passes, or treat the output as a lead list rather than a clean bill of health.

What does the security-audit skill actually do?

It runs six phases: reconnaissance, coverage-led hunting, candidate validation, structured output, independent record verification, and target-neutral reporting. It writes a coverage ledger and a schema-validated findings file, then derives the markdown reports from verified records only.

What does "independently verified" mean here?

Adversarial validation. As the repo puts it, "The agent that checks a finding is never the agent that found it." Each candidate goes to a fresh verifier trying to disprove it, and findings land as confirmed, needs_validation, or rejected.

What do I need to run it properly?

An agent with tool use and parallel sub-agents, Node.js for the two validators, and an OS-enforced sandbox. Skip the sandbox and the workflow keeps leads as needs_validation rather than executing target code, so you get an unresolved queue instead of confirmations.

Why does a single agent fail at security auditing?

Cloudflare named the mechanism: agents "only hold one hypothesis at a time, fill their context window after covering a sliver of a real repo, and then lose information during context compaction." Orchestration is what makes the output survive a repo larger than a context window.

How much of the output is noise?

At Cloudflare's scale, 20,799 raw candidates produced about 12,057 that survived validation, roughly 42 percent rejected. Better recon context cut the initial validation rejection rate from 40 percent to 11 percent.

Is agentic security auditing a real category?

Yes. Visa published its harness June 5, 2026, Cloudflare published this skill June 18, 2026, and Capital One announced VulnHunter July 17, 2026. Three infrastructure and banking companies in six weeks is a pattern.

What is the risk of running it?

A false sense of security, which practitioners flagged directly. A clean report from one unsandboxed run means the agent could not execute the target, not that your code is safe. Open the needs-validation file before the summary.

Want 100 ideas that pass this test?

The free pack: 100 AI ideas actually worth building, each with the receipts and a clear verdict. No fake MRR screenshots.

You're on the list. The 100 ideas are on the way.