Cloudflare’s Security Audit Skill, Explained
Cloudflare has published security-audit-skill, an MIT-licensed instruction set that turns a coding agent into a multi-phase security auditor. The repository is not a scanner. It ships prompts, attack-class guides, a coverage ledger, JSON schemas, and two zero-dependency Node validators. The agent does the reading, hunting, and verification.
The distinction matters. Most “AI security” tools are either a model wrapped around a prompt or a scanner with a model bolted on. This is a workflow that assumes the model will be wrong, then builds checks around that assumption. Cloudflare says the skill seeded the vulnerability discovery harness described in its Build your own vulnerability harness post. The released repo is the single-repository starting point. The fleet system is described in Cloudflare’s blog.
What the skill actually runs
The README lists six phases. Reconnaissance maps the architecture, trust boundaries, input surfaces, prior evidence, and deterministic coverage into architecture.md and coverage-ledger.json. Coverage-led hunting assigns isolated hunters to ledger units and uses coverage critics to find gaps. Candidate validation gives every unique candidate to a fresh verifier that tries to disprove it. Structured output writes confirmed, needs_validation, and rejected records to findings.json and validates the file against report-schema.json. A second, independent record-verification pass checks the final source claims. Reporting then derives REPORT.md, FINDINGS-DETAIL.md, and NEEDS-VALIDATION.md from the verified records and the coverage ledger.
The released workflow is six phases; Cloudflare’s blog describes the earlier seven-phase version that seeded the harness. The difference is mostly packaging. The important part is the same: a finding must name a lower-trust principal, an accepted input or action, a control that should have stopped it, the boundary crossed, the affected resource, and a concrete observed result. A checklist deviation or a missing best practice belongs in a hardening note; a vulnerability needs a boundary failure.
The skill has two operating modes. Guidance mode answers security questions and performs focused reviews without creating the full audit artifacts. Full audit mode runs when the user explicitly asks to audit or pen-test a codebase, asks for a comprehensive or end-to-end review, or requests the report artifacts. If the request is ambiguous, the skill says to ask one focused question before creating files. That is a sensible default in a world where “review this” often means “look at this function,” not “spend hours and tokens on a six-phase audit.”
Why the design is more interesting than the prompt
The strongest idea is adversarial independence. The agent that validates a finding did not hunt it. The agent that performs final record verification is fresh again. Material replacements get another independent verifier. This is the security equivalent of separating the author from the approver, and it addresses the most common failure mode in agentic review: a model that finds a pattern, then confidently confirms its own interpretation.
The second idea is the coverage ledger. Instead of letting a model roam a repository and report whatever it notices, the skill builds a deterministic plan of surfaces and attack classes, assigns hunters to units, records what was checked, and uses critics to find empty cells. The ledger is also how later runs become additive. Prior findings can be carried forward only when the relevant source and conditions are unchanged; changed source creates current work. The README says multiple runs against the same repo are additive, and Cloudflare’s blog reports that a single run found roughly half of the vulnerabilities that repeated runs found in total. That is a useful admission: one pass is a sample; repeated runs are how coverage grows.
The third idea is the evidence contract. A confirmed record needs a complete source trace and a bounded observed result. A needs_validation record needs an exact unresolved fact and no severity. A rejected record preserves the disproof so a later run does not repeat the same unsupported claim. Severity is allowed only on confirmed records, and overall severity cannot exceed demonstrated impact. That is a stronger discipline than the usual “critical, high, medium” labels applied to unverified model output.
The fourth idea is the sandbox rule. Target-controlled builds, tests, processes, browsers, emulators, and fuzzers run only inside an OS-enforced sandbox with no external network, an allowlisted environment, read-only target and toolchain, scratch-only writes, and resource limits. If any of those controls cannot be enforced, the skill says not to execute target code and to keep the lead as needs_validation with the missing capability as the blocker. This is the right posture for an agent that is about to run code from an untrusted repository.
What ships, and what does not
The repository includes the audit prompts and attack-class guides for core, web, client-side, memory safety, AI/LLM, supply chain, cloud, protocols, resource exhaustion, data isolation, desktop/mobile, and validation. It includes the coverage ledger, the findings schema, and the two zero-dependency Node validators with tests. It does not include the model, the orchestration database, the fleet scheduler, the OS sandbox implementation, or cross-repo dependency tracing. Those belong to the host agent or to Cloudflare’s later harness.
The validators are worth understanding. They are mechanical checks for schema shape and ledger consistency. The documentation is explicit that validator success proves format and ledger consistency only. It does not prove that a finding is real, that a severity is right, or that a patch is correct. Those judgments remain with the verifier and, ultimately, the code owner. That is why the skill produces needs_validation records instead of forcing every lead into a confident verdict.
The limits that matter
The repository is a skill, so its guarantees depend on the host agent following the instructions and on the platform enforcing the sandbox. The repo does not ship a sandbox, a model, or a policy engine. If the agent ignores the scratch-only rule or runs target code outside the sandbox, the workflow’s safety properties do not hold. A team adopting this should verify the host’s tool permissions and sandbox behavior before pointing the skill at an untrusted repository.
Independence is also narrower than it sounds. The skill requires fresh agents, but it does not require different models. Cloudflare’s harness uses different models for discovery and validation; the released skill leaves that choice to the user. Fresh context and a different prompt reduce self-confirmation, but they do not guarantee a genuinely different set of logical weights. Model diversity is an operational choice. The repository can require fresh agents; a different model is up to the operator.
The efficacy numbers are vendor-reported. Cloudflare’s blog says the harness processed 128 repositories and reduced 20,799 raw candidates to 7,245 actionable findings, with 12,057 surviving validation and 5,442 duplicates removed. Those numbers describe Cloudflare’s fleet system, not a controlled benchmark of the released skill. There is no labeled set of every real bug in a codebase, so a recall number would be speculative. The honest claim is narrower: the workflow is designed to keep unconfirmed findings away from human reviewers, and repeated runs improve coverage.
Finally, a confirmed record is confirmed in the skill’s sense: complete source trace and bounded observed result. It is not a merged patch, a public disclosure, or a production incident. The output still needs an owner to review the evidence, decide whether the conditions apply to the deployment, and land the fix. The skill describes the smallest effective source change; it does not modify the target source.
Who should try it
Security teams that already use a coding agent with tool use and parallel sub-agents are the natural audience. The requirements are Node.js for the validators, an OS-enforced sandbox for target code, and enough budget to run a multi-phase audit. Installation is a single command:
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-auditStart with guidance mode on a focused question, then run a full audit on a repository you are allowed to test. Read the coverage ledger and the needs_validation file before the confirmed findings. The gaps are part of the result. A clean report with no confirmed records can be a valid outcome; it means the run did not establish a boundary violation, not that the code is secure.
Bottom line
Cloudflare’s contribution is less “an AI that finds bugs” and more a disciplined way to make an AI’s bug claims survive contact with evidence. The coverage ledger, the adversarial verifier, and the three-verdict schema are the parts worth copying even if you never use the skill. The model is replaceable. The audit trail is the product.