Cloudflare Security Audit Skill Turns AI Code Review Into an Adversarial Workflow

Cloudflare has released a six-phase AI code-auditing workflow, but the Cloudflare security audit skill is not another prompt that asks a model to find bugs. It assigns separate agents to map code, hunt vulnerabilities, challenge findings, and verify the surviving evidence.

That distinction matters because AI-generated security reports often contain plausible claims without a valid attack path. Cloudflare’s design treats every proposed vulnerability as an allegation that another agent must try to disprove. It also records what the audit covered, which makes missing analysis more visible.

The open-source release packages ideas that Cloudflare developed while building a much larger internal vulnerability harness. The public skill targets one repository and one audit run. Cloudflare’s internal system, by contrast, persists results across repositories, traces dependencies, and manages thousands of findings.

That creates the central tension around the release. A reusable skill lowers the barrier to structured AI code review, but it cannot reproduce Cloudflare’s internal infrastructure by itself. Developers gain a stronger starting point, not an autonomous replacement for security engineers.

What the Cloudflare Security Audit Skill Actually Changes

Cloudflare is turning AI security review from a conversation into an evidence-producing process with explicit coverage and verification gates.

The public audit skill repository describes a workflow built for coding agents that support tools and isolated subagents. It is licensed under the MIT License and can be installed through the Skills command-line interface.

The Cloudflare security audit skill divides an audit into six phases. Reconnaissance maps the software architecture, trust boundaries, input surfaces, and available evidence. The process records that map in an architecture document and a machine-readable coverage ledger.

Coverage-led hunting comes next. The parent agent assigns isolated hunters to defined areas and attack classes. Each hunter records what it checked instead of returning only a list of suspected problems.

That ledger is important because a short report can otherwise create false confidence. An agent might inspect authentication code, find nothing, and imply that the entire application looks safe. A coverage record can show that parsing, deployment configuration, dependency handling, or tenant isolation received little attention.

Candidate validation gives each distinct lead to a fresh verifier. That verifier tries to reject the proposed vulnerability by checking its assumptions, source path, affected principal, and security outcome. The hunting agent does not approve its own work.

Surviving findings then move into structured output. The skill separates records into confirmed findings, issues needing validation, and rejected candidates. A schema defines the required fields, while included JavaScript validators check the files mechanically.

The final phases independently verify the source claims and generate target-neutral reports. Material changes to a finding trigger another verification pass. This design tries to prevent a report writer from quietly strengthening a weak claim during summarization.

The result differs from a normal AI code security audit in one crucial way. The deliverable includes an account of examined surfaces, rejected ideas, unresolved facts, and independently checked findings. A clean-looking report is no longer the only artifact.

Cloudflare also defines a strict execution boundary. Builds, tests, fuzzers, browsers, and target-controlled fixtures require an operating-system sandbox without external network access. Without those controls, the workflow must preserve a lead as unverified instead of executing untrusted code.

That restriction makes the release less convenient than a one-line audit prompt. It also reflects a real security problem. Code under review can contain instructions or build behavior that attacks the auditing environment itself.

Why Cloudflare Built a Skill Before a Fleet-Wide Harness

The public skill is valuable because it captures Cloudflare’s audit method, while also revealing why a single agent session reaches an operational ceiling.

Cloudflare says the project began as an approximately 450-line security skill for a single repository. Engineers refined its prompts until it surfaced useful bugs, then carried its scenarios and validation rules into a larger system.

The company detailed that evolution in its vulnerability harness engineering post. The first version used three research agents for reconnaissance, separate hunters for attack classes, adversarial validators, structured findings, and independent source verification.

Cloudflare identified three limits during those early runs. Long sessions exhausted the model’s context, interrupted executions lost progress, and single-repository reviews missed relationships with consuming services.

Those failures were not simply model-quality problems. They were state-management problems.

A model can reason about the code currently in its context, but a large audit produces many parallel hypotheses. Each hypothesis carries files, trust boundaries, assumptions, experiments, counterarguments, and status changes. Compressing that history into a conversation summary can discard decisive details.

Cloudflare responded by externalizing state. Its later harness treats language models as replaceable workers and keeps durable audit information outside their context windows. A database stores the run, repository, and stage for each task.

The distinction explains why Cloudflare released the starting point rather than presenting it as the finished internal system. A skill can encode a rigorous sequence inside a coding environment. It cannot automatically provide fleet inventory, durable queues, dependency graphs, or production telemetry.

Cloudflare reports that moving from its first skill to a system spanning 128 repositories took about six weeks. That internal system works across Rust, Go, C, Lua, TypeScript, Python, and configuration formats without per-language orchestration.

Its larger workflow separates discovery from validation. The Vulnerability Discovery Harness maps and hunts potential weaknesses. A different Vulnerability Validation System deduplicates results, checks production relevance, and manages remediation.

Cloudflare says it uses different models for those two stages. That choice reduces dependence on one model’s recurring reasoning patterns. It also lets the company change providers without redesigning the security process around a particular model.

This model-neutral position pressures vendors that frame benchmark performance as the main measure of an AI security product. Cloudflare’s argument is that orchestration, evidence, and independent rejection determine whether model output becomes useful engineering work.

The company is not claiming that the skill recreates its production pipeline. Its own guidance says teams should begin with reconnaissance, hunting, and validation. Cross-repository tracing and dedicated deduplication become useful only after audit volume creates those problems.

That sequencing gives smaller teams a practical entry point. They can test whether the prompts and evidence rules work on their code before building expensive infrastructure around them.

It also prevents the public release from becoming a misleading product demo. The repository offers the method that seeded Cloudflare’s system, not the full system that now operates across its fleet.

The Real Opponent Is One-Shot AI Code Review

The Cloudflare vulnerability harness challenges the assumption that one capable model can inspect a repository, identify real flaws, and reliably grade its own conclusions.

A one-shot review usually follows a familiar pattern. The developer gives a coding agent access to a repository and asks it to find security vulnerabilities. The agent reads selected files, identifies suspicious patterns, and writes a polished report.

That process can produce useful leads. It can also hide three distinct failures.

First, the model chooses what to inspect without preserving a durable record of what it skipped. Second, the same reasoning process generates and evaluates each claim. Third, persuasive language can make incomplete evidence sound final.

Cloudflare’s workflow attacks each failure separately. The coverage ledger records the intended audit surface. Independent hunters examine bounded units. Fresh validators try to disprove candidates rather than improve their presentation.

This adversarial split is more important than simply adding more agents. Ten agents sharing the same assumptions can generate ten versions of the same false positive. Cloudflare assigns different roles and gives validators authority to reject a hunter’s theory.

The skill also requires a concrete boundary failure. A confirmed issue needs an affected principal, resource, or security result. Missing a best practice does not automatically become a vulnerability.

That distinction filters findings such as unrestricted behavior available only to an already trusted administrator. It also rejects reports that describe an absent defense without showing how an attacker crosses an actual boundary.

Cloudflare’s internal process uses stronger proof requirements. A confirmed finding must include a reproducible test against the original codebase. The test cannot depend on source changes introduced by the hunting agent.

This rule addresses an especially dangerous failure mode. An agent can modify code while experimenting, then demonstrate an exploit against the modified version. Without source-state controls, the resulting report may attribute an agent-created flaw to the application.

Mechanical validation adds another layer. Ordinary code checks whether cited files, paths, patches, and tests exist or parse correctly. The language model does not decide whether its own output satisfies these basic structural requirements.

Cloudflare says a single skill run found roughly half the vulnerabilities that repeated runs eventually discovered. That is a company-reported observation, not an independently measured recall rate.

Still, the result supports the release’s central design choice. One completed run does not establish complete coverage, even when every reported finding is valid.

A rigorous AI code security audit therefore needs two different confidence statements. One concerns the validity of each finding. The other concerns how thoroughly the audit searched for findings.

The Cloudflare security audit skill exposes both questions. Its confirmed, unresolved, and rejected verdicts describe evidentiary confidence. Its coverage ledger describes the search process.

Traditional static analysis remains relevant within this model. Deterministic scanners excel at known patterns, data-flow rules, and repeatable checks. An agent can explore application-specific trust assumptions or compose weaknesses across unfamiliar logic.

Cloudflare’s internal experience also offers a warning about assumed tool preferences. The company says its hunters did not invoke an integrated Semgrep path during one month of runs. They preferred reading and executing code, while frequently requesting missing environments or fixtures.

That observation does not show that static analysis lacks value. It shows that installing a tool does not guarantee that an agent will use it effectively. Teams must measure actual tool behavior inside their workflow.

The competition is therefore not AI versus conventional scanners. It is unstructured model output versus an audit process that combines deterministic checks, specialized exploration, and adversarial verification.

Structured Findings Reduce Noise, but They Do Not Prove Safety

The strongest part of the release is its refusal to treat plausible model output as confirmed evidence, yet that discipline cannot measure undiscovered vulnerabilities.

Cloudflare reports that its internal discovery harness generated 20,799 raw candidates. About 12,057 survived the initial validation stage before entering a larger validation pool.

After findings from another harness joined that system, the central pool contained 13,841 records. Deduplication removed 5,442, while 1,154 were routed away as wrong-repository or low-risk cases. Cloudflare says 7,245 actionable findings remained for engineering teams.

These numbers are useful because they show how much filtering sits between generation and remediation. They should not be interpreted as an independent benchmark of detection accuracy.

Cloudflare selects its own repositories, models, prompts, attack classes, and definitions. The published figures describe its operational pipeline. They do not establish how the public skill performs on an unrelated codebase.

The company explicitly avoids claiming a false-negative rate. A real repository has no complete label set containing every vulnerability, so recall cannot be calculated directly. Repeated runs that continue finding bugs show incomplete coverage, but not the size of the remaining gap.

That uncertainty belongs at the center of any assessment. A verified report can establish that several findings are real. It cannot establish that the audited code is safe.

The public skill attempts to communicate this difference through three verdicts.

A confirmed finding has a complete source trace and a bounded observed result. A needs-validation record preserves an exact unresolved question without assigning unsupported severity. A rejected record documents why a candidate failed.

Keeping rejected candidates has practical value. Future runs can distinguish a genuinely new path from a previously disproved idea. Reviewers can also inspect whether rejection depended on facts that later changed.

However, structured output can create its own illusion of certainty. A valid JSON record is not necessarily a valid security conclusion. Schema validation can confirm required fields and accepted values, but it cannot prove that an exploit crosses a real boundary.

Cloudflare addresses that limitation through fresh source verification. The verifier reviews the code claim independently, and a material replacement receives another check. Yet the quality still depends on model behavior, available context, and the correctness of the threat model.

Sandboxing presents another adoption challenge. The skill requires operating-system controls around target-controlled builds and experiments. Many everyday coding-agent environments do not provide that isolation with clear resource and network limits.

Teams that ignore this requirement risk running malicious dependencies, build scripts, or test fixtures. Teams that respect it must retain some promising leads as unresolved until a safe environment becomes available.

Prompt injection creates a related concern. Source files, documentation, issue text, and generated artifacts can contain instructions aimed at the agent. Cloudflare’s later commercial workflow says it treats code, logs, and metadata as evidence rather than instructions.

That same boundary must exist in local use. A security agent should never interpret repository content as authority to expose credentials, expand network access, or modify unrelated systems.

The secure software framework from NIST offers a useful reference point. It treats secure development as a set of organizational practices spanning preparation, protection, production, and vulnerability response.

An AI auditing skill covers only part of that lifecycle. It can help investigate source and document candidate weaknesses. It does not establish secure design, access governance, dependency provenance, deployment controls, or incident readiness.

Human review remains essential for the same reason. Engineers understand intended behavior, production architecture, business impact, and compensating controls that may not appear in a repository.

The release should therefore change the shape of review, not remove reviewers. Security teams can spend less time sorting unsupported claims and more time testing evidence, prioritizing exposure, and approving fixes.

Cloudflare Is Connecting Code Findings to Production Context

Cloudflare’s larger strategy is to combine source-code findings with traffic and defensive telemetry, something the standalone skill cannot do alone.

A source scanner can identify an unsafe handler without knowing whether that handler runs in production. It may not know which route reaches the code, how frequently clients use it, or whether active controls block the relevant requests.

Cloudflare’s invitation-only Vulnerability Discovery and Remediation service tries to close that gap. The company announced the service on September 3, 2026, as part of Cloudflare Managed Defense.

According to its context-aware remediation announcement, the service connects authorized code analysis with Web Assets, Web Application Firewall data, and Workers observability.

The service uses OpenAI Daybreak models, including GPT-5.6 Cyber, for reconnaissance, hunting, and validation. Cloudflare says prompts pass through AI Gateway to OpenAI’s servers. Model inference does not run at Cloudflare’s edge.

That implementation illustrates why the open-source skill and commercial service serve different roles. The skill organizes a repository-level investigation. The service adds information about deployed routes, request volume, security events, and existing controls.

Production context can change priority without changing technical validity. A real vulnerability on an unreachable development path deserves different treatment from the same flaw on a heavily used public endpoint.

Cloudflare says its process can propose a code patch and a narrowly scoped WAF rule when the evidence supports both. The edge rule can reduce exposure while engineers review the permanent code change.

The service does not let the model deploy its own proposal. Tool calls are logged and evaluated against an access policy. External checks test patches and rules, while customers decide whether changes are implemented.

This approach turns the Cloudflare vulnerability harness into more than a discovery engine. It becomes part of an exposure-management system that links source evidence, runtime context, mitigation, and remediation.

That strategy also explains the company’s emphasis on target-neutral reports. The same audit method can inspect different languages and application types, while production-specific systems supply the context needed for prioritization.

Most teams using the public skill will lack equivalent network visibility. They can still improve decisions by supplying deployment manifests, route maps, ownership records, and sanitized logs as controlled evidence.

They should keep provenance clear. A source finding, deployment assertion, and traffic observation are different claims. Combining them inside one paragraph should not erase where each fact came from.

This is where disciplined knowledge handling matters. Engineering teams need a searchable record connecting architecture decisions, audit evidence, rejected hypotheses, and later fixes. A maintained technical knowledge base can keep those records available beyond one agent session.

The public skill already moves in that direction through persistent artifacts. Architecture notes, coverage records, machine-readable findings, and human reports give future reviewers something more durable than a chat transcript.

Still, a repository remains an incomplete picture. Infrastructure policy, secrets management, authorization configuration, service dependencies, and user behavior can determine whether a source-level weakness becomes exploitable.

The teams most likely to benefit will treat the skill as one evidence generator inside a wider security program. The teams most likely to struggle will expect a repository scan to answer production-risk questions that the repository does not contain.

Three Signals Will Show Whether the Release Matters

The next test is whether developers can reproduce Cloudflare’s discipline without Cloudflare’s private infrastructure, data, and security staff.

The first signal is the quality of public audit artifacts. Useful adoption will produce reports with precise trust boundaries, reproducible evidence, meaningful rejected candidates, and honest unresolved questions.

A rising installation count would show interest, but not effectiveness. The better measure is whether independent teams publish audits whose confirmed findings survive maintainer review.

The release’s current design supports that evaluation. Its coverage and findings schemas create comparable artifacts, while validators can catch malformed records before human review begins.

The second signal is how the repository evolves after real use. Cloudflare’s internal harness learned from repeated runs, missing environments, shallow coverage, and rejected findings. The public skill will face a wider range of languages, build systems, and agent platforms.

Watch for changes to attack-class guidance, sandbox requirements, coverage modeling, and false-positive handling. Those updates will reveal which parts of Cloudflare’s process transfer cleanly and which depend on internal systems.

The distinction between confirmed and needs-validation findings deserves particular attention. If outside users regularly promote unresolved leads into confident reports, the workflow’s safeguards will exist only on paper.

The third signal is whether other security platforms adopt similarly independent verification. AI code tools already compete on speed, issue counts, and remediation assistance. Cloudflare is shifting attention toward evidence lineage, rejection rates, and coverage accounting.

That change would strengthen the Cloudflare security audit skill’s broader impact, even if developers never install this specific package. A market that asks who verified a finding is healthier than one that rewards the largest alert count.

Cloudflare’s internal results suggest why this matters. Thousands of raw candidates disappeared during validation, deduplication, and contextual judgment. Generating more candidates was not the scarce capability. Converting them into trustworthy work was.

There are also practical signals inside individual organizations. Security leaders should track how many findings survive independent review, how much coverage grows across repeated runs, and how many patches pass regression tests.

They should also record audit cost and elapsed time. Cloudflare says its internal full scans can take hours, with its longest run exceeding 14 hours. The public skill can consume significant model time as hunters and verifiers examine separate areas.

That expense can be justified for sensitive repositories or periodic deep reviews. It may not suit every pull request. Smaller checks, deterministic rules, and focused threat reviews remain better fits for fast feedback.

The important decision is not whether to replace existing scanners with an agent skill. It is where an evidence-driven agent audit adds information that current controls miss.

Developers can start with one bounded repository and a clearly defined trust boundary. They should inspect the coverage ledger before reading the final report, then challenge every confirmed issue against the untouched source.

They should preserve unresolved records instead of forcing a verdict. They should run tests only inside an appropriate sandbox and keep remediation decisions under human control.

If that process produces repeatable findings that maintainers accept, Cloudflare has released a meaningful security method. If users reduce it to another broad prompt, its six phases will add complexity without trust.

The Cloudflare security audit skill therefore offers a concrete challenge to AI security vendors and engineering teams: stop measuring success by how many weaknesses a model can describe. Measure which claims survive adversarial review, which areas were actually examined, and which facts remain unknown.