October 23, 2026
When an AI security finding is still unproven
A fuzzer crashes on one build. An API test gets a 200 response with a second account. Both are observations. They may become serious…
By Saroyan Zorayr
1 min read
A fuzzer crashes on one build. An API test gets a 200 response with a second account. Both are observations. They may become serious findings, but an agent that jumps straight to "RCE" or "IDOR" has skipped the handoff another researcher needs.
That handoff can be a compact casefile. I would require six fields before promoting a lead to a finding:
Scope: the specific authorized target, account and permitted actions. Keep the program brief or rules version.
Target: the commit, binary hash or deployed build, plus the relevant environment.
Input: the minimized file or exact request, including role and object ownership. Redact secrets in anything shared publicly.
Observation: the raw response, trace or crash log, not an agent's paraphrase.
Control: what happened with the expected role, another input or an unaffected build. Keep failed hypotheses too.
Retest: the instructions and result from a second pass, ideally by another researcher.
In a pwn lab, this keeps a deterministic crash separate from a demonstrated primitive. In a web pentest, it preserves both test identities and the resource owner behind a suspected authorization bypass. For a bug bounty report, it keeps scope attached to the proof. HackerOne recommends explicit in- and out-of-scope assets; Bugcrowd permits category exclusions for specific targets. An AI workflow should not widen that permission on its own.
Existing skills solve pieces of this. REA's reverse-engineering skill retains evidence IDs and can export bundles. Strix's API skill asks for two tenants and out-of-scope routes before testing. The idea here is a tool-neutral record that can carry those artifacts into a review. It would distinguish observed, inferred and unknown, and reject any finding missing its target or scope.
I have not built or benchmarked this skill. The test I would apply is simple: can a second researcher, within the same permissions, reproduce the recorded observation against the pinned target? If the answer is no or unknown, the casefile should say "unproven."
Sources: HackerOne scope guidance · Bugcrowd scope rules · REA skill · Strix API skill