How to audit your code security with AI using the skill Cloudflare released

You can now audit your code’s security with AI using security-audit, the MIT skill that Cloudflare used as the basis for its internal vulnerability harness. It installs with a single npx skills add and works with any coding agent capable of launching subagents in parallel. At the time of writing this note, the repository is trending on GitHub: 6.2k stars, 1.2k of them in a single day.

What sets it apart from asking your agent to “find bugs” is that it doesn’t trust its first answer. Agents that find a vulnerability candidate are never the ones that confirm it. Anything without a concrete attacker, a trust boundary, and an observable result ends up rejected or left open.

What is Cloudflare’s security-audit skill?

It’s a set of instructions, prompts, and two small validators that turns a general-purpose coding agent into a structured security auditor. Cloudflare released it alongside their June 18, 2026 article, Build your own vulnerability harness, which explains that their scanning system at the scale of their entire repository fleet was born from this single-repository skill, and that their prompts still preserve the attack scenarios and bug classes from the original skill with almost no changes.

It doesn’t depend on any specific agent. SKILL.md describes generic roles—a parent agent that coordinates, research agents for focused code reading, and general agents for broader investigation—and asks your agent to use whatever subagent mechanism its platform has.

How does it analyze vulnerabilities?

A complete audit runs through six phases in order:

  1. Reconnaissance. Agents in parallel map the architecture, trust boundaries, entry points, and local build routes. Everything goes into architecture.md and a coverage plan, coverage-ledger.json.
  2. Coverage-guided hunting. Isolated hunter agents take units from the plan and attack them by class: injection, access control, business logic, trust breaches between components, and more. After each wave, coverage-critical agents look for gaps.
  3. Candidate validation. Each candidate goes to a new verifier whose job is to refute it.
  4. Structured output. All results are written to findings.json and validated against a JSON schema.
  5. Independent verification. New agents recheck the final claims against the source code.
  6. Report. REPORT.md, FINDINGS-DETAIL.md, and NEEDS-VALIDATION.md are generated only from already-verified records.

Order matters: the report is written at the end, after verification, so the prose for humans cannot contradict the JSON record.

During reconnaissance, the skill also decides which of its ten specialized files to load: for example, AI-AND-LLM.md for prompt injection and MCP, SUPPLY-CHAIN-AND-RELEASE.md for CI and release signing, or MEMORY-SAFETY-AND-BINARY.md for native code. The instructions are explicit: a file is selected because there’s a real trust boundary, not because a language or dependency name appears in the repo.

Guide mode or full audit?

Loading the skill doesn’t automatically start all six phases. By default it works in guide mode: it answers security questions and does spot checks without creating an output directory. The full flow activates only when you explicitly ask to audit or pen test code, do a complete review, or generate report files. If your request allows both readings, it asks first.

How to install security-audit?

Install it with the Skills CLI:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

For a user-level installation instead of per-project, add --global:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global

Other useful CLI options: --list shows skills in the repository without installing anything, -a, --agent chooses which agents to install it for, and -y skips confirmations. Run npx skills --help to see the full list.

How to security audit your repository?

Open your coding agent in the repository and request the audit in natural language. The README gives these examples:

security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project

If you don’t specify an output directory, results go to ~/security-audit-skill/<repo-name>/run-<N>, outside your repository, so no findings end up in a commit by accident. The skill only writes inside the repo if you explicitly choose a directory that version control ignores.

Quick, standard, or deep?

A complete audit has three profiles:

  • quick runs a single hunting pass and one critical sweep, meant for small targets or a first look.
  • standard is the default profile.
  • deep breaks down the work with more detail and keeps validation and final verification as separate agents, for large or critical code.

You can also scope execution to specific paths, a subsystem, a specialized domain, or the diff between two code refs. In that case the skill marks the report as partial coverage.

Changing profiles changes how much ground the audit covers, not how much evidence it requires. Even quick maintains the validation filter and independent verification of confirmed findings.

What do you need before running it?

According to the README, three things:

  • A coding agent whose model supports tool use and parallel subagents.
  • Node.js, for the two validators, which have no dependencies.
  • An OS-level sandbox for any build, test, or process that executes code from the target itself. It must have:
    • no external network access,
    • an environment built from an explicit allowlist of variables,
    • the target as read-only, with write access only to an assigned scratch/ directory,
    • explicit limits on CPU, memory, processes, and time.

Read that third requirement carefully. If your environment can’t guarantee all those controls, the skill doesn’t cut corners: it doesn’t execute the target code and marks the lead as needs_validation, with the exact blocker and a safe plan to resolve it.

If you use Claude Code, it has a built-in /sandbox that isolates the file system and network for bash commands. Check whether your setup also meets the environment requirements and resource limits before counting on local reproduction.

The skill is also strict with its own limits: no probing deployed endpoints or shared infrastructure, no installing dependencies during the audit, and only main, fixtures, and fake secrets. It describes fixes, but doesn’t modify your code.

Is it free?

The skill is open source under the MIT license; the cost is in model usage, and a multi-agent audit consumes significantly more than a single prompt. The skill makes that spending traceable: roughly speaking, one plan unit equals one hunter allocation, and each candidate that survives needs one or two verifiers depending on the profile.

You can set a budget as a maximum number of agent calls. The skill reserves critical and validation calls before starting to hunt. If the budget doesn’t even cover the minimum, it doesn’t spin up any agents and tells you so, instead of silently handing you a leaner audit.

As a reference, Cloudflare describes complete scans of their harness as periodic backlog sweeps that can take hours on a complex repo, not as a per-PR check. That applies to the harness, not this skill, but it’s a good hint at where this type of audit fits.

How do you read the vulnerability scan results?

Start with findings.json. Each record has one of three verdicts:

  • confirmed: a complete trace in the source code and an observed, bounded outcome. Only these receive severity (critical, high, medium, low, or informational).
  • needs_validation: a concrete hypothesis, anchored in the code, blocked by a single unresolved data point, like a proxy configuration or an identity policy that isn’t in the repo. They don’t receive severity. They’re open questions, not low-confidence vulnerabilities.
  • rejected: a candidate that validation refuted. It’s kept so future runs don’t hunt it again.

The skill runs both validators on its own, and you can run them again:

node <skill-dir>/validate-findings.cjs <output-dir>/findings.json
node <skill-dir>/validate-coverage-ledger.cjs <output-dir>/coverage-ledger.json
```An execution can only end in two ways: with all reports written and both validators in green, or with `run_status: "incomplete"` and the exact reason stated in the report.

### Why run it more than once?

According to Cloudflare's own testing, a single execution found approximately half the vulnerabilities that multiple executions found in total. This is self-reported data from Cloudflare. Each execution reads previous plans and findings, re-reviews everything that changed in the code, and focuses on the gaps. A previous `confirmed` finding is only carried over if its code hasn't changed and still passes verification.

## Claude Code security review or security-audit: which one to use?

They solve different problems, and many teams will want both:

- **Claude Code's `/security-review` command** performs, according to Anthropic's documentation, an on-demand security review of your current branch's changes. It's fast, lives within your usual workflow, and works for reviewing work before commit.
- **`security-audit`** audits complete code (or a bounded portion). It builds a coverage plan, attempts to refute its own candidates, and leaves a machine-readable record you can expand execution after execution. It's more like a scheduled audit than a review step.

If you read our note about [VulnHunter, Capital One's open source vulnerability hunter](https://www.yodev.dev/t/vulnhunter-como-poner-el-cazador-de-vulnerabilidades-de-capital-one-a-trabajar-sobre-tu-propio-repo/3917), the approach will feel familiar: reason from the attacker's perspective and verify itself adversarially. Cloudflare's skill puts more weight on coverage tracking, on the explicit `needs_validation` verdict, and on not depending on any specific agent.

## Does it work with Cursor, Codex, or other agents?

It's designed for that. `SKILL.md` describes itself as agent-agnostic, and the Skills CLI can install in many agents, including Cursor and Codex. The practical requirement is in the README: your agent and model have to support tool use and parallel sub-agents. Confirm it before expecting a full audit.

If you're not working with skills yet, here's a selection of [skills for AI agents](https://www.yodev.dev/t/las-mejores-skills-para-agentes-de-ia-21-que-hacen-codear-a-tu-ia-como-un-senior/2418) to get started.

## What's the relationship to Cloudflare's harness?

The skill is the starting point for a single repository; the harness is what Cloudflare built on top. According to their article, the harness adds:

- persistent state in SQLite,
- deduplication agents,
- dependency tracing across repositories,
- a separate triage system that uses a different model from the discovery phase,
- an agent that generates fixes, whose patches still require human review before merge.

The harness numbers in that article are from Cloudflare and describe the harness, not the skill:

- 20,799 raw candidates, of which about 12,057 passed validation.
- A combined pool of 13,841 findings (including output from another harness), of which 7,245 remained actionable after deduplication and triage.
- A drop in the initial validation rejection rate from 40% to 11% thanks to better recognition context.

When Cloudflare published the article, they said they expected to release the harness soon. At the time of publishing this note, Cloudflare had not released the harness.

## How to avoid installing an unofficial copy?

Always install from `github.com/cloudflare/security-audit-skill` and read `SKILL.md` before running anything. Popular skills attract copies, and the skills directory already lists at least one third-party repackaging under a different name. The ecosystem has already produced [skills that steal credentials](https://www.yodev.dev/t/las-skills-que-instalas-en-tu-agente-de-ia-pueden-estar-robandote-las-credenciales/2048), and a security auditor is the last thing you want from an unofficial source.

## Is it worth it?

Yes, if you use it as intended. security-audit is that rare security tool more strict about what it doesn't claim than about what it finds. Try it first with the `quick` profile on a small service, read `findings.json` before `REPORT.md`, and treat each `needs_validation` record as a question for the service owner, not as a bug. Then run it again.

https://github.com/cloudflare/security-audit-skill