Cloudflare's Security Audit Skill: Check Your Own Code, Keep the Agent Contained

Cloudflare's security audit skill gives a coding agent a disciplined procedure for finding security defects in source code. It suits a small business with a developer who can contain the work and judge the evidence. The biggest risk is letting the agent execute untrusted code or reach systems outside your permission. Try it on code you own inside a properly isolated test environment, with a named human reviewer and a spending limit.

We read the live README, the instructions, every companion reference, both validators and their tests, the report schema (its required data structure) and the license. We did not install or run the skill. This expands the short entry in our November GitHub roundup, with particular attention to what the files actually require.

A procedure binder for your coding agent

A coding agent is an AI assistant that can read files and use tools, such as a terminal, to work on software. A skill is a folder of instructions and helper scripts the agent loads when a task matches. Think of handing a new technician a binder of procedures before sending them to inspect a machine.

Sub-agents are separate AI work sessions assigned smaller jobs by a coordinating agent. Here, some map the code, some look for weaknesses, and others challenge the proposed findings. Separate sessions reduce the temptation to defend an earlier answer, but they are still AI judgments. They do not become independent human experts because they have different task names.

The skill instructions distinguish guidance mode from full audit mode. A focused security question uses relevant guidance. An explicit codebase audit, comprehensive review or request for report files starts the full process. The README includes pen-test the code among its triggers. That wording does not grant permission to test a website.

The README lacks a general authorized-targets-only sentence. The actual skill supplies a much tighter operating boundary: source inspection and contained local checks, with dummy data, no deployed endpoints, no production identities and no external services. Read the instructions before interpreting a short trigger as a capability or a legal permission slip.

Cloudflare's June article about its larger research system says this skill was the starting point for a system spanning multiple repositories. That later system adds persistent task tracking, duplicate removal, production-context review and a patching stage. Installing the published skill does not install that entire operation. The blog describes an earlier seven-phase procedure; the current README and files define six phases. This article follows the current files.

What happens during an audit

A repository is the folder and version history holding a software project. A trust boundary separates things with different permissions, such as one customer's records from another's. A finding is an evidence-backed claim that code lets something cross a boundary it should enforce. A missing precaution alone does not establish that claim.

The workflow is defined in reconnaissance, hunting, and validation and reporting:

1. Map the project. Establish who uses it, where input enters, which checks protect resources, what can be tested locally, and what remains unknown. Write an architecture summary in architecture.md and a coverage ledger in coverage-ledger.json.
2. Assign focused investigations. Give hunters specific ledger units. After their work, a fresh coverage critic looks for missed entry points, unchecked alternate routes and unsupported exclusions.
3. Challenge every candidate. A fresh verifier tries to disprove each distinct suspected defect using current source and bounded local evidence. Duplicate claims about the same underlying defect are consolidated.
4. Write structured records. Store the independently decided results in findings.json, a machine-readable list. Check the required fields and the coverage ledger with the supplied validators.
5. Recheck final claims. Fresh reviewers inspect confirmed and unresolved records. A material replacement, such as stronger impact or a changed cause, needs another independent check.
6. Produce the reports. Derive REPORT.md, FINDINGS-DETAIL.md and NEEDS-VALIDATION.md from those final records for the summary, detailed confirmed findings and unresolved leads. The prose must preserve the verdicts and evidence limits.

The coordinator owns shared records. Each worker gets separate temporary working space. The audit describes the smallest source fix; it does not change the target's source. A developer must take a proposed fix through ordinary review and testing.

The coverage ledger matters as much as the findings

The ledger is an inventory of what was examined. Each unit combines an entry surface, a permission boundary, a subsystem and a relevant attack class. An attack class is simply a family of mistakes, such as trusting a customer-supplied record identifier without checking ownership.

Each unit records its assigned reviewer, source paths, checks, results and unresolved facts. Stable identifiers let later runs compare the same work even when labels change. covered, blocked, deferred and out_of_scope mean different things. A blocked check cannot disappear into a sentence saying the project passed.

The standard profile can run additional investigation waves when the critic finds gaps. A quick profile gets one hunter wave and one final critic pass, with newly found gaps deferred. Deep review adds finer divisions and independent passes over prior coverage. Scoped reviews cover only the selected part. Quick mode combines candidate validation and final-record verification in one fresh independent reviewer; the other profiles keep those passes separate. These profiles change breadth and repetition, while preserving the evidence rules. Profile and budget requirements.

The reference files cover ordinary access checks, input handling and business logic, plus selected areas such as browser code, authentication protocols, cloud configuration, dependencies (other software the project needs) and releases, data isolation, message processing, resource exhaustion, AI tools, native programs and mobile or desktop applications. Selection follows actual trust boundaries in the source. Having a library name in the dependency list does not justify claiming its entire security domain was reviewed. The individual references are linked in the source notes below.

Read the verdict before reading the severity

Confirmed records contain the cause, intended behavior, ordered source trace, evidence, conditions, local reproduction, observed result, remediation, confidence and separately reasoned likelihood and impact. Overall severity cannot exceed demonstrated impact. The schema keeps these fields distinct.

needs_validation has no severity. It needs a source-backed claim, exact blockers and an applicable local or owner-observed validation plan. For example, source may show a risky path whose reachability depends on a deployment setting absent from the repository. The operator can inspect that setting. The agent must not guess or send test traffic to the live deployment. A missing sandbox can also block confirmation.

An untouched candidate is different again. If the budget ends before independent review, the instructions leave it in the ledger, mark the run incomplete and disclose it. They do not permit relabeling every unfinished idea needs_validation to make the report look finished.

What the validators can prove

The findings validator checks the schema and additional consistency rules, including verdict-specific fields, duplicate identifiers, source-path syntax, trace ordering and severity constraints. The ledger validator checks coverage identities, states, evidence ownership and allowed evidence locations. Both impose input limits.

These are programs that check records. They cannot establish that the model understood the code, that its described observation happened, or that an unexamined production setting is safe. The accompanying tests exercise validator behavior; we read those tests without executing them. Passing the validators is a prerequisite for a consistent report. Human evidence review is still required.

Why one run is not enough

The README reports that a single run found roughly half the vulnerabilities found across repeated runs in Cloudflare's tests. That is the project's own observation. It does not mean the skill finds half of every business's bugs, or that two runs find everything. Cloudflare's research article explicitly declines to claim a false-negative rate, meaning a measured proportion of real vulnerabilities it misses.

Repeat work should use prior findings and coverage records. The current instructions require checking whether relevant source and conditions changed, revalidating carried confirmations, and keeping unresolved or previously excluded areas visible. A repeat audit after a payment-flow change should concentrate on changed code and prior gaps, rather than treating yesterday's clean summary as evidence about today's release.

Expect mistakes and omissions. This is not a pentest of your live site, not a compliance certificate, and it misses things. A penetration test is a separately scoped exercise against a system's behavior, usually including its deployed configuration. An insurer's requirement, a customer's questionnaire or a contractual security assessment may demand work this skill does not perform.

Five small business uses, with someone accountable

These illustrations show possible uses. They are not customer stories or measured results. The skill has no license fee under its MIT license, which requires preserving the notice when distributing copies or substantial portions and supplies no warranty. The AI plan, isolation environment and professional review still cost money. The plan prices below are subscription baselines; per-audit quotes are unavailable.

For the WordPress example, paying an invoice alone is not proof of ownership or permission to examine every bundled component. Check the agreement and third-party licenses. For the questionnaire example, attach the reviewed source version and unresolved coverage to the answer. Avoid turning a generated report into a claim that an independent penetration test occurred.

Agents, subscriptions and the size of the bill

The README is agent-neutral: it requires tool use and parallel sub-agents. The Skills documentation and FAQ describe support for agents including Claude Code, Cursor and Windsurf, and list Codex in the ecosystem. Installer support alone does not prove a particular agent can enforce every isolation and delegation rule. Have the technical owner check those capabilities. We did not test compatibility.

These are US dollar list prices before tax, read November 3, 2026. They buy AI access, with usage limits, rather than a guaranteed number of security audits.

Sources: Claude pricing, ChatGPT pricing and official Codex pricing. The Codex documentation supplies the access-surface distinctions and Edu inclusion. The general pricing page lists Pro from $100; the Codex documentation lists its $100, $200 and $500 monthly tiers. Check the selected tier before paying.

A long audit can use a substantial share of a plan's allowance. Anthropic says Claude and Claude Code share limits, and that conversation length, complexity and model choice affect consumption. OpenAI says long-running tasks with more context use significantly more allowance. Neither vendor publishes a fixed price or included run count for this skill. Claude usage limits, Claude Code limits, Codex usage and pricing.

The skill's budget is a count of agent invocations, meaning delegated work sessions, rather than a dollar meter. It reserves reconnaissance, coverage review and candidate verification before assigning hunters. It must disclose an incomplete run if it cannot finish the required validation within a strict budget. Set provider spending controls where available and disable unapproved paid extras: equal numbers of sessions can consume different amounts of model input and output. Budget rules.

Before you install

Give your IT person the repository, the written authorization, a specific source revision (the saved version being reviewed), the chosen agent plan, the spending cap and a named reviewer. Ask them to read the full instructions before installing. The exact project-level command in the README installation section is:

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

The README's user-level alternative is:

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

It also lists npx skills --help for agent selection. These commands reproduce the documentation. We did not run them. npx runs a JavaScript command package; Node.js, which runs JavaScript outside a browser, is also required for the supplied validators. Choose the agent deliberately instead of installing into every detected tool without review.

For an installation with the Skills command tool's optional telemetry, meaning installation-use reporting, disabled, set DISABLE_TELEMETRY=1 in its environment, as its command documentation describes. This switch does not prevent the coding agent from sending material to its AI provider.

A sandbox is an enforced enclosure for a running program, like a locked workshop with only the approved materials inside. A prompt saying “be careful” is not that enclosure. Code under review can contain hostile build steps, tests that contact real services or instructions that try to redirect the agent. Even ordinary code can write to the wrong place when given production credentials.

The execution-safety rules require:

• External networking disabled for target-controlled processes. Any local client/server check uses its own isolated network space.
• An initially empty process environment with only explicitly approved safe values; temporary storage and caches stay inside assigned working space.
• Source and tools exposed read-only, with writes limited to that worker's assigned temporary directory. A disposable source copy is allowed there if a build needs it.
• Explicit limits for processor use, memory, process count, file size, disk use and elapsed time.
• No host credentials, shared services or other workers' storage exposed. Use only dependencies already available locally; target builds must not download them.
• Only minimal, predeclared evidence retained by trusted coordinating code after all target processes stop. That code checks file type, links, paths and size before accepting output.

If any required control is unavailable, do not run target code. Record the exact blocker. This restriction applies to browsers, emulators, tests and processing of fixtures, meaning prepared test inputs, as well as obvious build commands.

The network restriction concerns the code being examined. A cloud coding agent may separately send source excerpts and tool output to its model provider. Have the owner approve that data handling before use; do not assume the audit is entirely offline because its test process is isolated.

By default, full-audit output goes in the user's home folder, under a folder named security-audit-skill, then the repository name and the next unused run-N folder. It stays outside the target repository unless an explicitly selected destination inside it is confirmed ignored by version control. Reports can reveal exploitable details. Restrict access, exclude real secrets and customer records, and decide retention before starting. Output and write-isolation rules.

The Computer Fraud and Abuse Act and other legal risks

This section provides general information. Ask a lawyer for legal advice. Have a lawyer licensed in your state review the proposed scope and authorization before testing someone else's systems.

Reading and testing code you own inside your own isolated sandbox does not involve accessing another person's computer without authorization. The dangerous change happens when an agent follows a connection from that code to a live site, API, cloud account or network you do not own and lack permission to test. An API is an application's doorway for other programs. Owning the program that calls it does not give you permission to attack whatever sits behind that doorway.

The federal Computer Fraud and Abuse Act, 18 U.S.C. § 1030(a)(2)(C), covers obtaining information through specified unauthorized access to a protected computer. Internet-connected business systems can qualify as protected computers. Section (a)(5) addresses damage through several forms of conduct; section (g) also allows civil suits when its conditions are met. A claim that the agent was only checking security does not supply the system owner's permission.

In Van Buren v. United States, the U.S. Supreme Court's 2021 decision, the Court distinguished obtaining information in off-limits computer areas from using information available to you for an improper purpose. Its federal interpretation applies nationally. The majority used the phrase "gates-up-or-down inquiry" on page 13. Footnote 8 expressly left open whether access limits must be technological or can also come from contracts or policies. Treating that opinion as permission to ignore an owner's testing restrictions would go much further than the Court did.

The DOJ policy announced May 19, 2022 tells federal prosecutors to decline cases involving intended, good-faith security research. Its definition requires research aimed at finding or correcting flaws, conducted to avoid harm, with the resulting information primarily used to improve security or safety. Extortion falls outside that description. This guides federal prosecutors; it creates no enforceable right for a defendant and supplies no protection against private civil suits or state cases. It describes good-faith research and does not grant permission to test a stranger's systems. States have their own laws, including California Penal Code § 502 and Texas Penal Code § 33.02. Other countries differ.

Copyright law presents another boundary when testing involves getting around a copyright access control. DMCA § 1201(j) defines security testing to require authorization from the computer's owner or operator. Its exception requires no copyright infringement or other applicable-law violation, including the CFAA. How you use and protect the information matters too.

The separate security research exemption in 37 C.F.R. § 201.40(b)(18) covers qualifying circumvention involving computer programs on lawfully acquired devices or machines, or on systems tested with owner/operator authorization. The purpose must be good-faith security research in an environment designed to avoid harm. Information must primarily promote security or safety and must not be used or maintained to facilitate copyright infringement. The regulation explicitly preserves liability under other laws, including the CFAA. Neither provision is a blanket exemption for anything called an audit.

Contracts can impose additional restrictions. Read your hosting, SaaS (software subscription service) and contractor agreements. For a concrete example, AWS's penetration-testing policy permits customer assessments on listed services without prior approval, but excludes assessment of AWS's own infrastructure or services and prohibits activities including request flooding. A customer cannot expand that permission by signing a letter to a contractor.

A bug bounty program can provide written permission, but only within its terms. Microsoft's bounty guidelines treat policy-compliant research as authorized and explicitly say Microsoft cannot authorize third-party testing. Save the current scope, allowed methods and disclosure rules. An adjacent service, another customer's data or a newly discovered connection can be outside that permission.

Before anyone starts, get authorization from the system owner or a representative who actually has authority to grant it. A helpful staff member's access credentials are not enough. Write down the exact systems and code versions, dates, allowed methods, forbidden actions, emergency contacts, data handling and deletion rules, and the conditions that immediately stop the work. Clarify who can approve a scope change. Stop at an unexpected login, CAPTCHA, paywall, block, cease-and-desist notice or out-of-scope system; do not have the agent work around it. Ordinary reviews of your own code, and properly authorized work within agreed boundaries, are legitimate small-business activities. The paperwork and sandbox keep that boundary clear.

The workflow and its permission checkpoint

┌───────────────────────────────────┐
│ Approved source + dummy test data │
└─────────────────┬─────────────────┘
                  ▼
      Isolated review and checks
                  ▼
       Findings + coverage ledger
                  ▼
        Developer verifies and fixes

Own the systems and rights, or have written permission?
  No → Get written permission first
  Yes ▼
Live testing or unclear authority?
  Yes → Stop and ask a lawyer; scope separately
  No ▼
Required sandbox and data handling ready?
  No → Stop execution; record the missing control
  Yes → Go ahead with logs and human review

Take a signed scope to the technical person

• AI security audit authorization kit (.md): an authorization letter, sandbox checklist, findings triage sheet, setup commands, risk table and use cards.

The useful business outcome is an assigned repair with evidence and a retest. Put a person and a deadline beside each confirmed issue, and a specific information request beside each unresolved lead. Keep the coverage ledger with the source revision so the next reviewer can see what changed.

For a small operator building a product before paying for a larger team, The $97 Launch is about starting with a manageable piece of work. Security review belongs in that piece, with ownership of the follow-through included.

Related reading

• The GitHub repositories small businesses are watching
• REA reverse engineering and legal boundaries
• MoneyPrinterTurbo and safe short-video publishing
• Scrapling and permission-first web data
• Firecrawl for small business web data
• AI agent cost controls for small businesses
• An operating workflow after installing your coding agent

Fact-check notes and sources

All reads were on November 3, 2026, at the UTC times shown. This was a documentation and source review. We did not execute the skill. Business scenarios are illustrations; reviewer fees and per-audit consumption are unknown. Related-reading links and the book link supply editorial context.

• Project overview and install commands: README, 21:34:45.

• Research-system background: Cloudflare research article, 21:35:18: historical workflow, broader system and limits of repeated-run measurements. Its historical counts are not substituted for current instructions.

• License and warranty: LICENSE, 21:35:19.

• AI context and tool authority: AI-AND-LLM.md, 21:35:20.

• General attack classes: ATTACK-CLASSES.md, 21:35:22.

• Browser trust boundaries: CLIENT-SIDE.md, 21:35:23.

• Cloud and deployment controls: CLOUD-AND-DEPLOYMENT.md, 21:35:25.

• Customer separation and data lifecycle: DATA-ISOLATION-AND-LIFECYCLE.md, 21:35:26.

• Desktop, mobile and local communication: DESKTOP-MOBILE-AND-LOCAL-IPC.md, 21:35:28.

• Assignments and coverage critics: HUNTING.md, 21:35:29.

• Native-code safety: MEMORY-SAFETY-AND-BINARY.md, 21:35:31.

• Messages and service communication: PROTOCOLS-RPC-AND-MESSAGING.md, 21:35:32.

• Source mapping and coverage ledger: RECONNAISSANCE.md, 21:35:34.

• Resource limits and availability: RESOURCE-EXHAUSTION-AND-AVAILABILITY.md, 21:35:35.

• Modes, containment, profiles and budgets: SKILL.md, 21:35:37.

• Dependencies and release authority: SUPPLY-CHAIN-AND-RELEASE.md, 21:35:38.

• Verdicts, independent review and reports: VALIDATION-AND-REPORTING.md, 21:35:40.

• Web protocols and authentication: WEB-PROTOCOL-AND-AUTH.md, 21:35:41.

• Required finding fields: report-schema.json, 21:35:43.

• Ledger validator source: validate-coverage-ledger.cjs, 21:35:44.

• Ledger validator test source, not executed: validate-coverage-ledger.test.cjs, 21:35:46.

• Findings validator source: validate-findings.cjs, 21:35:48.

• Findings validator test source, not executed: validate-findings.test.cjs, 21:35:49.

• Agent support and installer behavior: Skills documentation, 21:34:56; FAQ and command reference, 21:35:13. Ecosystem support is not a compatibility test of this skill.

• Prices and allowances: Claude pricing, 21:34:42; official Codex pricing, 21:34:56; ChatGPT pricing, browser-supplied US-view excerpt reviewed 21:44:22; Claude usage limits, 21:35:22; Claude Code limits, 21:35:51. The general pricing page and product documentation have different levels of detail, identified above.

• Federal computer law: 18 U.S.C. § 1030, 21:34:35, particularly (a)(2)(C), (a)(5), (e)(2) and (g); Van Buren opinion, 21:34:35, majority pages 13 to 14 and footnote 8, conclusion page 20; DOJ Justice Manual § 9-48.000, 21:34:36, May 2022 research policy and final no-enforceable-rights paragraph; DOJ announcement, browser-supplied excerpt reviewed 21:41:30, publication date and policy definition.

• Copyright access controls: 17 U.S.C. § 1201, 21:34:36, particularly (j)(1) to (3); Copyright Office regulation, 21:35:19, § 201.40(b)(18)(i) to (iii); current eCFR text, browser-supplied excerpt reviewed 21:41:30, same conditions.

• State examples: California Penal Code § 502, browser-supplied statutory excerpt reviewed 21:41:30, particularly (c)(2), (c)(7) and (e)(1); Texas Penal Code § 33.02, 21:36:22, current rendered chapter and subsection (a).

• Contracts and permission: AWS testing policy, 21:34:36, permitted services and prohibited activities; Microsoft bounty guidelines, 21:35:59, scope and Safe Harbor sections 1 and 2.

This post is informational, not legal advice. Mentions of third parties are nominative fair use. No affiliation or endorsement is implied.