Blog

AI bug bounty report writing, without invented impact

By the RedRouter Team
October 15, 2026 · Updated November 5, 2026

Use AI bug bounty report writing to turn a verified evidence packet into a readable draft. Don't use it to fill gaps in reproduction or invent impact. Every factual sentence should point back to an observation you can show a triager.

A model can make a weak report sound finished. That's the problem. “Critical account takeover affecting all customers” reads confidently even when the only artifact is one HTTP 200 response from an owned account.

The examples below are fictional and use a local invoice app, two researcher-controlled accounts and synthetic records. They aren't findings to submit. Real testing, external processing and disclosure must follow the current program policy.

polished AI reports still need proof

HackerOne's Quality Reports guidance, dated February 5, 2025, recommends a concise title, detailed reproduction, expected versus actual behavior, impact and supporting material. It also says to check scope before submitting.

Bugcrowd's March 10, 2026 policy on unverified AI submissions makes the researcher responsible for accuracy. These are evidence requirements, not a contest to produce more fluent paragraphs.

Start with the smallest demonstrated boundary crossing. If your evidence shows a cross-tenant read, don't promote it to account takeover. If a prerequisite is unknown, keep it in an unanswered-questions section until you can establish it within scope.

assemble the packet before opening the writing prompt

Keep five groups of material:

1. Permission: saved policy URL, retrieval time, applicable scope text and any explicit approval.
2. Setup: account roles, tenant relationships, synthetic-object creation and sharing state.
3. Baseline: the owner successfully reads its object, with a stable evidence ID.
4. Comparison: the authorized non-owner check and relevant body marker.
5. Controls and limits: fresh-session behavior, contrary observations and what was not tested.

Redact a separate model-facing copy. Preserve enough structure to explain actor, object and boundary without exposing credentials. A cookie isn't needed for a prose editor to understand that the request came from account B.

Don't rely on screenshots alone when exact request fields matter. Conversely, don't replace browser-observed behavior with a model's reading of source code. Attach the evidence appropriate to the claim.

constrain the draft to facts, inference and questions

Write a concise report using this evidence packet only. Label each factual sentence with an evidence ID. Separate observed impact, conditional inference and unanswered questions. Preserve exact request fields from the redacted fixtures. Do not invent CVEs, user counts, severity scores, credentials or additional tests. If reproduction is incomplete, return a missing-evidence list instead of a submission-ready report. Do not submit anything.

An evidence-only prompt helps, but it is not enforcement. Audit the output line by line. If the assistant adds a plausible step that nobody ran, remove it or label it as an untested suggestion outside the reproduction.

YesWeHack's July 17, 2026 lab write-up shows why discovery and validation belong in different states. A model explaining a bug class is not the same as a person reproducing a finding.

before and after: a fictional report excerpt

Bad draft — fictional, unsupported claims deliberately retained:

Critical account takeover lets any attacker access every customer's invoices. The invoice API has no authentication and is almost certainly affected by a known CVE. Changing the invoice ID returns 200, proving complete database exposure. The issue should receive the maximum bounty because it exposes millions of financial records. An attacker could delete invoices and transfer funds. The problem affects every tenant and can be reproduced without an account. A screenshot of the response is attached. Please fix immediately and confirm the payout.

Evidence-bound replacement — fictional:

A signed-in tenant T2 test account read one private invoice created by our tenant T1 test account. The expected rule is tenant isolation, shown in the local lab policy P01. E01 records invoice creation and the synthetic marker LAB-A-ONLY. E02 shows the owner's successful read. E03 shows the same object's marker returned to account B in tenant T2. E04 records a fresh-session repetition with that owned account. The observed impact is cross-tenant disclosure of this synthetic invoice. Anonymous access, write access, account takeover, affected-user count and financial actions were not tested. The attached redacted requests preserve actor labels and object references. No third-party data was collected. Please assess severity under the program's rubric.

The second version is less dramatic and more useful. It tells the reviewer what can be checked and refuses to borrow impact from a different vulnerability class.

audit every consequential sentence

A report can discuss potential consequences, but identify the assumptions behind them. Don't write a hypothetical chain in the same voice as an observation. Suggested remediation is also a suggestion, not proof that you know the root cause.

a complete synthetic report template

Title: T2 test account reads T1 private invoice by object reference
Asset: invoice.example.test — local training fixture
Scope reference: P01, saved policy and retrieval time
Prerequisites:
  Two owned accounts A/T1 and B/T2; separate sessions;
  invoice-A created by A, private sharing state confirmed.
Reproduction:
  1. Create invoice-A with marker LAB-A-ONLY as A [E01].
  2. Read invoice-A as A; preserve owner baseline [E02].
  3. With human approval, perform the same bounded read as B [E03].
  4. Confirm actor and marker using a fresh owned B session [E04].
Expected: B cannot read T1's private object [P01].
Observed: B receives invoice-A and LAB-A-ONLY [E03, E04].
Evidence: redacted request/response pairs, creation record, controls.
Demonstrated impact: cross-tenant read of one synthetic invoice.
Limitations: no enumeration, writes, anonymous access or takeover tested.
Suggested remediation: enforce object-level authorization server-side;
  add regression coverage for owner and non-owner reads.

This template is not a claim about the exact fields in today's authenticated submission form. Use the platform's current interface and program instructions. HackerOne's public guidance supports these content sections; field labels and required inputs can change.

redact without destroying reproducibility

Replace secrets consistently, but don't substitute all object IDs with the same placeholder. Use invoice-A and invoice-B so relationships survive. Remove signed query parameters, session headers, private attachment names and unrelated response rows.

If the program prohibits third-party processing, don't upload the packet to a hosted model at all. RedRouter's zero data retention is opt-in, off by default and free on monthly plans; the policy doesn't grant data-sharing permission. See authorized use, model limits and API setup before choosing a worker.

final review before a human submits

Reproduce from the draft, not from memory. Check every evidence ID, remove guessed severity, verify that attachments contain no credentials and follow the program's disclosure timing. State AI assistance accurately if the program asks; don't invent a universal disclosure rule.

What we still don't know: whether a particular program considers the behavior eligible or what severity it will assign. A writing assistant can't decide either. It can help make the demonstrated behavior clear enough for the program to evaluate.

Sources checked November 5, 2026 (PT). No live finding, model API or submission tested.