Cloudflare Open-Sourced Its AI Security Audit Skill. Here's How It Works

Cloudflare has published an open-source skill that gives compatible coding agents a structured way to audit a codebase. Its central idea is straightforward: an AI-generated suspicion is only a candidate until someone traces the source, checks the trust boundary, and independently tries to disprove it.

That distinction matters. Finding a risky-looking function is not the same as showing that an attacker can reach it and affect a protected resource. Cloudflare’s security-audit-skill repository makes that evidence path part of the workflow.

Plexicus illustration. All interface details—including repository star and fork counters—are mockups, not live Cloudflare repository data or a Cloudflare product screenshot.

What did Cloudflare open-source?

Cloudflare’s public repository contains a single-repository coding-agent skill: instructions, attack-class guidance, validation rules, schemas, and scripts for producing audit records. It is released under the MIT license. The skill is the starting point that informed a larger internal system; it is not that whole system.

In its June 18, 2026 article, “Build your own vulnerability harness”, Cloudflare described an original seven-step skill workflow and how it grew into an internal vulnerability discovery harness. The current public repository describes its audit as six phases. The two descriptions reflect different versions and scopes, so they should not be collapsed into one sequence.

Cloudflare described a fleet harness covering 128 repositories in about six weeks. Its internal architecture includes persistent orchestration and downstream triage that are not automatically provided by installing the public skill. The public project is best understood as an auditable, single-repository method that teams can adapt.

What is in the repository?

The repository includes SKILL.md for workflow and safety rules; reconnaissance and hunting guides; attack-class references for areas such as AI/LLM security, web protocols, supply chain, cloud, and client-side code; VALIDATION-AND-REPORTING.md; report-schema.json; and zero-dependency Node.js validators for findings and coverage ledgers.

The coverage ledger records which parts of the system were examined, by whom, and with what evidence. Findings are written in a schema that distinguishes confirmed issues, unresolved candidates, and disproved hypotheses. These artifacts make the audit easier to inspect, but their presence does not by itself prove that a conclusion is correct.

The six phases below describe Full audit mode. By default, the skill operates in guidance mode: focused questions and reviews use only the relevant guidance and do not automatically start all six phases or create audit artifacts.

The current six-phase workflow

1. Reconnaissance

The agent maps the application’s architecture, principals, entry points, sensitive resources, and trust boundaries. It records the result in architecture.md and creates a coverage-ledger.json with deterministic units of work. This gives later investigators a defined scope and makes gaps visible.

2. Coverage-led hunting

Isolated hunter agents receive units from the ledger, document the checks they performed, and investigate security hypotheses tied to real boundaries. Coverage critics look for missed areas. This is more specific than “ask several agents to scan the code”: the work and the evidence for coverage are recorded.

A useful hypothesis names the attacker’s starting capability, the protected resource, the path through the application, and the suspected boundary failure. For example, a handler that loads an invoice by an ID is not automatically an authorization flaw. The investigator must determine whether a user can control that ID, whether another layer checks ownership, and whether the request can cross tenant boundaries.

3. Candidate validation

A fresh verifier receives each unique candidate and tries to disprove it. The verifier checks whether the input is attacker-controlled, whether the path is reachable, whether a guard exists elsewhere, and whether the evidence demonstrates an actual security outcome. The discovering agent does not validate its own finding.

4. Structured output

The skill writes findings to findings.json with distinct verdicts:

A schema validator checks structure. It cannot establish exploitability on its own; that is why validation remains a separate phase.

5. Independent record verification

Fresh agents review the final source claims and their evidence. If a record is materially replaced, the replacement receives another independent check. This is a review of the report as a security record, not merely a repeat of the original code investigation.

6. Target-neutral reporting

The verified records and ledger produce REPORT.md, FINDINGS-DETAIL.md, and NEEDS-VALIDATION.md. Teams can see what was confirmed, what remains unresolved, and which areas were covered without receiving a report that overstates uncertainty as fact.

How the public skill differs from Cloudflare’s harness

Cloudflare’s launch article describes an internal Vulnerability Discovery Harness (VDH) and a Vulnerability Validation System (VVS). The VDH organizes source investigation and candidate generation; the VVS handles downstream review such as deduplication, production applicability, prioritization, and routing work to engineering. The larger system also adds fleet-level persistence, cross-repository context, and operational feedback loops.

Those capabilities are important context when reading Cloudflare’s results. A public skill can structure an audit, but its user still needs a compatible agent environment, safe execution controls, and a way to assess deployment-specific exposure. Do not infer that every internal harness feature is included in the standalone repository.

What do Cloudflare’s reported numbers mean?

Cloudflare published figures from its internal system in June 2026. They are company-reported operational results, not an independent benchmark of the public skill.

The 128-repository figure describes the initial VDH fleet footprint. The combined VVS pool was reported across 145 repositories. These are different populations and should not be conflated. The arithmetic also matters: the actionable total follows removal of duplicates and wrong-repository or low-risk recycled items from the combined pool.

“Actionable” does not mean “confirmed exploitable on an internet-facing production system.” Cloudflare’s account concerns its own ring-fenced research and operational context; some records were based on snapshots that could become stale as code and configuration changed. The figures show scale and triage, not a universal detection rate or a count of externally exploitable bugs.

Cloudflare also says it cannot measure a reliable false-negative rate without knowing every vulnerability present. It reported that a single run found roughly half of the issues discovered across repeated runs in its experiments. That is a result from those runs, not a claim that the skill detects half of all vulnerabilities in any codebase.

Audit skill, SAST, and penetration testing

The skill complements other AppSec methods rather than replacing them. SAST can repeatedly analyze code for known patterns and data flows. An agentic audit adds an explicit architecture and trust-boundary investigation, coverage records, and adversarial review. Each approach has different failure modes, and advanced static analyzers can also reason across functions and components.

A source-first audit also differs from runtime penetration testing. Source review may trace an authorization condition and reproduce a bounded behavior locally. An authorized pentest can test a deployed environment with approved accounts and scope, revealing how runtime configuration, identity providers, gateways, and infrastructure affect the path. Neither method alone proves complete security.

Do not point the skill at a live target or treat its “pen-test” trigger as permission to probe a deployed service. Its documented workflow is defensive and source-first. Any target-controlled build, test, process, browser, emulator, fuzzer, or fixture must run inside an OS-enforced sandbox that disables external networking, uses a sanitized allowlisted environment, enforces resource limits, and restricts writes to assigned scratch paths. Without those controls, the workflow says to keep the lead as needs_validation rather than execute target code. Use only code and environments you own or are explicitly authorized to assess.

Installing the skill safely

The project README documents installation through the Skills CLI:

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

For a user-level install, the README adds --global. Start a compatible coding agent in, or pointed at, an authorized repository and request an audit. Node.js is needed for the project’s zero-dependency validation scripts; the agent must support tool use and parallel sub-agents.

Installing the skill does not create an OS sandbox. Before allowing it to execute repository-controlled code, establish the operating-system controls above. Keep proprietary source code within the data-handling terms approved by your organization, use dummy principals and test data, and do not let a build fetch dependencies or inherit credentials. Review the coverage ledger, the exact evidence for each claim, and every proposed fix before acting on the output.

What this means for AppSec teams

The strongest contribution is the workflow discipline: show what was examined, separate candidates from confirmed findings, challenge each candidate independently, and preserve the exact unresolved fact when evidence is incomplete. That structure can make agent-assisted research more reviewable. It does not guarantee full coverage, consistent model behavior, or production impact.

For a broader AppSec program, teams still need to correlate source findings with runtime context, ownership, exposure, and remediation testing. Teams that need to assess authorized running applications can explore Plexicus AI Swarm Pentest as a separate runtime-testing approach. It is not part of Cloudflare’s source-first skill, and the two methods are not equivalent. Evaluate each approach against the evidence it can provide for your authorized scope; the Cloudflare release does not establish product capabilities.

The practical standard is simple: judge a security result by the traceable evidence, the boundary it establishes, the uncertainty it preserves, and whether an engineer can reproduce and act on it—not by the number of findings in a dashboard.

Frequently asked questions

Is Cloudflare’s skill free?

The repository is MIT-licensed. Model usage, compute, and the surrounding agent environment may still have costs.

Is the public skill the same as Cloudflare’s internal system?

No. The public project is a single-repository starting point. The internal harness adds fleet orchestration and downstream validation and triage described in Cloudflare’s blog.

Does it automatically fix vulnerabilities?

The public skill focuses on audit, validation, and reporting. Cloudflare’s internal system separately describes fixing workflows with regression checks and human review; do not assume those are part of the standalone skill.

Does independent verification eliminate false positives?

No. It is a way to challenge unsupported claims and preserve uncertainty. It cannot guarantee that every classification is correct or that no vulnerability was missed.

Can I use it against a production website?

Do not use the source-audit workflow to probe live services. Any runtime validation must have explicit authorization and a separately defined safe scope; the skill’s documented execution requirements concern isolated, local target code.

Sources

• Cloudflare, Build your own vulnerability harness, June 18, 2026.
• Cloudflare, security-audit-skill repository and README.
• Cloudflare, Security Audit skill instructions.