Turn your AI coding agent into a security auditor

A coding agent writes in one afternoon what used to take a week.

More code. More changes. More of the application exposed.

The capacity to review it, though, has stayed where it was. And code nobody has really read is the perfect place for a security mistake.

Cloudflare has open-sourced a skill that tries to close that gap: security-audit-skill turns a coding agent into a security reviewer that follows a precise process, instead of just glancing at the code.

This guide covers how it works, what sets it apart from a simple scan and what to prepare before you use it.

01. AI writes code. Who checks it?

Asking an agent to "check for security issues" usually produces a generic list: a few valid warnings, plenty of false alarms, no evidence.

The problem is not the model. It is the lack of method:

• the agent looks at a small part of the project and stops;
• it flags everything that looks like a bug, without proving it;
• it judges its own results, and tends to confirm them.

A human reviewer works differently. First they understand how the system is built, then they search methodically, then they verify every hypothesis before it goes into the report. Cloudflare's skill teaches the agent to do the same.

02. A skill for security audits

A skill is a package of instructions a coding agent loads when it needs it. This one is published by Cloudflare under the MIT license and requires an agent that supports tool use and parallel sub-agents.

It installs with a single command:

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

It is not an isolated experiment. According to Cloudflare's blog, a first version of about 450 lines was the starting point of their internal vulnerability discovery system: in about six weeks it grew into a system that continuously scans 128 repositories. On a typical repository of about 30,000 lines it found around 80 distinct bugs; the roughly 10 critical ones were patched in production in about 5 days.

These are numbers from Cloudflare's internal system, not from the public skill used as is. They still give a sense of the method.

03. It does not scan your code: it examines it

A traditional scanner compares code against a list of known patterns. The skill instead has the agent work through six phases, each with a precise job:

1. Reconnaissance
   architecture, trust boundaries, entry points
  ↓
2. Coverage-led hunting
   several agents, each on one part of the system
  ↓
3. Candidate validation
   a fresh agent tries to disprove every hypothesis
  ↓
4. Structured output
   results in a JSON file with a strict schema
  ↓
5. Independent verification
   more agents recheck the final claims
  ↓
6. Report
   readable documents, built only from verified results

Reconnaissance produces a map of the system and a coverage ledger: which parts have been examined and which have not. That is what stops the agent from looking at three files and calling the job done.

04. It knows where to look

Every kind of software has its own weak spots. That is why the skill includes dedicated guides for different attack surfaces:

• web, protocols and authentication: HTTP requests, caching, sessions and login;
• AI and LLMs: prompt injection, misuse of tools and agents, handling of model output;
• client side: DOM injection, cross-window messaging, clickjacking;
• supply chain: dependencies, CI pipelines, signing, updates, plugins;
• cloud and deployment: permissions, infrastructure as code, containers, serverless;
• data isolation: separation between tenants, export, backup, deletion.

There are also guides for protocols and message queues, native code, desktop and mobile apps, and resource exhaustion.

If you read the article on 5 mistakes that make your web app login vulnerable, many of those issues fall under the first item: sessions, authorization, client-side only checks.

05. The agent that finds an issue is not the one that confirms it

This is the most important choice in the whole skill. The agent that spots a possible issue is never the one that validates it.

Hunting agent
  ↓
Candidate
  ↓
Fresh agent trying to prove it wrong
  ↓
Confirmed · Needs validation · Rejected

Every candidate ends up in one of three states:

• confirmed: there is a complete trace through the code and an observed result;
• needs validation: one specific fact is missing, and until it is found the issue gets no severity;
• rejected: the hypothesis has been disproved.

Cloudflare's blog explains why in one blunt line: if an agent is allowed to grade its own homework, it will confidently validate everything it produces. In their internal system, validation even uses a different model from the one that hunts. As the process matured, the share of candidates rejected at validation dropped from 40% to 11%.

There is also a rule about severity: what counts is real impact, not distance from a checklist. A missing extra layer of defense is a hardening note, not a vulnerability.

06. From source code to verified findings

At the end of the audit you get a folder with:

• findings.json: machine-readable results, validated against a schema;
• REPORT.md: the summary;
• FINDINGS-DETAIL.md: details for every confirmed issue;
• NEEDS-VALIDATION.md: the cases that need another check.

The structured format matters: results can be compared across runs, imported into other tools and turned into tasks to fix.

Runs add up. The skill reuses the coverage ledger and previous findings, and according to Cloudflare a single run finds roughly half of the issues that repeated runs uncover.

Before you run it

The skill is powerful, and that is exactly why it needs careful setup.

An isolated environment. To execute the project's code you need a sandbox enforced by the operating system: no external network, a sanitized environment, resource limits, restricted writes. Without these protections the skill does not run the code and leaves the leads as "needs validation".

No secrets within reach. Production keys, real .env files and credentials must not be accessible to the agent during the audit.

The right folder. By default, results are written outside the repository. The skill only writes inside the repository if you explicitly pick a folder that version control ignores.

The cost. A full audit uses many agents and many tokens, especially in the hunting phase. It makes sense to start from one part of the project, such as authentication or the API, rather than the whole codebase.

A human at the end. Even in Cloudflare's system, fixes are never merged automatically: a person reviews every change. A model left free to patch can close a security bug and quietly break an unrelated feature.

Checklist before an audit with an agent

Before asking an agent to check the security of your code, go through at least these five points:

• The code is yours, or you have written authorization to test it.
• The agent works in an isolated environment, with no external network and no real secrets.
• You have picked one part of the project to start from.
• Results go to a folder outside the repository or ignored by git.
• Every proposed fix is reviewed by a person before it is merged.

Review cannot be fully delegated

Coding agents have not made security less important. They have increased the amount of code someone should be reading.

A tool like this does not replace the people who know the system. It takes over the most repetitive part: searching methodically, discarding false alarms, lining up the evidence. Deciding what to fix, and how, is still up to a person.

Sources

• Cloudflare, security-audit-skill on GitHub
• Cloudflare Blog, Build your own vulnerability harness