# Run an Independent AI Security Audit on Your Own Code (Cloudflare Open-Sourced the Skill)

> Cloudflare open-sourced an agent-neutral security-audit skill. Here is how its six phases work, why a second independent model pass catches what the builder missed, and how to run one on your own repo.

Source: https://playciso.com/blog/run-an-ai-security-audit-on-your-own-code-cloudflare-skill · Published: 2026-10-23 · Publisher: PlayCISO (https://playciso.com)

---

More and more of your code is written with an AI assistant. That is productive, and it creates a quiet problem: the same model that wrote a function is often the one asked to judge whether it is safe. Cloudflare has just open-sourced a way to break that loop, and the underlying practice is worth adopting whether or not you use their tooling. ## What Cloudflare released Cloudflare published [cloudflare/security-audit-skill](https://github.com/cloudflare/security-audit-skill), a public, MIT-licensed security-audit skill that is agent-neutral and independent of any particular harness. It is the single-repository seed of the vulnerability-discovery harness Cloudflare describes in [Build your own vulnerability harness](https://blog.cloudflare.com/build-your-own-vulnerability-harness). Read that post for the full design; this article summarises the parts a security leader can act on. ## The six phases - 1. Reconnaissance. Map the architecture, trust boundaries and input surfaces into architecture.md and a coverage-ledger.json, so the audit knows what exists before it starts hunting. - 2. Coverage-led hunting. Isolated hunter agents work one attack class at a time, while coverage critics look for gaps in what has been examined. - 3. Candidate validation. A fresh, separate verifier agent tries to disprove each candidate. Surviving a hostile second look is what earns a finding its place. - 4. Structured output. Results become confirmed, needs_validation or rejected records in findings.json, validated against a schema. - 5. Independent record verification. The records themselves are checked independently. - 6. Report. A target-neutral REPORT.md summarises the outcome. ## The discipline that makes it useful The most reusable idea is not the pipeline, it is the bar for what counts as a finding. A finding has to name four things: a real trust boundary, a lower-trust principal, the control that was crossed, and a concrete observed result. If you cannot fill in all four, you do not have a vulnerability. That rule separates two things teams constantly confuse. A "missing best practice with no reachable boundary violation" is **hardening**, which is worth doing but belongs in a different queue. Only confirmed findings receive a severity. The **needs_validation** status is reserved for a specific, source-grounded hypothesis that is blocked on a fact outside the source, such as how production is actually configured. It is not a dumping ground for vague suspicion. If you have ever triaged a scanner report with hundreds of rows and no reachable path, you already know why this matters. It is the same reason a good [security metrics](/security-metrics) programme counts validated, exploitable exposure rather than raw alert volume. ## Why a second, independent model pass helps Here is the argument for independence. It is our reasoning about why the pattern works, not a benchmark result, and you should test it on your own code. A model that built a feature carries the assumptions it made while building it. Asked to review its own work in the same session, it tends to confirm those assumptions: the input was "obviously" validated upstream, the caller "would never" pass that value. A different model, running in a different harness with a clean context and a rigorous checklist, does not share those assumptions. It has no sunk cost in the design and is more likely to ask the awkward question. The same logic explains the verifier in phase 3. A separate agent whose only job is to disprove a candidate behaves like a code reviewer who did not write the change. And because the value comes from the process (checklists, isolation, coverage tracking, structured records) rather than raw model capability, a cheaper model following a rigorous checklist can still add a second perspective the original builder lacked. That is what makes this a cheap, repeatable control instead of a one-off consulting engagement. ## What attack classes it covers The skill spans a broad range of classes: - Web and authentication - AI and LLM issues: prompt injection, tool and agent abuse, unsafe output handling - Client-side - Supply chain and release - Cloud and deployment - RPC, messaging and webhooks - Resource exhaustion - Data isolation and lifecycle - Memory safety and binaries - Desktop, mobile and IPC The AI and LLM coverage is the one most teams are missing today. If you ship agents that call tools, our [MCP linter](/tools/mcp-linter) is a quick complementary check on the tool-definition side, and the [labs](/labs) let your team practise the attack patterns safely. ## How to put this into practice - Start with one repo, one branch. Pick a service that handles authentication, untrusted input or money. Run the skill from a clean checkout, using a different model and harness from the one that helped write the code. - Keep the records. The coverage ledger and findings.json are your audit trail. Re-run after significant changes and diff the results. - Triage by the four-part test. Anything lacking a boundary, principal, control and observed result goes to the hardening backlog, not the vulnerability queue. - Treat needs_validation as an action item. Assign someone to establish the missing fact, whether that is a deployment setting, an upstream guarantee or an environment detail. - Layer it with the basics. An AI audit does not replace secret scanning, dependency review or human review of high-risk changes. Run a secret scan alongside it, and browse the rest of the PlayCISO tools for other quick checks. - Handle the output with care. Audit reports describe your weaknesses in plain language. Store them with the access controls you would give a pen-test report, and be cautious about what source code you send to any external model provider. ## Limits to keep in mind AI-driven audits produce leads, not guarantees. A clean report does not prove the absence of vulnerabilities, and models can miss issues or misjudge reachability. The verification phases reduce false positives, but a human who understands your threat model should still review anything that will drive a severity rating, a disclosure or a release decision. Think of this as another independent reviewer on the team, one that never gets tired and costs very little to re-run. ## The takeaway for security leaders As AI writes more of your code, the question to ask in every engineering review is simple: **who checked this, and were they independent of the thing that built it?** An open-source, MIT-licensed, harness-neutral workflow lowers the cost of answering "yes" to nearly zero. Try it on one repository this week, and judge it by what it finds that your builders and your existing tooling did not.