Pimp My IDE / Garage Dispatch
Back to garage
September 19, 2026 | security review / agent harnesses / evidence

A lead is not a finding with worse typography.

Agent security audits can produce more candidates than a human team can absorb. The useful machine is not the one that shouts the most. It is the one that preserves coverage, tries to kill its own claims, and prints a verdict another reviewer can check.

THE TAKE: Keep "confirmed," "needs validation," and "rejected" as different record types. A schema can enforce the shape. An independent verifier must decide whether the evidence supports the state. Neither one proves that an audit covered everything.
Load the Finding Verdict Press

The interesting release is a process, not a prompt.

Cloudflare published the security-audit skill that preceded its larger vulnerability-discovery harness. The repository defines reconnaissance, coverage-led hunting, adversarial candidate validation, structured records, independent record verification, and reporting. It also ships validators for the coverage ledger and findings file.[1]

That matters because security review fails in the handoff. One agent sees a suspicious path. Another sentence turns it into a vulnerability. A severity label arrives before anyone establishes the affected principal, reachable sink, runtime condition, or observed result.

Make the second reviewer hostile to the claim.

The published workflow assigns each candidate to a fresh verifier that did not hunt it. The verifier must reread the cited source, reconstruct preventing controls, and reproduce only the minimum bounded result when local execution is safe. If a deployment fact is still missing, the claim stays in "needs validation." If source or local behavior refutes it, the claim becomes "rejected."[2]

The hunter earns a candidate. The verifier earns the verdict.

This is better than asking the same context window to critique its own momentum. It does not make the reviewer infallible. It creates a clean responsibility boundary and leaves a record when the attractive theory dies.

A schema checks the receipt, not reality.

The repository's JSON schema gives each verdict a different contract. A confirmed record requires a source trace, conditions, execution evidence, remediation, severity, and confidence. A needs-validation record requires the exact blocker and a concrete validation plan. A rejected record keeps the disproved claim and reason without smuggling in severity.[3]

The validator can catch missing fields, impossible line numbers, malformed traces, and incompatible fields. Cloudflare's post states the boundary plainly: schema adherence is not correctness. Mechanical checks protect the shape of the handoff. Independent source review protects the meaning.[4]

Coverage needs its own ledger.

A pile of findings says nothing about the code nobody inspected. The published workflow plans deterministic coverage units and records checked, blocked, deferred, and out-of-scope work. Its authors report that one run found roughly half of the vulnerabilities found across repeated runs in their tests. That is project-reported experience, not a universal benchmark.[1]

Keep candidate state and coverage state separate. A clean verdict on one trace does not close neighboring attack classes. A rejected candidate is useful memory, but it does not certify the subsystem.

Install four pressure switches.

  1. Trace: name the lower-trust entrypoint, every meaningful propagation step, and the boundary effect.
  2. Replay: reproduce the smallest safe result with dummy data and strict sandbox limits.
  3. Independence: use a reviewer who did not write the candidate and is tasked with refuting it.
  4. Impact: identify the affected principal or resource. Do not derive severity from checklist deviation.

If one switch remains open, print the blocker and next check. If a visible control kills the path, retain the rejection so the next run does not rediscover the same ghost.

Interactive makeover / evidence press

Finding Verdict Press.

Traditional purpose replaced: a severity dropdown attached to an untested theory. Better version: close four evidence clamps or mark the claim refuted. The press prints bounded wording and the next unresolved check.

Clamp the record before stamping it

This teaching rig does not inspect source or run a security test. Its status changes only from the controls below.

Evidence clamps
NEEDS VALIDATION

Keep the blocker attached.

The candidate has not cleared every evidence clamp. Record the exact missing fact and a safe validation plan. Do not assign severity.

Why it is better: unresolved work cannot borrow a red badge and severity score. Rejected claims remain useful. Confirmation requires all four visible evidence conditions, but the operator still has to fill the real source, command, environment, and result.
Sources read, not vibes
  1. Cloudflare security-audit-skill repository: six-phase workflow, coverage ledger, candidate states, repeated-run claim, validators, installation, and operating requirements.
  2. Validation and reporting procedure: fresh-verifier role, source and sandbox boundaries, verdict transitions, schema validation, independent final review, and incomplete-run handling.
  3. Findings JSON schema: distinct required and forbidden fields for confirmed, needs-validation, and rejected records.
  4. Cloudflare, "Build your own vulnerability harness," June 18, 2026: skill-to-harness history, adversarial validation, structured output, mechanical-check boundary, repeated-run limits, persistence, and cross-repository orchestration.

Source boundary: all four sources come from Cloudflare's project and describe its design and experience. They do not independently measure detection quality. The four-clamp press and its wording are Pimp My IDE editorial synthesis.