Cloudflare has open-sourced the security-audit skill it used to start hunting vulnerabilities in its own code with AI agents. It’s free, MIT-licensed, and works with the coding agent you already use. The repository has passed 33,000 GitHub stars. The interest says less about the skill itself than about the moment it arrived in: attackers already have models that can read code, find bugs and chain them into exploits. Here’s what the skill does, what Cloudflare learned from it, and how to use it safely.
What Cloudflare released
cloudflare/security-audit-skill is an „agent skill”: a set of instructions, attack checklists and small validators that a coding agent loads when you ask it for a security review. Its README describes it as a skill that „turns your agent into a security auditor.”
It is the starting point of something much bigger. In June 2026, Cloudflare described how a roughly 450-line version of this skill grew, in about six weeks, into a Vulnerability Discovery Harness that scans 128 of its repositories continuously. Cloudflare published the skill alongside that post. In September it reworked the workflow, the findings format and the validators, and the repository has been climbing GitHub’s charts since. The full fleet-wide harness isn’t public yet. Cloudflare says it „will follow shortly”.
- Licence: MIT, free for commercial use.
- Works with: any coding agent whose model supports tool use and parallel sub-agents. The skill is written to be agent-neutral.
- Needs: Node.js for its two zero-dependency validators, and an OS-level sandbox if the agent is going to build or run the target code.
- Covers: web and auth protocols, client-side code, cloud and deployment, supply chain and CI, RPC and messaging, data isolation between tenants, native and mobile apps, and a dedicated file on AI and LLM features (prompt injection, agent tools, unsafe model output).
How it works: six phases, two kinds of agent
Asking a chatbot „is my code secure?” gets you a confident list of maybe-problems. The skill replaces that with a process modelled on how a real security team works:
- Reconnaissance. Map the architecture, trust boundaries and every place untrusted input enters. The result is an
architecture.mdand a coverage ledger listing every unit that needs checking. - Coverage-led hunting. Isolated „hunter” agents each take units from the ledger and look for specific attack classes. „Coverage critic” agents then look for what the hunters skipped.
- Candidate validation. Every candidate goes to a fresh agent whose only job is to disprove it.
- Structured output. Results go into
findings.jsonwith one of three verdicts and are checked against a JSON schema. - Independent record verification. Yet another fresh agent re-checks each final claim against the source code.
- Reporting. A readable
REPORT.md, plus detail files, generated from the verified records only.
The three verdicts are what make the output useful. Confirmed means a complete trace through the source and an observed result. Needs validation means the agent got stuck on one specific fact it couldn’t check, and it says exactly which one. Rejected means a candidate was disproved, so the next run won’t waste time on it. Runs are additive: a second audit reads the previous ledger and goes after the gaps.
The key idea: the agent that finds a bug never confirms it
The skill’s most important rule fits in one line of its README: „The agent that checks a finding is never the agent that found it.” Cloudflare’s engineering post explains why. Agents that grade their own work will confirm almost everything.
This is the same problem that led Google to pause part of its open-source bug bounty a few weeks ago, after it was flooded with AI-generated reports of bugs that didn’t exist. Generating a plausible vulnerability report is cheap. Proving it is the expensive part. Cloudflare’s answer is structural: separate hunters from verifiers, require a source trace and a working proof, and rate severity by real impact. Two more rules from the README follow from that:
- „Severity requires impact.” Likelihood multiplied by impact, not „this deviates from a checklist”.
- „Defense-in-depth gaps are not vulnerabilities.” If one layer already stops the attack, a missing second layer is a hardening note, not a critical finding.
Cloudflare goes a step further internally and uses one model for discovery and a different model for validation, so each finding is checked by a separate set of weights.
What it found at Cloudflare scale
Cloudflare published unusually detailed numbers for the harness that grew out of this skill:
- 20,799 raw candidates from the discovery harness, of which about 12,057 survived validation.
- In the shared triage pool, 5,442 of 13,841 findings were duplicates. Deduplication needed its own reasoning step, because string matching wasn’t enough.
- A typical repository of about 30,000 lines produced around 80 distinct bugs in roughly 3 hours. About 10 of them were critical and were patched in production within about 5 days.
- As the process matured, the share of candidates rejected in validation fell from 40% to 11%.
- Every fix had to turn a failing test into a passing one, and a human reviewed every branch before merge.
Cloudflare also notes that these results came from an isolated research experiment and don’t describe live, unpatched vulnerabilities in its products.
Why this matters in the AI era
The skill exists because Cloudflare saw first-hand what current models can do. In May 2026, as part of Anthropic’s Project Glasswing, Cloudflare pointed a preview frontier model at more than fifty of its own repositories. It reported that the model could chain several small weaknesses into a working exploit, and could compile and run its own proof code, adjusting its approach when a proof failed. Other models often found the same bugs but stopped short of chaining them.
These capabilities „will, in the wrong hands, accelerate the attack side against every application on the Internet.”
Cloudflare, „Project Glasswing: what Mythos showed us”
Three things change for every company that ships software:
- Finding bugs is getting cheap. Reading a whole codebase for weak spots used to take a skilled person days. A model does it in minutes, for attackers and defenders alike. Your code will be read by an AI either way. The real choice is whether you run that review before someone else does.
- The window between disclosure and exploitation is shrinking. Cloudflare mentions teams working towards a two-hour SLA from a public CVE to a production patch. In October, Cloudflare also described letting frontier models attack its own Web Application Firewall: 1,107 attempts across 45 scenarios led to 49 findings and three new or improved WAF rules.
- Your own AI features are a new attack surface. Chatbots, agents with tool access and LLM-generated output all bring new risks, such as prompt injection and an agent being tricked into using its tools against you. The skill gives this a whole file of its own.
Cloudflare’s conclusion is that „faster is not going to be enough”. Patching quickly matters, but so does architecture that makes a bug hard to exploit even when it exists: isolation between components, protection in front of applications, and fixes you can roll out everywhere at once.
How to try it
Install it with the Skills CLI. Add --global to make it available in every project:
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-auditThen open your coding agent in the repository and ask in plain language:
security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-projectA security question or a focused review runs in lightweight guidance mode. An explicit request to audit or pen-test the codebase starts full audit mode: all six phases, with reports written to ~/security-audit-skill/<repo-name>/run-<N>, outside your repository by default. There are three profiles: quick for a fast first look, standard, and deep for high-stakes code.
Before you run it: audit only code you own or are authorised to test. The skill only reads source code until it has a sandbox. If the agent has to build or run your code, it requires an OS-enforced sandbox with no external network, a clean environment and resource limits. Without one, the skill doesn’t execute target code and marks the lead „needs validation” instead. Installing the skill doesn’t set up a sandbox for you. It also never probes live endpoints or production, which is how it should be.
The limits
- One run isn’t enough. In Cloudflare’s tests, a single run found roughly half of the vulnerabilities that repeated runs found in total. Plan for several passes.
- No published false-positive rate for the public skill. Cloudflare’s numbers describe its internal harness. A schema validator checks structure, not exploitability, so review every finding yourself.
- Fixes need care. Cloudflare saw model-written patches that fixed the bug but broke code that depended on it. That’s why it requires a failing-then-passing test and human review for every fix.
- It costs model usage. A full audit launches many sub-agents. Start with the
quickprofile or a scoped run on your most sensitive code. - It doesn’t replace a penetration test. It audits source code. Configuration, infrastructure, people and live behaviour still need their own testing.
What we recommend
Treat AI-assisted auditing as a habit, not a one-off event:
- Start where the damage would be largest: authentication, payments, multi-tenant data access, file uploads, webhooks and any feature that calls an LLM.
- Run it repeatedly, for example before each major release. Because runs are additive, each one builds on the last.
- Triage like a team. Fix confirmed findings first, assign an owner to every needs validation item, and keep rejected items as a record of what was checked.
- Fix with tests. Every fix gets a test that fails before and passes after, and a human review before merge.
- Keep the basics in place: MFA, least privilege, key rotation, dependency updates and tested backups. AI auditing finds bugs in code. It doesn’t fix a weak password policy.
