Cloudflare security-audit skill

What it proposes

This is a coding-agent skill that converts an agent into a whole-repository security auditor, and it is unusual in that the security content is only half of what it ships. The mechanism is a six-phase pipeline run by a parent agent that owns all shared state: reconnaissance produces an architecture map plus a coverage-ledger.json of deterministic coverage units (surface × trust boundary × attack class); hunting assigns isolated sub-agents to ledger units and then runs “coverage critics” whose only job is to find what the hunters missed; candidate validation hands every unique candidate to a fresh agent instructed to disprove it; structured output writes confirmed / needs_validation / rejected records into a schema; independent record verification sends the surviving claims to yet another fresh agent that re-checks the source trace; and reporting derives the human-readable documents from the verified records rather than from anyone’s recollection. Two Node validators (~60KB of code with ~55KB of tests) are run by the parent against the ledger and the findings file at defined checkpoints, so the JSON contract is machine-enforced, not merely described in prose.

Three design choices carry most of the transferable weight. First, coverage is a ledger, not a feeling: every unit has an explicit state, a scoped or fast run must mark everything else out_of_scope rather than covered, and the skill forbids implying that one pass exhausts the target. Second, the verdict taxonomy separates priority from certainty — only confirmed records get a severity, and needs_validation means “a specific, named fact is unresolved,” not “I am unsure,” which kills the usual agent habit of hedged findings that are neither actionable nor dismissable. Third, disproof is structurally enforced by agent freshness and write isolation: the agent that found a thing never gets to be the agent that blesses it, sub-agents can write only to their own scratch directory, and promotion of any artifact into retained output runs through a paranoid no-follow, fstat-verified copy procedure in trusted parent code. There is also a real cost model — profiles (quick / standard / deep), an agent-invocation budget, mandatory reserves for critics and verifiers, and defined run_status: "incomplete" failure states with named reasons — which is a more honest treatment of multi-agent spend than most orchestration designs offer. The skill is explicitly agent-neutral (it names “parent,” “Task tool,” and two generic delegated roles) and MIT licensed, and it defaults to a guidance mode where loading it does not authorize the full pipeline.

Best used when

The full workflow thrives on an application codebase with real trust boundaries: a service that accepts untrusted input, a multi-tenant system, a library with a public API, a CLI or daemon that handles attacker-influenced data, anything with an identity or authorization model to defeat. It also assumes a repository large enough that “read it all and think hard” is not a viable single-pass strategy — the coverage ledger only earns its overhead when the surface genuinely exceeds one agent’s working memory, and the additive multi-run design pays off for a codebase audited repeatedly over time.

The guidance mode has a much wider fit and is the more likely everyday use for most setups: loading the attack-class files and the evidence discipline for a focused question about one subsystem, without creating an output directory or spending a fleet of sub-agents. Separately, the orchestration pattern is worth lifting wholesale into any workflow where the failure mode is silent incompleteness rather than incorrectness — a research pass over a large document corpus, a continuity audit across a long manuscript, a compliance or consistency sweep over structured notes. In those domains the ledger becomes “units of source I claim to have checked,” the fresh verifier becomes “an agent that has never seen my reasoning and is asked to break the claim,” and the confirmed/needs-validation split becomes the difference between a verified fact and a named open question. Those three mechanics transfer cleanly and are, arguably, more broadly valuable than the security material they were built for.

Poor fit when

The repository is content rather than code. Markdown vaults, note collections, prose manuscripts, and configuration-light personal projects have no lower-trust principal, no crossed boundary, and no observable security result — which is precisely the bar the skill sets for a confirmed finding. Run the full pipeline against such a target and it will correctly produce almost nothing while consuming the full reconnaissance-plus-hunter-plus-critic-plus-verifier invocation chain to say so. The skill’s own anti-pattern list (“checklist deviations presented as vulnerabilities,” “defense-in-depth advice with no reachable boundary violation”) is an accurate description of what a forced run on a non-code target would have to invent in order to look productive.

It is also a poor fit for the diff-shaped question. “Is what I just wrote safe?” is answered by a passive or on-demand review of pending changes; this skill is deliberately whole-repository and deliberately expensive, and using it per-change inverts its economics. Note the size honestly: roughly 200KB of markdown instruction across sixteen files, of which the parent and its sub-agents load a meaningful fraction, and a standard profile means many separate agent invocations. On a usage-metered plan that is a real bill, and the elaborate budget machinery exists precisely because the authors knew it. Finally, the execution-safety contract is strict by design — no network, OS-enforced sandbox, no dependency installation, read-only target — and if your environment cannot enforce every listed control, the skill’s correct behavior is to refuse to execute and file a blocker, which means a setup without a proper sandbox gets a static-analysis-only run at full orchestration cost. Several companion domains (memory safety and binaries, desktop and mobile IPC, cloud deployment, RPC and messaging) will be dead weight for most single-language or non-service projects; the scoped-run and profile mechanics exist to trim this, and should be used.

Verdict

adapt. As a security tool this is the most rigorous publicly available agent audit workflow of its kind — it is the seed of a production vulnerability-discovery harness, the evidence discipline is genuinely adversarial rather than performative, and shipping tested validators instead of trusting the model to honor a schema is the detail that separates it from the many “security review” prompts that are really checklists in a trench coat. But most projects should not run it as-is. For codebases with real trust boundaries, adopt the guidance mode immediately and reserve the full six-phase pipeline for deliberate, budgeted, scoped audits rather than routine use; for repositories that are content rather than application code, the security pipeline itself is out of scope, and the thing worth taking is the machinery underneath it. Steal the coverage ledger with its explicit out_of_scope-is-not-covered rule, the fresh-verifier-must-try-to-disprove pattern, the confirmed / needs-validation / rejected taxonomy with severity attached only to the first, the rule that a run ends in exactly one of two terminal states (complete, or explicitly incomplete with a named reason), and the budget reserves that stop an orchestrator from spending its whole allowance on breadth and having nothing left for verification. Those five patterns apply to any thoroughness-critical multi-agent workflow, code or not, and the MIT license plus the agent-neutral vocabulary make them cheap to borrow. The honest summary is that this resource’s primary audience — teams auditing production services, multi-tenant infrastructure, and native binaries — is narrower than its secondary value as a reference implementation of how to make an agent’s claim of completeness mean something.