The AI security audit skill for coding agents from Cloudflare has passed 44,844 stars on GitHub for an unusual reason: it does not promise to find every vulnerability in your code. Instead, it turns a coding agent into a disciplined auditor that knows the difference between a confirmed boundary failure, a lead that still needs proof, and a guess that should be thrown away. If you run a business that ships software, that distinction is worth more than a long list of maybe-bugs. This deep-dive explains what the skill actually does, how its six-phase workflow runs, where it genuinely helps, and where a human still has to take over.
This post is for engineering leads, founders with a codebase to protect, and developers who already use AI coding agents daily. By the end, you will know how to install it, what a run produces, what it costs, and when to call in a professional tester instead. Every project fact below comes from its public repository, checked on 25 October 2026.
What the AI security audit skill for coding agents actually is
Cloudflare’s security-audit-skill repository contains a single coding-agent skill, named security-audit, that orchestrates a structured security audit of a codebase. It is not a scanner you point at a URL, and it is not a one-shot prompt like “find vulnerabilities in this repo”. It is a workflow: a parent agent coordinates isolated sub-agents through reconnaissance, hunting, validation, structured output, independent verification, and reporting. The skill is agent-neutral, so it works with any coding agent that supports tool use and parallel sub-agents, and it is released under the MIT licence.
The repository is small and readable. The skill lives under skills/security-audit/ and consists of a SKILL.md defining the workflow, attack-class guides from memory safety to prompt injection, a JSON schema for findings, and two zero-dependency Node.js validators. Cloudflare says this skill seeded the vulnerability-discovery harness described in Build your own vulnerability harness, which later grew into a multi-stage, fleet-wide system. What is on GitHub is the teachable single-repo starting point, not Cloudflare’s internal production pipeline.
What it can do: the six phases, in plain English
Most AI security reviews fail the same way: the agent reads some code, gets excited about a dangerous-looking pattern, and reports it as a vulnerability. This skill is built to stop that — its six phases each catch the previous phase’s mistakes.
- Phase 1 — Reconnaissance. The agent maps the architecture, trust boundaries, input surfaces, and prior evidence, and writes them into architecture.md and a coverage ledger (coverage-ledger.json). Nothing gets hunted until the map exists, so effort goes where the attack surface actually is.
- Phase 2 — Coverage-led hunting. Isolated hunter agents are assigned units from the ledger, record their checks, and coverage critics look for gaps the hunters missed. Coverage, not enthusiasm, decides what gets examined.
- Phase 3 — Candidate validation. Every unique candidate goes to a fresh verifier agent whose job is to disprove it. The agent that found a bug never gets to confirm its own finding.
- Phase 4 — Structured output. Findings are written to findings.json in three verdicts — confirmed, needs_validation, and rejected — and validated against report-schema.json with a bundled validator script.
- Phase 5 — Independent record verification. Fresh agents verify the final source claims in the report. If a claim is materially replaced, it gets another independent verifier.
- Phase 6 — Target-neutral reporting. The final documents — REPORT.md, FINDINGS-DETAIL.md, and NEEDS-VALIDATION.md — are derived from the verified records and the coverage ledger, not written freehand from memory.
Those three verdicts are the skill’s most important idea. Confirmed means a complete source trace and a bounded, observed result. Needs_validation means one exact unresolved fact and, deliberately, no severity rating — severity without impact is a guess. Rejected records a disproved candidate so the next run does not rediscover it. Runs against the same repository are additive: prior ledgers and findings target gaps and revalidate changed code, rather than treating stale work as covered.
How it works: installation, setup, and a real run
Installation is one Skills CLI command. For one project, run:
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
Add –global for a user-level installation across projects. Then start your agent in, or pointed at, the codebase and ask for a security audit — “security audit this codebase”, “find security vulnerabilities in ./src”, or “do a security review, output to ~/audits/my-project” all trigger it. It has two modes: guidance mode for security questions and focused reviews, which creates no output directory and runs no full workflow, and full audit mode for explicit audit or penetration-test requests, which runs all six phases and writes the report artifacts.
In full audit mode, an unspecified output directory defaults to a repository-named folder with a run number appended. The workflow writes inside the target repository only when you explicitly choose a directory version control ignores — a guard against polluting a repo with audit artifacts. The parent runs the coverage-ledger validator after creating the ledger and after each update, and the findings validator in Phase 4 and after every Phase 5 replacement. The only runtime requirements are a capable coding agent, Node.js, and — critically — an operating-system-enforced sandbox for anything executing target code.
Why it is trending: the problem it solves for teams using AI agents
The timing explains the star count. Coding agents now write a large share of new code, and it ships fast. Traditional scanners reason about patterns, not about what a particular application trusts: which principals can touch which resources, where input crosses a trust boundary, and what the actual security outcome would be. An agent reading the whole codebase can, in principle, answer those questions — but left to itself, it hallucinates, over-claims, and buries real issues under noise. Teams tried the naive version, got burned by false positives, and stopped trusting agent audits.
This skill treats that trust problem as the design problem. Adversarial validation, source-grounded claims, severity only when impact is established, and a rule that a defence-in-depth gap is not a vulnerability (if one layer already prevents the attack, the missing second layer is a hardening note) all push one way: fewer findings, but findings a team can act on. Cloudflare’s note that a single run found roughly half of what repeated runs found is refreshingly honest — run it more than once, and treat coverage as something that compounds.
Its breadth helps too. Beyond usual web issues, it ships hunting classes for memory safety, AI risks such as prompt injection, authentication protocols, client-side issues, supply chain and release signing, cloud configuration, RPC and messaging, resource exhaustion, data isolation, and desktop, mobile, and local IPC surfaces. A small team auditing a mixed codebase gets one workflow instead of five disconnected checklists.
From our experience: where it earns its keep, and where it does not
At MTD Technologies, with 9+ years building client software across web, mobile, and AI, the pattern we see matches Cloudflare’s bet: the bottleneck is never generating candidate bugs, it is deciding which ones are real. A tool that skips validation just moves work onto senior developers, who spend review time disproving its output instead of fixing real issues. A workflow arriving with source traces, bounded observations, and a separate needs_validation list respects that scarce review time — which is why we would pilot this skill before any other agent-audit approach.
That said, be honest about the costs. A full audit is a multi-agent run, and repeated runs multiply the token and time cost. Budget it like a real audit, not a linter — before a release or major refactor, not on every commit. Expect the needs_validation list to be genuinely useful: it names the exact fact that would settle a lead, often a five-minute check for a developer who knows the code. And do not mistake coverage for completeness — a ledger covering every module is not proof every vulnerability class was hunted well, and weak models will produce weak audits no matter how good the workflow is.
One more gotcha: the sandbox requirement is not optional. If OS-enforced sandboxing — no external network, a sanitised allowlisted environment, resource limits, scratch-only writes — cannot be enforced, target code must not be executed, and the lead stays as needs_validation. Teams that let agents execute untrusted project code with broad access to “prove” a bug are creating the very risk they hired the audit to find. Set the sandbox up first.
Responsible use: this is a defensive tool, so keep it one
A security-audit skill is dual-use by nature: the same workflow that finds flaws in your code could be pointed at someone else’s. Use it only on code you own or are authorised to test, with dummy principals, fixtures, and secrets — never production credentials, real user data, or live systems. Its own safety rules forbid probing deployed endpoints, shared infrastructure, or other people’s data, and forbid spending paid API quota or altering releases to prove a point. Those rules are the reason a defensive team can adopt it without becoming the threat it audits against. For formal assurance for customers or regulators, it is preparation for a professional penetration test, not a replacement.
Getting started: a sensible first run
- Install the skill with the Skills CLI command above, globally if you will audit more than one project.
- Confirm your agent runs parallel sub-agents and Node.js is available for the validators.
- Set up the OS-enforced sandbox first: no external network for target code, an allowlisted environment, resource limits, scratch-only writes.
- Pick a small, well-understood repository first, so you can judge whether findings are real.
- Run in full audit mode, then read the needs_validation list first: it shows what the audit could not prove.
- Triage confirmed findings by impact, fix them, and re-run to validate fixes and hunt remaining gaps.
- Judge the skill only after two or three runs — a single run finds roughly half of what repeated runs find.
Frequently asked questions
Is Cloudflare’s security audit skill free to use?
Yes. It is MIT-licensed for commercial use. Your costs are agent and model tokens plus triage time — not a licence fee.
Does it replace a professional penetration test?
No. It is strong preparation: it finds code-level boundary failures with evidence and sharpens the questions a human tester should ask. A professional test adds adversarial creativity, business-logic abuse, and independent assurance no automated workflow can certify.
Which coding agents does it work with?
It is agent-neutral: any coding agent with tool use and parallel sub-agents can run it, since the workflow is expressed as parent, research, and general roles rather than one vendor’s features.
Can it audit any programming language or stack?
Broadly, yes — the attack classes span web, client-side, cloud, supply chain, native, and AI surfaces. Expect the best results where the architecture is clear; obscure or heavily obfuscated code yields more needs_validation leads and fewer confirmed findings.
What do I actually get at the end of a run?
A coverage ledger, a schema-validated findings file with all three verdicts, and three derived reports: a main report, a findings detail document, and a needs-validation document. That paper trail makes the audit reviewable, repeatable, and improvable.
The bottom line
Cloudflare’s AI security audit skill for coding agents earns its 44,844 stars not by finding more bugs, but by being more honest about the bugs it finds. Confirmed means confirmed, with a source trace. Needs validation means exactly one fact is missing. Rejected means disproved, not ignored. For a team that already uses coding agents and wants a repeatable, reviewable pre-release audit workflow, that honesty is the feature — install it, sandbox it properly, run it more than once, and let a human make the final call. If you want help setting up an AI-assisted audit workflow for your own codebase, explore our AI integration and automation services, browse the AI Tools Directory for more vetted tools, or talk to us about what your next release actually needs.