Cloudflare's Security-Audit Skill, Explained

Most "AI security scanner" projects are a prompt in a trench coat: ask the model to look for bugs, print whatever it says, hope it's right. The cloudflare security audit skill is built on the opposite assumption, which is that a model's first answer about a vulnerability is a candidate and nothing more. Cloudflare open-sourced it in June 2026 under MIT, and as of September 2026 it sits at 7,481 stars with 430 forks.

What makes it worth a read isn't the finding-generation. It's the machinery for throwing findings away.

What the cloudflare security audit skill does

The repo is a coding-agent skill, so it installs into an agent you already run rather than shipping as a standalone scanner. Point your agent at a codebase, ask for a security audit, and the skill orchestrates a six-phase run:

Reconnaissance comes first, mapping architecture, trust boundaries, input surfaces and prior evidence into architecture.md and a coverage-ledger.json. Then coverage-led hunting assigns isolated hunters to units drawn from that ledger, records what each one checked, and runs coverage critics whose only job is to find the gaps the hunters left. Candidate validation follows, and this is the hinge: every unique candidate goes to a fresh verifier that tries to disprove it.

Phase four writes structured output, sorting records into confirmed, needs_validation and rejected inside findings.json, validated against a report-schema.json. Phase five sends fresh agents back to verify the final source claims, and any material replacement gets yet another independent verifier. Only then does phase six derive the human-readable REPORT.md, FINDINGS-DETAIL.md and NEEDS-VALIDATION.md.

Why "fresh verifier" is the whole design

An agent that finds a bug and then checks its own bug has already committed to an answer. It'll defend it, because everything in its context is the reasoning that produced it. Handing the candidate to an agent with a clean context and the instruction to disprove it removes that pressure entirely.

The three verdicts are defined tightly enough to be worth quoting. A confirmed record needs a complete source trace and a bounded observed result. A needs_validation record must name the exact unresolved fact, and it carries no severity at all, which kills the usual trick of assigning "medium" to something you couldn't be bothered to chase down. A rejected record documents a candidate that was actively disproved rather than quietly dropped.

Keeping rejections is the unglamorous part and probably the most valuable. A scanner that only shows hits gives you no way to tell "we looked and it's fine" from "we never looked," and that distinction is most of what a security review is actually for. It's also what makes the output survive a handoff: six months later, the person asking why a given subsystem was never flagged gets an answer from the ledger instead of a shrug.

Two zero-dependency validators enforce this rather than trusting the model to comply: validate-coverage-ledger.cjs runs after the ledger is created and after every later update, and validate-findings.cjs runs in phase four and again after every phase-five replacement. Both ship with their own test files. The skill assumes its own agents will drift and puts deterministic checks in the path.

The attack-class library

Beyond the orchestration, the bulk of the repo is hunting methodology split across domain files, and the list is a decent map of where things break in 2026:

• MEMORY-SAFETY-AND-BINARY.md for native and kernel targets
• AI-AND-LLM.md covering prompt injection, agent and tool abuse, and output handling
• WEB-PROTOCOL-AND-AUTH.md for HTTP request framing, cache behaviour and auth protocols
• CLIENT-SIDE.md for DOM injection, messaging trust, UI redress and prototype pollution
• SUPPLY-CHAIN-AND-RELEASE.md on dependencies, CI, signing, updates, plugins and extensions
• CLOUD-AND-DEPLOYMENT.md for IAM, IaC, containers, serverless and ingress
• DATA-ISOLATION-AND-LIFECYCLE.md on tenant isolation, exports, backups, deletion and restore
• RESOURCE-EXHAUSTION-AND-AVAILABILITY.md, which notably includes operator spend as an availability concern

The domain split also tells you how to read a run. A web service audited with this skill spends most of its budget in three or four of those files and legitimately skips the rest, and the coverage ledger records that decision rather than hiding it. That an AI-and-LLM attack class sits beside memory safety as a peer category says something about how the threat model has shifted. Prompt injection and tool abuse are now routine audit surface, not a research curiosity, and we've written before about how a coding agent can be fed fabricated tool output to steer it.

Where it came from

The README traces the lineage directly: this is the skill that seeded Cloudflare's internal vulnerability discovery harness, described in Build your own vulnerability harness, published 18 June 2026 by Dan Jones, Alexandra Godoi and Grant Bourzikas. The same day the repo was created. That post describes a two-stage system, a Vulnerability Discovery Harness feeding a Vulnerability Validation System, running fleet-wide across repos.

The open-sourced skill is explicitly the earlier, single-repo ancestor of that harness rather than the harness itself. Useful to know before you set expectations: you're getting the seed, not the production fleet system Cloudflare runs internally.

That provenance is also the strongest argument for taking the cloudflare security audit skill seriously. Plenty of security tooling gets open-sourced as a marketing artifact, built for the announcement and abandoned after it. This one is the documented starting point of something a large infrastructure company still runs against its own code, which is a different kind of evidence than a star count.

Installing and running it

Installation goes through the Skills CLI:

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

Add --global for a user-level install. Then start your coding agent in the repo you want audited and ask it for a security audit. Nothing about the cloudflare security audit skill requires a Cloudflare account, a hosted service, or an API key beyond whatever your agent already uses.

One property worth planning around: multiple runs against the same repo are additive. The skill reads prior ledgers and findings to target gaps, revalidate source that changed, and carry forward evidence that's still current, and it's careful not to treat stale or unresolved work as covered. So the second run is cheaper and sharper than the first, which only pays off if the artifacts from run one still exist when run two starts.

That's a real operational detail rather than a footnote. The coverage-ledger.json and findings.json from previous audits are the skill's memory, and if they live on whichever laptop happened to run it, the additive behaviour quietly stops working. Giving recurring jobs a durable home is the problem Zentor is built for: the run happens on schedule, the ledger persists between runs, and what accumulates belongs to you rather than to one machine's filesystem.

Delivery has the same shape. A six-phase audit produces three markdown reports and two JSON files, and the moment those land in a terminal somebody has to move them to wherever the team actually triages. Zentor closes that hop by putting the finished report back into the tracker or doc the work already lives in, which matters more for the audit you run every month than for the one you run once.

What it doesn't replace

The skill produces an evidence trail; it doesn't produce assurance. A confirmed verdict means one agent found something and an independent agent failed to disprove it, and that's a genuinely higher bar than most automated tooling clears, but it isn't a human deciding whether the finding matters for your threat model, your users or your compliance position.

Coverage is honest but bounded too. The ledger records what was checked, which tells you the shape of the gap without filling it. Reading NEEDS-VALIDATION.md carefully is probably more informative than reading REPORT.md, since that's where the unresolved facts sit with severity deliberately withheld.

Cost deserves a mention too, because nobody advertises it. Six phases with isolated hunters, coverage critics and fresh verifiers per candidate means a lot of separate agent invocations, and on a large repo that adds up in tokens and in wall-clock time. The additive design softens this over repeated runs, but the first pass on a big codebase is not a cheap operation and shouldn't be scheduled as if it were.

The other thing to keep in view is that you're handing a model your source. Whatever your rules are about code leaving the building, an agent-driven audit is subject to them, and that's a policy question rather than a technical one. Our broader write-up on the security risks that come with running agents covers the adjacent surface, and red-team skills sit on the offensive side of the same coin.

FAQ

Is the security-audit skill free and official?

Both. It lives under Cloudflare's GitHub organization with an MIT license, so commercial use and modification are fine. There's no paid tier and no Cloudflare account involved.

Which coding agents can it run on?

It installs through the Skills CLI at skills.sh, which handles agent selection, so it isn't bound to one vendor. The content is markdown instructions plus two Node validator scripts, meaning any agent that can read a skill directory and run .cjs files can execute it.

Does it replace a human security review?

No, and the design says as much by separating confirmed from needs_validation and refusing to assign severity to the latter. It narrows what a reviewer has to read and shows its work; deciding what to fix stays with a person.

Can I run the cloudflare security audit skill on a private repo?

Yes; it runs wherever your agent runs and has no hosted component. Whether you should is a question about your own policy on source code reaching a model provider, not one the skill answers for you.

How is this different from a normal SAST scanner?

Static analysis matches patterns it was programmed to recognize and produces a fixed rule set's worth of results. This runs exploratory agents against attack-class methodology, then tries to disprove what they find. Different failure modes: SAST misses novel classes, and an agent invents plausible ones, which is precisely what the disproof phase exists to catch.

Does it need network access or a Cloudflare service?

Neither. The repo has no release artifacts and no hosted component; it's instruction files and validators that run wherever your agent runs.

Worth a look

Strip away the security framing and the cloudflare security audit skill is a reference implementation of something the whole agent ecosystem needs: separate the agent that proposes from the agent that verifies, define your verdicts so tightly that hedging becomes impossible, keep the rejects, and enforce the schema with code instead of asking nicely.

Fourteen commits, no releases, MIT, and it moves as fast as a main branch does, so pin a commit if you need the behaviour to stay still. Clone it, read SKILL.md and VALIDATION-AND-REPORTING.md, and steal the verdict taxonomy for whatever you're building. That part isn't about security at all.