Cloudflare Security Audit Skill: Setup, Verified Findings, and Pentest Limits

Cloudflare Security Audit Skill gives a coding agent a structured method for auditing a repository: map trust boundaries, investigate candidate defects, independently validate them, and produce machine-readable findings. A useful evaluation must go further than installation. This guide walks through the actual output files, a scoped first-run request, a runnable authorization fixture, and six records exercised against the official report checker.

O official Cloudflare repository describes a skill for multi-phase audits with independently verified, machine-readable findings. That is a more specific proposition than “ask AI to find vulnerabilities.” The workflow organizes evidence and coverage instead of relying on a persuasive final chat response. This article examines the published project and tests its report validator with synthetic fixtures; it does not claim a model benchmark or a complete audit using the skill.

A solo developer can use this distinction immediately. If you own the source and need help investigating authorization, data flow, or a suspicious implementation, a code-oriented workflow can be useful. If your question concerns a deployed gateway, production identity configuration, or an application whose source you cannot inspect, source review alone cannot settle it. Choose the assessment around the fact you need to establish.

What Cloudflare released, and what you still have to supply

Cloudflare’s June 18 explanation of its vulnerability harness distinguishes a reusable skill from a larger scanning architecture. The public skill is a starting point associated with that work, not an installation of Cloudflare’s complete fleet-wide system. Do not transfer claims about an internal research pipeline to your own repository merely because both use the same skill name.

The operational unit is your coding-agent environment. You supply the target source, an appropriate agent and model, an execution environment, and time to review results. A skill can specify how an audit should proceed; it cannot make unavailable tools appear, supply missing deployment facts, or remove a model provider’s usage limits. Installation is therefore the beginning of setup rather than proof that a full audit can run.

The distinctions in this table are an assessment framework, not a performance ranking. They help prevent an expensive category error: buying or building a source-review workflow when the unresolved question is about deployment, or paying for remote testing when a clear source defect can first be reduced to a small local example.

Start by writing a concrete review question. “Can a signed-in user retrieve another tenant’s invoice through this handler?” is more useful than “make my application secure.” It identifies the principal, resource, and boundary that a reviewer must inspect. The broader request can still be appropriate, but it needs a coverage plan rather than an expectation that a single answer represents the whole application.

Install the official skill and verify the installation

The installation command documented by the official project README uses Skills CLI. Run it in the intended development context after reviewing the project and the installer behavior. This is an installation example, not a command executed as part of this article’s research.

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

# Inspect the current CLI options before choosing agent or install scope.
npx skills --help

O Skills CLI documentation is the reference for current command behavior. Choose project or user installation scope deliberately. A developer working on one application may prefer a project-specific setup so the intended context is clear; a broader installation is useful only when you want the skill available across projects. Do not infer the selected scope from an old tutorial or a directory that happens to contain similarly named files.

After installation, verify which skill the agent actually loaded. A successful package command does not prove that a particular agent recognizes the skill, selected the expected copy, or can perform its orchestration. Read the installation result and check the agent’s supported skill-discovery interface. If several copies exist, resolve that ambiguity before interpreting an audit result.

Preserve the skill revision separately from the target revision. The skill is the method; the target is the implementation being examined. Both can change between runs. A later comparison needs to know whether a different result followed a source change, a methodology change, or an execution difference. A model identifier and relevant settings are also useful context when the platform exposes them.

For a repeatable review, record a clean source reference before handing the repository to the agent. These read-only Git commands help establish the target state. They do not run an audit, install dependencies, or verify application behavior. Review any uncommitted changes explicitly instead of treating the commit hash as a complete description of a modified worktree.

# Run inside the repository you own and intend to review.
git rev-parse --show-toplevel
git rev-parse HEAD
git status --short

A clean checkout is convenient, but a dirty worktree is not automatically unusable. It means the assessment needs an exact account of what was reviewed. If the agent proposes a result in a modified file, preserve the relevant content and its relationship to the base revision. A finding that points only to a branch name will become difficult to verify as that branch moves.

Do not start by granting the agent access to every credential and service used by the application. Source inspection and execution have different requirements. An audit can begin by understanding code while unavailable execution capability remains a stated limitation. Expanding access merely to make the workflow appear complete can add risk without improving the evidence for the candidate under investigation.

Check the execution requirements before promising a full audit

The project’s core skill specification separates guidance from a complete audit and places strict conditions on target-controlled execution. Its requirements include isolation, restricted writes and environment, resource limits, and no external networking for such checks. These are requirements of the published workflow, not properties automatically conferred by installing a skill.

Ask your environment a practical question: can it enforce the requested controls at the operating-system boundary? A natural-language instruction to “be careful” is not the same thing. If a test process can reach unrelated files, credentials, or network services, its behavior is not bounded merely because the agent intends to run a unit test. The implementation of the test environment matters.

A repository can contain build scripts and test fixtures whose behavior is more extensive than their names suggest. Before execution, distinguish trusted review tooling from target-controlled code. A command called “test” may still run application hooks or helper processes. The assessment should retain that distinction rather than treating all familiar development commands as equivalent to reading text.

Missing execution capability should narrow the conclusion. A source-grounded candidate can be valuable while the decisive runtime fact remains unavailable. Describe the missing fact and a safe way for the owner to observe it. Do not claim that a candidate was reproduced because the agent read a test file, and do not discard a coherent source trace solely because the current environment cannot execute it.

For a small personal project, the sensible first scope may be one subsystem and source-only review. That is a useful engineering task when labeled accurately. It gives you a bounded set of questions to resolve before attempting more expensive validation. The dangerous alternative is presenting a constrained pass as an unrestricted audit because the user asked a broad question.

Turn a repository into a set of reviewable boundaries

O reconnaissance specification uses architecture and a coverage ledger to organize the work. Its central value is connecting source surfaces to security boundaries and retaining evidence about what was reviewed. A file count alone does not explain whether an important authorization decision received attention.

Think of a multi-tenant application with invoice reads, export jobs, and administrative changes. Those features may share a database helper while crossing different boundaries. Reviewing the helper once does not establish that every caller passes the correct tenant context. Conversely, reviewing every file that imports the helper does not automatically prove that the critical boundary was checked.

A useful coverage entry should tell a future reviewer where the input arrives, which control should constrain it, and what operation can affect another principal or resource. This is an analytical decomposition, not an instruction to create thousands of entries. Granularity should make omitted work visible without obscuring the important paths in bookkeeping.

For an individual developer, begin with the smallest set that matches the application: account identity, object ownership, administrative authority, external input processing, and lifecycle operations that are actually present. Avoid adding an attack class merely because a dependency name suggests it. A coverage plan earns its complexity by explaining a real boundary in the source.

The value of this map appears when a candidate is rejected. If a control earlier on the path blocks the proposed action, the candidate should change state while the reviewed path remains documented. The time spent disproving it is still evidence about coverage. A report containing only surviving findings loses that explanation and encourages the next run to repeat the same investigation.

What the six phases produce in a real review workflow

The useful output of an audit is a set of decisions tied to source and evidence. To understand the implementation, read the workflow specification alongside its companion files. The table below maps the published phases to the operational question each answers; the acceptance tests in the final column are practical review questions rather than additional product features.

A practical reading order starts with the report’s scope and incomplete-work statement, then moves to one important finding and its supporting record. Open the cited source at the reviewed revision before reviewing the proposed repair. Only then inspect the wider ledger for omitted paths. This avoids a common review failure: accepting an impressive executive summary before discovering that its strongest result depends on an unresolved deployment assumption.

The artifacts answer different questions. The architecture summary explains the system; it does not prove coverage. A finding describes one cause; it does not establish that neighboring routes were inspected. The ledger records the review’s population and state; it does not prove that every checked claim is correct. A maintainer should be able to navigate between them without treating any single file as the whole assessment.

For the invoice example, a coverage unit might pair the invoice-read surface with the tenant boundary and an access-control question. An export worker using the same storage helper deserves separate attention if it carries identity differently. The important distinction is not the number of files touched. It is whether the review followed each material way a lower-trust principal could reach the protected resource.

Leia o coverage-ledger specification for the native representation. Its dimensions include surface, boundary, subsystem, and attack class. A useful way to sanity-check that decomposition is to ask whether two entries differ in a security-relevant path or merely use different wording. Artificially splitting identical work inflates apparent coverage; combining different authority paths can hide a gap.

Failure states deserve the same attention as successful ones. If the build could not run, the result should preserve that limitation. If a caller was not inspected, the record should not imply the caller inherits another path’s conclusion. When an investigation is interrupted, a useful partial report tells the next reviewer exactly which question remains. It should not turn unfinished work into a successful empty result.

A bounded first-run request you can adapt

The following is an example request to a compatible coding agent after installing and checking the skill. It is ordinary task language, not an undocumented CLI command. Replace the paths and policy with facts about your own repository. Its value lies in defining an acceptance condition before the review begins.

Use the installed security-audit skill for a scoped review of this owned repository.
Scope: invoice reads and invoice exports under ./src/billing.
Policy: a non-admin user may read or export only their own tenant's invoices.
Record the reviewed commit and any worktree changes.
Map the HTTP handler, background-job context, storage query, and output retrieval.
Keep excluded application surfaces visible as out of scope.
Use synthetic identities and data only.
Do not contact deployed endpoints or external services.
If required execution isolation is unavailable, keep the exact blocker visible.
Return the native report artifacts and distinguish validated findings from blocked work.
Before any target execution, explain which enforced sandbox controls are available.

The scope includes export retrieval because generating a correctly scoped file does not help if another identity can retrieve it afterward. It includes background-job context because an asynchronous job may no longer have the request’s original identity object. These are proposed review questions for the fictional invoice application, not a claim that Cloudflare’s project discovered such a defect.

Do not copy the request while leaving a policy you cannot substantiate. If your product permits a support role to inspect tenant invoices, describe that role and its conditions. Otherwise the agent may report intended support authority as a violation. An audit needs a trusted policy input precisely because implementation alone is not always a reliable statement of intended behavior.

After the run, compare the actual artifacts with the requested scope. If the output contains only a conversational summary, determine whether the environment ran guidance mode, could not create artifacts, or stopped before finishing. If it claims a complete application review, challenge that expansion: the requested scope covered billing paths, not every feature. A precise request is useful only when the result remains faithful to it.

Hands-on validation with the official report checker

For this article revision, we retrieved the official schema, finding validator, and its self-test file, then ran the validator tests and six synthetic records locally. All 34 provided self-tests passed. Three correctly shaped teaching records passed the CLI; three intentionally malformed records failed. This is a test of the reporting machinery and our fixture construction, not a full skill audit, a model benchmark, or evidence about a deployed application’s security.

O official validator e its test suite are the implementation references. Keep the validator and schema from the same reviewed revision. The following commands assume those project files are already available in a trusted local checkout; they do not require an npm dependency installation.

# Replace these paths with your trusted checkout and audit output directories.
# The two findings files below are separate teaching snapshots of one candidate.
node ./skills/security-audit/validate-findings.cjs ./audit/confirmed.json
node ./skills/security-audit/validate-findings.cjs ./audit/needs-validation.json
node ./skills/security-audit/validate-findings.cjs ./audit/rejected.json

# Check a real run's separate coverage claim with its native validator.
node ./skills/security-audit/validate-coverage-ledger.cjs ./audit/coverage-ledger.json

# Exercise the provided findings-validator self-tests.
node --test ./skills/security-audit/validate-findings.test.cjs

The three finding commands were exercised using the fixtures described below. The coverage command is the documented procedure for a real run; no real coverage ledger was generated or validated by our teaching experiment. That distinction matters because a passing finding fixture says nothing about whether a repository’s important boundaries received review.

Our fixture used the invoice demonstration’s actual file and line positions. The entry calls the unsafe helper with Alice and the beta invoice; the sink returns a row without comparing tenants. The blocked snapshot asks a different unresolved question: whether an actual deployed route reaches that helper without another control. The rejected snapshot concerns the controlled wrapper, whose assertion observes a denial. Each file contains one record, so the snapshots do not create duplicate fingerprints in a single document.

[
  {
    "fingerprint": "toy-invoice-read-tenant-boundary",
    "title": "Synthetic invoice helper omits tenant ownership",
    "description": "Educational fixture only: the in-memory helper accepts an invoice identifier belonging to another dummy tenant.",
    "trace": [
      {
        "kind": "entrypoint",
        "file": "authorization_evidence_demo.py",
        "line": 52,
        "scope": "module",
        "description": "The synthetic caller passes inv-b for Alice from tenant alpha."
      },
      {
        "kind": "sink",
        "file": "authorization_evidence_demo.py",
        "line": 16,
        "scope": "vulnerable_read",
        "description": "The toy helper returns the row without checking the user tenant."
      }
    ],
    "evidence": [
      {
        "file": "authorization_evidence_demo.py",
        "line": 16,
        "description": "The return depends only on invoice_id; the user parameter does not constrain the lookup."
      }
    ],
    "verdict": "needs_validation",
    "claimed_root_cause": "A direct caller could omit the tenant ownership control.",
    "blockers": [
      "A deployed route reaching this toy helper has not been established."
    ],
    "validation_plan": {
      "local": "Trace every caller in an owned application and determine where tenant ownership is enforced."
    }
  }
]

The JSON above is a complete native needs_validation teaching record that passed the downloaded validator. It is source-grounded in the synthetic file, while explicitly withholding any production-exposure claim. Copying it into a real report without replacing its trace and evidence would produce misleading content even if the format still passed.

Error counts describe the tested snapshot, not a permanent interface contract. One incorrect field can violate several checks. Automate around the exit status and reviewed schema rather than matching an exact number of messages. Keep the original diagnostic available when investigating failure, and avoid silently deleting inconvenient fields until the checker accepts an inaccurate report.

The severity mutation is particularly useful to understand. A blocked candidate does not become a confirmed high-severity finding by adding a severity object. The record must first satisfy the evidence branch appropriate to its conclusion. The line-zero mutation demonstrates a different boundary: an apparently specific citation can still be structurally invalid. Neither rejection proves that the candidate itself is false; it proves that the submitted record does not meet the checker’s contract.

The impact mutation checks an internal consistency rule. Our educational fixture contains only synthetic, non-secret records and uses low impact within that bounded setting. Raising its overall severity to critical without changing the demonstrated consequence produces a rejected record. A real application’s severity must follow its actual principals, protected data, and consequence, not the label chosen for a toy fixture.

There is a limit the experiment makes visible: the checker can reject impossible structure but cannot independently rerun the authorization scenario. We executed that scenario separately and preserved its assertion output. Source correctness, runtime behavior, schema consistency, and report wording remain distinct checks. The strongest deliverable lets a reviewer inspect all four without mistaking one for the others.

Diagnose the failure at the layer where it occurs

Do not respond to every failure by increasing the token budget. A missing sandbox control is an infrastructure limitation. A malformed verdict is a producer-contract error. An unobserved gateway policy is an evidence gap. More inference may produce a longer explanation while leaving the decisive problem untouched.

For an individual developer, keeping these categories separate reduces wasted effort. Fix installation once, use a reproducible source reference, and test one reviewable boundary. When the blocker moves outside the repository, give it to the person or environment that can observe it. Resume the original record when that fact arrives instead of launching an unrelated full audit.

Read the three verdicts as different evidence states

O validation and reporting contract separates confirmed, needs_validatione rejected. A source-grounded issue with demonstrated consequences is different from a candidate blocked by a missing fact, and both differ from a claim disproved by a control. Uncertainty should change the record rather than disappear inside confident prose.

A developer reading a report should first ask which of those states applies. A candidate that depends on an unknown gateway configuration is not a confirmed production bypass. A missing check in one helper is not necessarily a vulnerability if every reachable caller enforces the required constraint. The point of a verifier is to reconstruct the strongest relevant path, not to endorse the hunter’s first interpretation.

This interpretation does not mean every untested suspicion deserves a finding record. A useful blocked candidate has a coherent source trace and a precise missing fact. “Something may be insecure” is a research question, not an equivalent of a documented boundary hypothesis. Keeping speculative ideas separate protects the developer’s review time.

Severity and certainty also answer different questions. A potentially serious outcome can remain unverified, while a well-demonstrated issue can have limited impact. Do not collapse those dimensions into a red label. A report should let you understand the consequence, the prerequisites, and the strength of the evidence independently enough to make a repair decision.

A rejected result can save more time than a weak confirmation. Suppose a data-access function accepts an arbitrary object identifier but a trusted caller has already bound the request to the authenticated tenant. If that relationship holds on every relevant route, a claim based only on the helper signature is incomplete. Preserve the enforcing control and its reachable path rather than merely writing “false positive.”

The reverse mistake is equally common in review: finding one secure caller and assuming the helper is always protected. Check parallel routes and background jobs before treating the caller as a universal boundary. The coverage map gives those paths a place to live. A finding and a coverage entry are related records, but they should not be used as substitutes for each other.

A runnable offline authorization example

The following demonstration is original teaching code. It is not a Cloudflare test result, does not execute the skill, and does not implement a real application’s API. It models two authenticated users from different tenants and an invoice store containing only dummy data. Everything runs locally in memory with Python 3; there is no server, network request, package installation, or credential.

The boundary is simple: a user may read an invoice only when the invoice belongs to that user’s tenant. The vulnerable function accepts the object identifier without enforcing that relationship. The corrected function checks the relationship at the data-return decision. Save the code as authorization_evidence_demo.py and run it with Python 3.

from dataclasses import dataclass

@dataclass(frozen=True)
class User:
    name: str
    tenant: str

INVOICES = {
    "inv-a": {"tenant": "alpha", "amount": 120},
    "inv-b": {"tenant": "beta", "amount": 240},
}


def vulnerable_read(user, invoice_id):
    # Deliberately incorrect: object existence is not authorization.
    return INVOICES[invoice_id].copy()


def fixed_read(user, invoice_id):
    row = INVOICES.get(invoice_id)
    if row is None or row["tenant"] != user.tenant:
        raise PermissionError("not authorized")
    return row.copy()


def caller_with_control(user, invoice_id):
    # A caller can enforce the boundary before reaching a helper.
    row = INVOICES.get(invoice_id)
    if row is None or row["tenant"] != user.tenant:
        raise PermissionError("not authorized")
    return vulnerable_read(user, invoice_id)


def must_deny(label, operation):
    try:
        operation()
    except PermissionError:
        print(label + ": denied")
    else:
        raise AssertionError(label + ": expected denial")


alice = User("alice", "alpha")
bob = User("bob", "beta")

# Positive control: an owner's normal read works.
assert fixed_read(alice, "inv-a")["amount"] == 120
assert fixed_read(bob, "inv-b")["amount"] == 240
print("owner reads: allowed")

# Minimum dummy effect: demonstrate a cross-tenant read in the toy helper.
leaked = vulnerable_read(alice, "inv-b")
assert leaked["tenant"] == "beta"
print("vulnerable helper: returned another dummy tenant's row")

# Counterexample: a real upstream control can refute a route-level claim.
must_deny("controlled caller", lambda: caller_with_control(alice, "inv-b"))

# Regression checks: repair the direct data-return boundary.
must_deny("fixed helper", lambda: fixed_read(alice, "inv-b"))
must_deny("missing object", lambda: fixed_read(alice, "unknown"))
print("PASS: normal access preserved; cross-tenant access denied")

owner reads: allowed
vulnerable helper: returned another dummy tenant's row
controlled caller: denied
fixed helper: denied
missing object: denied
PASS: normal access preserved; cross-tenant access denied

The first check is a positive control. A repair that denies every request would prevent the unwanted read while also breaking the feature. Confirming legitimate access makes the regression more meaningful. In a real application, positive cases should reflect the intended roles and ownership model rather than merely testing that a function returns something.

The vulnerable call establishes exactly one effect in the toy model: a principal associated with tenant alpha receives a dummy row belonging to tenant beta. It does not establish write access, administrative control, or access to a deployed service. A useful report describes that minimal result before considering broader impact. Do not inflate the observation because the same weakness class can be serious elsewhere.

The controlled caller is the counterexample a reviewer should actively seek. It demonstrates that an unsafe helper can sit behind an effective caller-side check. A claim about that particular controlled route would be refuted by the check, while a claim about the directly reachable unsafe helper remains a separate question. Actual source review must establish which call paths exist and are reachable.

The corrected helper reduces reliance on every caller remembering the policy. That is an engineering choice in this model, not a universal rule that authorization must always be inside a data helper. Real frameworks may centralize policy differently. The invariant is that the last trusted decision before releasing the protected resource must enforce the intended authority on every reachable path.

The missing-object case checks another boundary in the model’s behavior. It confirms that the corrected function does not return data when the identifier is absent. It does not establish whether a real application reveals object existence through timing, status codes, or response wording. Those are different observations requiring a real interface and an authorized test plan.

Use this demonstration to evaluate explanations, not tools. Ask whether an audit result identifies a principal, resource, enforcing control, counterexample, and bounded outcome as clearly as the example. If not, the next step is to improve the evidence. Running a larger model or another broad pass will not automatically repair a vague claim.

What an independent verifier should try to disprove

For a candidate like the toy invoice read, the verifier should begin with the strongest plausible control rather than the most convenient vulnerable-looking line. Is identity derived from a trusted session? Is the object query already tenant-scoped? Does middleware reject the route before the helper runs? Is the proposed input even accepted by the interface being described?

Those questions are adversarial toward the claim, not toward the investigator. The project’s independent validation instructions require checking source and bounded evidence rather than simply accepting another agent’s conclusion. Independence is useful because a second narrative can otherwise inherit the same unsupported premise as the first.

A verifier should also check the stated preconditions against the intended user. An administrator reading an object through an administrative feature may be exercising normal authority. A user operating on their own process may cause only self-impact. Neither observation becomes a cross-boundary vulnerability merely because the action looks powerful in isolation.

When the candidate survives those checks, preserve the result in language a maintainer can reproduce. Include the relevant source path and a minimal dummy fixture or approved observation. Stop at the effect needed to establish the defect. More extensive data collection would add risk and noise without improving the central evidence.

Code audit versus SAST, DAST, and an application pentest

A source-first agent can investigate implementation intent and follow a path across files. A deployed-application assessment can observe how the released system behaves with its actual controls. These perspectives overlap, but their evidence is different. Neither should be sold as a complete replacement for the other without specifying the application, scope, and acceptance criteria.

For this decision, use the terms operationally. SAST refers to analysis of source or related code artifacts without treating a running deployed application as the primary target. DAST examines application behavior through a running interface. A pentest is an authorized assessment with defined objectives and scope; it may combine methods. These descriptions help frame the comparison rather than assign a product to a rigid marketing category.

The most useful difference is often visibility. Source can show a hidden administrative route before a tester knows it exists. Runtime evidence can show a deployment policy the source tree does not contain. A coherent assessment records how those observations relate. It does not force them into a contest where one technique must make the other irrelevant.

Consider an authorization rule supplied by a deployment platform. If the reviewed repository contains the handler but not the platform policy, a source reviewer should identify the missing deployment fact. A tester with approved access to a staging environment can then check the relevant request with dummy identities. The result should return to the source record so the final conclusion reflects both the implementation and its actual enforcement.

The reverse handoff starts from an unexpected response. A tester may establish that one approved identity receives another dummy tenant’s object, but the external result may not reveal why. Source review can distinguish a missing filter from a caller that passes the wrong identity context. That distinction changes the repair and the regression test even when the visible symptom looks identical.

Do not compare workflows solely by how quickly they produce the first alert. A fast candidate that requires hours of triage may be less useful than a slower, bounded finding with a direct repair. Compare the time to an accepted decision: evidence reviewed, consequence understood, repair selected, and verification planned. This article proposes that evaluation criterion; it does not report measured performance for either approach.

Hand off the missing fact instead of repeating the audit

A useful handoff names a question that another environment or owner can answer. “Validate this finding” is too broad. “Determine whether the staging gateway requires an authenticated tenant context before this handler receives a request” identifies the missing control and the relevant observation. It makes the next task smaller and reduces the temptation to restart a broad scan.

Retain the source candidate’s identity through the handoff. If a runtime check resolves the prerequisite, the updated record should explain which fact changed and which evidence supports it. Creating an unrelated new ticket discards the reasoning that led to the test and can leave one team closing an issue while another still describes it as unresolved.

The following JSON is a proposed owner-handoff note for an application team. It is intentionally not a valid Cloudflare findings.json record and must not be presented as one. The example uses a placeholder source revision and a fictional staging environment. Its purpose is to show how to communicate one missing deployment fact without inventing a production exploit result.

{
  "note_type": "owner_validation_handoff",
  "candidate": "invoice-read-tenant-boundary",
  "source_revision": "REPLACE_WITH_REVIEWED_COMMIT",
  "known_fact": "The reviewed handler expects trusted tenant context.",
  "missing_fact": "Whether staging ingress enforces that context on every route.",
  "owner": "Application deployment maintainer",
  "allowed_environment": "Isolated staging with dummy tenants only",
  "expected_evidence": [
    "Deployed artifact identity",
    "Relevant ingress policy revision",
    "Bounded request and response for approved dummy identities"
  ],
  "status": "waiting_for_owner_observation"
}

A good handoff also has a completion condition. If the owner supplies a policy document, decide whether it establishes the deployed state or merely the intended configuration. If the owner supplies a successful denial, retain the request conditions and the tested route. If the owner cannot observe the fact, keep the blocker visible rather than converting silence into either confirmation or rejection.

The amount of runtime testing should follow the missing fact. A question about one gateway rule does not justify testing unrelated accounts, collecting customer records, or expanding into another service. A narrow authorized check can be more decisive than a broad exploratory session because its expected result is clear before the first request is sent.

When your assessment includes both source review and an authorized testing workflow such as Penligent, keep their evidence attached to the same application and build. The product name does not bridge an evidence gap. A source claim and a runtime observation become useful together only when the target, identities, configuration, and acceptance criteria actually match.

What does Cloudflare Security Audit Skill cost?

The project is published under the MIT license, as stated in its official repository. That addresses use of the skill’s code and instructions; it does not make the coding agent, model inference, execution environment, or review time free. There is no single reliable per-repository price that follows from the license.

For planning, separate usage from outcome. A provider bill can tell you how much inference you consumed. It cannot tell you how much meaningful security coverage you obtained. A report with many low-value candidates may cost more to review than a smaller set with stronger evidence. Track both the run’s resource use and the work required to reach an accepted engineering decision.

At a basic level, inference cost depends on the model’s billable input and output usage and its applicable rates. Caching, tool charges, agent subscriptions, and provider billing rules can add complications. Use the current billing documentation for your chosen provider. The arithmetic below is only a planning model and deliberately contains no claim about a vendor’s current prices.

# Illustrative arithmetic only. These rates are invented inputs.
# Replace them with the actual rates and billable units for your provider.
input_tokens = 2_000_000
output_tokens = 200_000
input_rate_per_million = 3.0
output_rate_per_million = 15.0

estimated_inference = (
    input_tokens / 1_000_000 * input_rate_per_million
    + output_tokens / 1_000_000 * output_rate_per_million
)
print(f"Illustrative inference subtotal: ${estimated_inference:.2f}")
# Illustrative inference subtotal: $9.00

The subtotal is not an estimate for Cloudflare’s skill, a particular model, or your repository. It excludes any provider-specific billing behavior and every non-inference cost. Its purpose is to make assumptions explicit. If a proposed budget cannot identify its token assumptions or rate source, it is too vague to support a purchasing decision.

Repository size affects planning but is not a complete predictor. A small authorization subsystem can require careful reasoning across several layers; a large generated directory may add little useful review scope. Prefer a count of meaningful review units and expected validation work over a simple price per line of code. Record why the initial scope is small enough to finish.

Candidate volume can become the expensive part. Every plausible issue needs a decision, and stronger verification may consume additional calls and human attention. Reserving the entire budget for discovery creates an attractive list of unresolved leads without enough resources to validate them. A bounded first pass should preserve capacity for the evidence work that makes its results usable.

A strict spending limit should have a defined stop behavior. Decide which work will be deferred, how incomplete validation will be reported, and which artifacts must be retained before the run begins. A smaller, honestly scoped assessment can be useful. A supposedly complete audit that quietly stops when usage runs out leaves the reader unable to judge its coverage.

Make repeat audits additive rather than repetitive

A second run should begin with changed source and unresolved questions, not with an empty memory of the first. The project’s prior-run guidance connects current review to earlier ledgers while requiring current evidence. An old result can inform planning, but its mere existence does not establish that a changed path remains safe.

In practical terms, preserve the relationship between a finding and its underlying cause. If a function is renamed while the same missing ownership check persists, a new title should not turn the issue into a second independent discovery. If a repair changes the control path, the old confirmation should not be carried forward without checking the new behavior.

Use the same discipline for rejected claims. A prior rejection can prevent wasted investigation when the same control still applies. It should not permanently suppress the path if a refactor removes that control or introduces another caller. The useful history is the reason the claim failed and the source conditions under which that reason was valid.

Coverage gaps also need continuity. If a run did not inspect background jobs, a later run should not treat them as implicitly reviewed because the application name matches. Preserve excluded and deferred work in a form that can become current scope. That makes a sequence of small reviews accumulate understanding instead of accumulating unrelated reports.

A change-based review should state its baseline. A diff is meaningful only relative to a known source state and a defined question. It can help prioritize review effort, but a changed line may rely on unchanged code with the relevant defect. Follow the security path far enough to understand the effect rather than treating the diff boundary as the trust boundary.

Repair the invariant and preserve a useful regression

A source finding earns its place when the maintainer can identify the invariant the code must enforce. In the toy example, that invariant is the relationship between the requesting tenant and the returned invoice. The repair should make that relationship hold at the relevant decision point. A generic recommendation to “sanitize input” would not address the authorization failure.

Choose the smallest effective change after reviewing the application’s policy architecture. Sometimes the correct repair is a tenant-scoped query. Sometimes it is fixing the trusted identity passed by a caller. Sometimes the helper should reject an operation it cannot authorize. The right choice depends on which layer owns the policy and which paths can reach the operation.

A regression case should preserve the original boundary question without preserving unnecessary exploit complexity. Use dummy identities and a minimal protected resource. Include an allowed operation and a denied operation so the test distinguishes a repaired boundary from a disabled feature. Keep the expected outcome explicit enough that a future refactor cannot accidentally weaken it while keeping the test green.

Review the test’s relationship to the deployed interface. A helper-level test establishes behavior at that helper. It does not establish that a route passes the correct identity, that a job retains its tenant context, or that the released build contains the repair. Add integration or deployment checks where those facts matter, and identify which layer each check covers.

The repair record should also state what was not tested. If only reads were examined, do not imply that updates and exports received equivalent validation. If a deployment policy remains unknown, keep that question open even after improving the source. A precise repair can be complete for one finding while the broader assessment remains partial.

Keep evidence files inside the trust model

An audit artifact is not automatically trustworthy because a tool wrote it. A test can produce a log that contains application-controlled strings, and a source file can contain instructions aimed at the reviewer. Read those materials as evidence about the target, not as authority to change the audit’s scope, grant access, or run another command. The same boundary applies when an agent summarizes them.

A useful artifact should have a narrow purpose. For the toy authorization check, a short assertion result and the exact teaching program are sufficient. A complete environment dump would add unrelated information without strengthening the demonstrated boundary. Prefer minimal records that preserve the input, expected policy, observed result, and source identity needed to reconstruct the decision.

Separate temporary execution output from retained evidence. Before preserving a file, establish that it is the expected regular artifact, belongs to the intended check, and contains no unrelated sensitive data. This is a general evidence-handling recommendation; the project’s own retention and validation rules remain the authority for a real skill run. A familiar filename does not establish those properties by itself.

Link the retained evidence to the specific conclusion it supports. A passing test can support one regression invariant; a source excerpt can support an implementation trace; a deployment record can support a released build identity. None should be attached as an undifferentiated bundle that supposedly proves the entire report. Clear attribution makes both review and later correction less expensive.

Finally, preserve the distinction between an observation and a generated explanation of it. If a model says a test returned another tenant’s record, the reviewer should be able to inspect the bounded test result that supports that sentence. If that artifact is missing, the explanation is a claim requiring verification. Keeping the two separate is essential when reports move from an agent session into an issue tracker or a customer deliverable.

Use CI as a controlled consumer of evidence

Integrating an agent-assisted audit with continuous integration introduces a policy question: which results should block a change? A candidate count is a poor gate because the count can rise when coverage improves or when a model produces more speculation. A better starting point is a reviewed severity policy applied to evidence states the team understands.

Begin in a reporting mode for a bounded subsystem before making the output a release blocker. Compare generated records with maintainer decisions. Track which issues were accepted, rejected, or returned for more evidence and why. This gives the team a calibration dataset without pretending that a new workflow is ready to make every release decision autonomously.

Keep audit infrastructure separate from target-controlled execution. The job that reads trusted configuration and publishes an internal report should not inherit arbitrary behavior from the repository under review. Review the platform’s actual isolation and credential handling before enabling target tests. A CI label does not itself define a security boundary.

Output validation should happen before downstream automation consumes the record. A malformed record should fail clearly rather than be repaired by guessing the missing meaning. Even a well-formed record may require human judgment before it becomes a customer-facing statement or an urgent release stop. Treat the report as evidence input to policy, not as a substitute for policy.

Preserve run identity in the issue tracker. If a record changes after verification, the tracker should not retain a stale severity or description beside the new artifact. Avoid creating a fresh ticket for every rerun when the underlying cause is unchanged. Good integration reduces repeated triage; it does not simply make a larger queue arrive faster.

Frequently asked questions

What is Cloudflare Security Audit Skill?

• It is an open-source coding-agent skill for structured source-oriented security review. The official repository is the starting point for current installation instructions and project requirements. Installing it does not mean that an application has completed an audit.

Is it Cloudflare’s complete vulnerability harness?

• No. Cloudflare’s harness article distinguishes the released starting skill from a larger scanning architecture. Your local environment, orchestration, evidence handling, and review process still determine what you can run and substantiate.

Can it replace a pentest of my deployed application?

• Do not assume that. Source review and running-application testing establish different facts. Use source analysis for implementation paths and authorized runtime checks for deployment-dependent behavior. Match the method to the question and retain the limitations of each result.

Is the skill free to use?

• The project is MIT-licensed. Model usage, an agent subscription, execution infrastructure, and review time can still cost money. No universal per-repository cost is established here. Plan around your chosen provider’s current billing rules and the scope you can finish.

What should I do with a needs_validation result?

• Identify the exact missing fact and assign it to an owner who can observe it safely. Do not treat the label as confirmed exposure or automatically discard it as noise. Keep the evidence and the completion condition attached to the candidate.

Does a valid findings.json prove that the findings are correct?

• No. The project’s validation guidance distinguishes record consistency from the correctness of source and execution claims. A reviewer still needs to inspect the path, conditions, and bounded observed result.

Can I run the example without installing the skill?

• Yes. The Python example uses only the standard library and synthetic in-memory data. It demonstrates authorization evidence and counterexamples; it is not a security-audit-skill run, a real application’s exploit, or a product performance test.

What is a sensible first task for an individual developer?

• Choose one owned subsystem with a clear protected resource and intended authority rule. Record the source revision, define the review question, and preserve capacity to validate candidates. Expand after the first pass produces a decision you can inspect and act on.

Start with one boundary and finish its evidence

Cloudflare Security Audit Skill is most useful to evaluate as a method for turning source investigation into reviewable decisions. Choose a boundary, establish the reviewed source, challenge the candidate, and retain the exact result. If the decisive fact lives in deployment, hand that fact to an authorized runtime check. The result should be an evidence trail an application owner can use, with unresolved work still visible.

The following Penligent video illustrates a general testing workflow. It is not a demonstration of Cloudflare’s skill, a head-to-head comparison, or evidence that either workflow discovers a particular defect.