From Candidate to Record to Report
In Cloudflare's security-audit skill, finding a plausible path is only the midpoint of a claim. This chapter follows a candidate through independent validation, branch-specific record contracts, executable structural checks, final verification, and target-neutral reporting, so readers can tell what a finished record proves, what it leaves unresolved, and when a correction is too material to apply without another fresh reviewer.
The distinction is necessary because a hunter's write-up is optimized for discovery. It may contain alternative explanations, a promising trace, a local observation, and a proposed severity in one paragraph. A final record has a different job: it must let an owner reconstruct the boundary, reproduce the minimum result safely, understand the conditions, and see why the chosen verdict and fix do not exceed the evidence.
A candidate must survive someone who did not find it
After a hunting wave and its coverage critique, the workflow consolidates candidates by stable fingerprint and root cause. Multiple paths that expose one source-derived cause should not become several copies of the same issue. Distinct missing controls remain separate even when they occur in the same subsystem. A carried prior confirmation is also sent through the current verification path; an old verdict is not allowed to become an unquestioned example for a new run.
Every unique candidate is then given to a fresh verifier that did not hunt it. The verifier's role is adversarial. They re-read every cited source location, check that the first trace entry is a real lower-trust interface, confirm that the last entry is the claimed sink or boundary effect, and reconstruct the strongest source-visible controls on the path. If a local result is decisive and the sandbox permits it, they reproduce only the minimum observed behavior. They do not continue into persistence, broader access, live traffic, or a more dramatic effect.
This separation protects against a subtle failure mode of multi-agent work: agreement can look like evidence when it is only shared context. A second agent that receives the first agent's conclusion may unconsciously improve its wording instead of challenging its premise. The fresh verifier is given the candidate and relevant evidence, but not another verifier's conclusion. They may confirm the complete path, reject it because source or local behavior refutes it, or preserve needs_validation when the decisive fact remains external.
The fingerprint follows the same root cause across those states. That lets the parent merge corrections without losing history. It also prevents a candidate from being promoted merely because its title or severity changed. The identity of the underlying claim stays stable while its evidence state changes.
Three record contracts preserve three kinds of knowledge
The structured output uses three verdict branches. They should be read as contracts, not as positions on a confidence slider.
A confirmed record contains the root cause and intended behavior, a source-relative trace and evidence, relevant conditions, a target-native bounded execution, the observed result, remediation, likelihood, impact, overall severity, and confidence. The trace begins at an entry point and ends at a sink when it has multiple steps. The execution describes the interface the target actually has: an API or message, a library call, a file fixture, a browser action, a rendered policy, or another local harness. It is not required to pretend that every target is an HTTP service.
A confirmed record's severity describes what the evidence demonstrated. Likelihood can reflect reachability and conditions. Impact can reflect the affected resource or principal. Overall severity cannot exceed demonstrated impact.