Inside Cloudflare's Security Audit Skill: How to Turn Your AI Coding Agent into a 6-Phase Adversarial Vulnerability Hunter
When developers prompt an AI coding agent to "audit this repository for security vulnerabilities," the result is almost always disappointing. Left to a single-turn prompt, an LLM will scan a handful of obvious files, flag missing defense-in-depth niceties as "High Severity," invent theoretical exploit chains that fail basic reachability checks, and declare the codebase secure once its context window fills up.
To get real application security signal out of coding agents, you have to replace open-ended prompting with deterministic coverage tracking and adversarial verification.
That is exactly what Cloudflare just released with cloudflare/security-audit-skill—an open-source coding-agent skill (now past 39,000 stars on GitHub) that turns any subagent-capable coding assistant into a rigorous, multi-phase security auditor. Notably, this repository is the exact single-repo starting point that seeded Cloudflare's internal, fleet-wide vulnerability discovery harness.
Let's break down how security-audit-skill is architected, why its six-phase adversarial workflow eliminates false positives, and how to run it on your own repositories.
Why Single-Agent Security Reviews Fail
Traditional LLM-based code review suffers from three structural flaws:
- Confirmation Bias: Once an agent forms a hypothesis that a function might be vulnerable to SQL injection or SSRF, it selectively reads surrounding code to confirm its suspicion rather than looking for upstream middleware or type guards that neutralize the input.
- Unbounded Coverage Drift: Without an explicit ledger of what has and hasn't been audited, an agent gravitates toward small, familiar files (
auth.ts, login.py) while completely ignoring complex RPC deserializers, CI/CD release pipelines, or IPC handlers.
- Checklist Severity Inflation: Standard prompts confuse hardening recommendations with exploitable boundary failures. As Cloudflare's design principles state: if Layer A prevents the attack, the absence of Layer B is a hardening note, not a vulnerability.
cloudflare/security-audit-skill solves all three problems by splitting the audit across isolated subagents coordinated by a parent state machine and zero-dependency Node.js validators.
The 6-Phase Adversarial Audit Pipeline
When triggered in Full Audit Mode (e.g., "security audit this codebase"), the parent agent orchestrates six distinct phases, writing structured state to ~/security-audit-skill/<repo-name>/run-<N>:
Phase 1: Reconnaissance ──► architecture.md + coverage-ledger.json
(Validated via validate-coverage-ledger.cjs)
│
▼
Phase 2: Coverage-Led Hunting ──► Isolated Hunter Subagents + Coverage Critics
(11 Domain Attack Matrices)
│
▼
Phase 3: Candidate Validation ──► Fresh Adversarial Verifier Subagents
(Explicitly tasked with disproving candidates)
│
▼
Phase 4: Structured Output ──► findings.json (confirmed | needs_validation | rejected)
(Validated via validate-findings.cjs + report-schema.json)
│
▼
Phase 5: Independent Record ──► Fresh Verifier Agents Check Final Source Claims
Verification (Re-validated via validate-findings.cjs)
│
▼
Phase 6: Target-Neutral ──► REPORT.md + FINDINGS-DETAIL.md + NEEDS-VALIDATION.md
Reporting
Phase 1: Reconnaissance & The Coverage Ledger
Before looking for a single bug, reconnaissance subagents map the repository's architecture, trust boundaries, input surfaces, and prior audit evidence into architecture.md and coverage-ledger.json. Immediately after creating (and updating) the ledger, the parent runs validate-coverage-ledger.cjs—a zero-dependency CommonJS validator—to guarantee every audit unit is properly tracked.
Phase 2: Coverage-Led Hunting Across 11 Attack Domains
Instead of wandering aimlessly through the repo, isolated hunter subagents are assigned specific ledger units and equipped with targeted attack playbooks matched to the codebase's stack:
| Attack Module | Target Surface & Vulnerability Classes |
|---|
ATTACK-CLASSES.md | Core, wildcard, and obvious-things attack prompts |
WEB-PROTOCOL-AND-AUTH.md | HTTP request-framing, cache poisoning, and auth-protocol flaws |
AI-AND-LLM.md | Prompt injection, agent/tool abuse, and insecure output handling |
MEMORY-SAFETY-AND-BINARY.md | Memory corruption, binary parsing, and kernel hunting for native code |
CLIENT-SIDE.md | DOM injection, postMessage trust, UI redress, and prototype pollution |
SUPPLY-CHAIN-AND-RELEASE.md | Dependencies, CI workflows, release signing, updaters, and plugins |
CLOUD-AND-DEPLOYMENT.md | IAM, IaC, containers, serverless, ingress, and runtime config |
PROTOCOLS-RPC-AND-MESSAGING.md | RPC, serialization, message queues, brokers, webhooks, and streaming |
RESOURCE-EXHAUSTION-AND-AVAILABILITY.md | Shared quotas, worker starvation, queue amplification, and operator spend |
DATA-ISOLATION-AND-LIFECYCLE.md | Multi-tenant isolation, cache bleed, search, exports, backups, and deletion |
DESKTOP-MOBILE-AND-LOCAL-IPC.md | Native apps, deep links, WebViews, daemons, helpers, and local IPC |
Once hunters record their checks, dedicated coverage critics inspect the ledger to identify blind spots and unexamined trust boundaries.
Phase 3: Adversarial Candidate Validation
This is the core philosophical breakthrough of the skill:
"The agent that checks a finding is never the agent that found it."
Every unique vulnerability candidate discovered in Phase 2 is handed to a brand-new verifier subagent with a clean context window. That verifier's mission is adversarial: trace the data flow from source to sink, check every sanitizer and type guard along the path, and try to disprove the candidate.
Phase 4 & Phase 5: Three-State Verdicts and Independent Source Verification
Candidates that survive Phase 3 are written to findings.json and validated against report-schema.json using validate-findings.cjs. Every record must fall into one of three strict verdicts:
confirmed: Has a complete end-to-end source trace, violates a real trust boundary affecting a concrete principal or resource, and includes a bounded observed result.needs_validation: A source-grounded lead blocked by an external or runtime fact that cannot be resolved statically or inside the local sandbox. Crucially, needs_validation records carry an exact unresolved fact and no severity rating, preventing speculative bugs from polluting urgent triage queues.rejected: Disproved candidates, preserved in machine-readable form so subsequent runs know the code path was already investigated and falsified.
In Phase 5, another wave of fresh agents independently verifies the final source claims in findings.json. If any material claim is replaced or corrected, it triggers yet another independent verifier pass and a fresh run of validate-findings.cjs.
Phase 6: Target-Neutral Reporting
Finally, the parent derives human-readable markdown artifacts (REPORT.md, FINDINGS-DETAIL.md, and NEEDS-VALIDATION.md) directly from the verified findings.json and coverage-ledger.json.
Hardened Execution Safety: Auditing Untrusted Code Without Getting Compromised
A major risk of running an AI coding agent against an unfamiliar or malicious repository is that building or testing the target can execute arbitrary code on the auditor's machine.
cloudflare/security-audit-skill enforces strict Universal Execution Safety and Write Isolation:
- OS-Enforced Sandboxing: Any target-controlled build, test, browser, emulator, or fuzzer must run inside an OS sandbox with external networking disabled (isolated loopback only), an empty allowlisted environment, read-only toolchain mounts, and strict CPU/memory/disk/wall-clock limits. If an OS sandbox is unavailable, the skill refuses to execute target code and logs the lead as
needs_validation.
- Per-Agent Scratch Isolation: Only the parent coordinator can write to shared audit files. Subagents and sandboxed processes can write only to
<output-dir>/agents/<agent-id>/scratch/.
- TOCTOU-Safe Artifact Promotion: Malicious repositories often attempt symlink or hard-link swap attacks in scratch directories to trick an agent into reading host files. Before promoting any reproduction log from
scratch/ to retained artifacts/, parent-side code opens non-inheritable directory descriptors, walks paths with no-follow directory-relative operations, checks fstat link counts (=== 1), enforces byte caps, and re-runs fstat after reading to reject any file whose identity or size changed mid-read.
Why Additive Multi-Run Auditing Matters
One of the most candid insights in Cloudflare's documentation is their empirical observation on LLM non-determinism:
"In our test runs, a single run found roughly half of the vulnerabilities that repeated runs found in total."
Because security-audit-skill persists coverage-ledger.json and findings.json across runs (run-1, run-2, run-3), multiple runs against the same repository are additive. When you trigger a second or third run, the skill reads prior ledgers and findings to:
- Target previously uninspected gaps in the coverage ledger,
- Revalidate files where the Git commit or worktree has changed, and
- Carry forward verified source evidence without treating stale or
needs_validation leads as complete.
How to Install and Use security-audit-skill
You only need Node.js (for the zero-dependency .cjs validators) and a coding agent that supports tool use and parallel subagents (such as Claude Code, Cursor, OpenCode, or Codex).
1. Install via the Skills CLI
Install the skill into your project or globally across your user profile:
# Project-level installation
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit
# Global installation across your coding agents
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit \
--global
2. Trigger Guidance Mode or Full Audit Mode
The skill operates in two modes depending on your prompt:
- Guidance Mode (Default): Ask focused security questions, review a specific PR diff, or triage a single vulnerability without spinning up the full 6-phase file pipeline.
- Full Audit Mode: Point your coding agent at a repository and ask for a full review:
security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project
By default, full audit artifacts are written cleanly outside your repository to ~/security-audit-skill/<repo-name>/run-<N>, keeping your Git worktree completely clean.
Key Takeaways
cloudflare/security-audit-skill is a blueprint for how complex, high-stakes engineering workflows should be built on top of AI agents:
- Don't trust a single context window—use deterministic JSON ledgers (
coverage-ledger.json) validated by real code (validate-coverage-ledger.cjs).
- Separate discovery from verification—force a fresh adversarial subagent to falsify every candidate vulnerability before a human ever sees it.
- Compound your results—design agent state so that Run #2 and Run #3 build directly on the coverage map of Run #1.
Check out the full source and prompt architecture on GitHub: https://github.com/cloudflare/security-audit-skill
