What Counts as a Vulnerability?
For Cloudflare's security-audit skill, the central question is not whether a reviewer can point to code that looks unsafe. It is whether a lower-trust actor can cross an intended security boundary and produce a meaningful result, and whether the available evidence is strong enough to say so. This distinction gives readers a practical way to classify a candidate by its principal, control, result, and limits before anyone assigns it a severity.
The difference matters because software is full of decisions that are imperfect without being exploitable. A second authorization check may be missing even though the first one is decisive. A parser may accept an unusual value but safely reject it before a dangerous operation. A service may have a broad permission in principle while no untrusted input can select the protected resource. Conversely, a short path that looks ordinary may let one tenant read another tenant's data. Surface appearance is a poor substitute for a boundary analysis.
The five questions behind a meaningful claim
A useful security claim can be reconstructed as a chain of five questions. The questions are simple enough for a non-specialist to use, but each rules out a common form of overstatement.
Who is acting, and what authority do they start with? The reviewer must name the lower-trust principal rather than use “attacker” as an all-purpose label. The principal could be an unauthenticated caller, an ordinary account, a tenant with limited membership, a contributor-controlled workflow event, an untrusted document, a browser origin, a local application, or a message producer. In a model-mediated system, it might be content that the model can read but that the product did not intend to treat as policy. The starting capability matters because security is relative to authority. An action available to a user on their own resource is not privilege escalation merely because the same verb would be sensitive on someone else's resource.
What exact value, action, or transition is accepted? Vague claims such as “the input is dangerous” hide the actual mechanism. The relevant input might be an object identifier, a callback URL, a message field, a file path, a tool argument, a workflow parameter, a role selector, or a quantity. Sometimes the important input is not a value but a transition: enrolling a second factor, restoring a deleted record, consuming a one-time token, or approving a particular side effect. The reviewer must describe the operation the system accepts, including the path by which it arrives.
Which control should bind, reject, isolate, limit, or revoke it? A security boundary is implemented through a decision. It may be an ownership check, a tenant predicate, a signature and audience check, an origin allowlist, a peer credential, a quota, a confirmation binding, a parser limit, or a lifecycle condition. The right question is not only whether some check exists. It is whether the check protects the same resource and action, uses the right principal, and runs after the relevant value has been normalized. A route that checks authentication but not ownership has a different control failure from a route that checks ownership on the initial request but not on a queued retry.
What boundary is crossed, and who or what is affected? The affected party may be another user, tenant, workload, process, release channel, shared worker pool, or operator-owned resource. This is where the analysis separates self-impact from a security consequence. A user who can make their own process spend more CPU has not necessarily created a service availability vulnerability. A workflow that can modify its own temporary artifact has not necessarily gained release authority. A model producing a command is not itself a security issue unless the command reaches a capability, resource, or principal that the requester did not have or did not intend to use.
What concrete result can be observed? The result might be an unauthorized record read or update, an unrequested action under another principal's authority, a private response served to the wrong account, an unsafe image load, a secret disclosure, a process-integrity effect, or a bounded shared-resource impact. The result must be as strong as the evidence. A crash proves a crash unless a safe local check establishes a stronger effect. A timing difference is not automatically a confidential-state oracle. A missing header is not automatically an exploit. The skill asks the reviewer to stop at the smallest result that settles the invariant.
These questions also reveal why a source trace matters. A candidate needs more than a dangerous sink and more than a plausible story. The trace should begin at a real lower-trust entry point, follow the relevant transformations and checks, and end at the operation or boundary effect. If an intermediate prerequisite is missing—perhaps the source path is not reachable in the active deployment—the claim must retain that limitation instead of silently assuming it.
Not every missing control is a vulnerability
The skill draws a firm line between a security failure and a defense-in-depth gap. Suppose an application has two layers that both appear to restrict an operation. If the first layer reliably prevents a lower-trust caller from reaching the protected state, the absence of the second layer may deserve a hardening note. It is not automatically a confirmed vulnerability. Calling every missing safeguard a finding would blur the difference between “the system can be attacked” and “the system would be more resilient with another barrier.”
The same discipline applies to code that appears permissive in isolation. A loader may accept a plugin path, but the result depends on who can write that path and whose process loads it. A function may accept a tenant identifier, but the identifier may be compared against an authenticated tenant before any query runs. A tool may use a shared service identity, but its handler may enforce the requester's permission on every named resource. The reviewer has to follow the authority to the point where the protected operation occurs.
This is why the skill's ordinary attack guidance asks reviewers to check parallel routes, batch operations, retries, legacy paths, error handling, and stored or derived copies. A control on the polished path does not protect a sibling path that produces the same effect. At the same time, a visually unusual path is not a finding if the strongest relevant control still applies. The security claim lives in the relationship among entry, control, boundary, and result—not in the novelty of the code.
Three evidence states, not one confidence slider
Once the five questions have been answered, the skill uses three distinct verdicts. They are not merely “high,” “medium,” and “low” confidence. Each one describes a different state of knowledge and permits a different kind of communication.
A confirmed record means that the source path and a bounded local result establish a meaningful boundary failure. The record includes the root cause and intended behavior, an ordered trace, supporting evidence, relevant conditions, a target-native reproduction, the observed result, a remediation strategy, and calibrated severity and confidence. The reproduction is deliberately narrow. A dummy tenant, a small fixture, a local function call, a rendered policy, or an isolated loopback service may be enough. The point is to establish the invariant's failure, not to expand the effect into persistence, broader data access, or service disruption.
A needs-validation record means that the source-grounded hypothesis is specific but a decisive fact remains outside safe local observation. The record must say what the blocker is and how an owner can resolve it through a bounded local or deployment check. Consider a backend that appears to trust a forwarded identity header. The source may show the trust decision, but the repository may not show whether a tightly controlled ingress strips client-supplied copies or whether a direct backend route exists. Declaring a confirmed bypass would assume the missing topology. Declaring the code safe would assume the opposite. needs_validation preserves the exact question: which peer can supply the header, which route is active, and which identity reaches authorization?
This state is not a weak vulnerability with a small severity. It has no severity because the impact has not been established. It is also not a parking place for any interesting thought. A speculative concern with no complete source trace, no concrete boundary, or no applicable validation plan should be rejected or recorded as a hardening issue, not dressed up as an unresolved finding.
A rejected record retains a source-grounded claim that validation disproved. The reason might be a visible authorization wrapper, an impossible prerequisite, a safe parser rejection, or a result that never crosses the stated boundary. Preserving the rejected claim helps a later run avoid repeating the same unsupported explanation while leaving the broader coverage area open to different evidence. Rejection is therefore useful negative knowledge, not an embarrassment to hide.
The separation prevents a common reporting error: using a severity label to stand in for certainty. A serious possible impact can make a lead worth validating urgently, but urgency does not make the lead confirmed. The workflow gives severity only to confirmed records, and overall severity cannot exceed the demonstrated impact. Likelihood and impact must describe the conditions that were actually established, not the worst scenario that can be imagined from the code.
Authorization and safety come before ambition
The classification boundary begins even earlier than the source trace. The skill distinguishes a focused guidance request from a full audit. Guidance mode can address a security question or a narrow review without automatically creating a complete set of artifacts or running every phase. Full audit mode is reserved for an explicit audit, penetration test, comprehensive review, or requested report output. If the request could mean either, the stated rule is to clarify before broad orchestration starts.
That gate protects the meaning of the result. A methodology does not authorize access to a target, and a question about a vulnerability does not automatically authorize a fleet of agents, target-controlled processes, or a formal-looking report. When a full audit is authorized, the workflow still requires all stages to reach either a complete terminal state or an explicitly incomplete one. It does not let an unfinished process borrow the appearance of completion.
Execution safety is part of evidence quality. The skill allows source inspection, but target-controlled builds, tests, processes, browsers, emulators, and fixture processing must run inside an OS-enforced sandbox. The specified controls include no external network, an empty allowlisted environment, read-only target and toolchain access, writes limited to assigned scratch space, and explicit resource and time limits. Real credentials, production data, live endpoints, shared infrastructure, publishing, stress, and paid services are outside the boundary.
If those controls cannot be enforced, the correct response is not to run a smaller live test. The lead remains needs_validation, with the missing capability named and a safe owner-observed or local plan supplied. This is a practical expression of the evidence rule: an unsafe demonstration is not better evidence merely because it produces a more dramatic result.
The result is a useful discipline for readers who must decide what to do next. First ask whether the claim names a real principal, accepted action, intended control, affected boundary, and observable result. Then ask whether source evidence establishes the path, whether a bounded local check establishes the behavior, and whether an external fact still controls reachability or impact. Only after those questions are answered should priority enter the conversation.
That order leads naturally to the next task: mapping the system in which the claim would live. Before an agent can decide whether a boundary was crossed, it must know which principals, resources, entry surfaces, copies, controls, and deployment facts make that boundary real.