Sceptical Security Report Triage Gate
You get a clear verdict on a security report, a record of what the reporter actually proved, and a short list of safe checks to run next. It works because the AI must separate evidence from assumption and test scope and duplicates before judging impact.
Struggled in our testThe analysis is sound and covers all five steps with a sensible "Needs more evidence" verdict. But it runs to roughly 380 words against a 250-word limit, and it adds long prose sections for steps 2–4 between the table and the bullets, so it departs from the requested output format.
The prompt
Act as a sceptical application security triager reviewing a report about a system our company owns.
Task: Decide whether the finding below is real, in scope and new, using only the evidence given. Do not assume anything the report fails to show.
Report: {finding_report}
Authorised scope: {authorised_scope}
Known issues already logged: {known_issues}
Steps:
1. Restate the claim in one sentence, then list each piece of evidence offered and mark it as shown, implied or missing.
2. Check the affected asset against the authorised scope and note any mismatch.
3. Compare the claim with the known issues and flag likely duplicates.
4. Rate realistic impact for an ordinary user, naming what an attacker would need first.
5. List the smallest safe, non-destructive checks our team could run to confirm it.
Output:
A verdict (Valid, Needs more evidence, Duplicate, Out of scope or Invalid) with one line of reasoning, then a short table of evidence and its status, then the safe checks as bullets. Keep it under 250 words.
Change the parts in curly braces. Use it when your inbox or bug bounty queue fills with reports and you need a consistent first pass before an engineer spends time on each one.
What happened when we ran it
We sent
Act as a sceptical application security triager reviewing a report about a system our company owns. Task: Decide whether the finding below is real, in scope and new, using only the evidence given. Do not assume anything the report fails to show. Report: The invoice download link at app.example-shop.co.uk/invoices/download?id=10482 returns a PDF without checking who is logged in. The reporter says changing the id to 10483 showed another customer's invoice. They attached one screenshot of a PDF with a blurred name and said it works on every invoice. No request logs or test account details were included. Authorised scope: In scope: app.example-shop.co.uk and api.example-shop.co.uk. Out of scope: blog.example-shop.co.uk, third-party payment pages, denial of service, social engineering, and any testing against real customer accounts. Known issues already logged: Ticket SEC-212: invoice endpoint lacks rate limiting (open). Ticket SEC-198: outdated JavaScript library on the login page (fixed). Ticket SEC-230: session cookies missing the SameSite attribute (open). Steps: 1. Restate the claim in one sentence, then list each piece of evidence offered and mark it as shown, implied or missing. 2. Check the affected asset against the authorised scope and note any mismatch. 3. Compare the claim with the known issues and flag likely duplicates. 4. Rate realistic impact for an ordinary user, naming what an attacker would need first. 5. List the smallest safe, non-destructive checks our team could run to confirm it. Output: A verdict (Valid, Needs more evidence, Duplicate, Out of scope or Invalid) with one line of reasoning, then a short table of evidence and its status, then the safe checks as bullets. Keep it under 250 words.
The model replied
**Verdict: Needs more evidence.** An IDOR on an in-scope asset is plausible and high-impact, but the report shows no proof that the PDF was another customer's data or that authentication was absent.
**1. Claim:** The invoice download endpoint serves any invoice by sequential id with no authorisation check, exposing other customers' invoices.
| Evidence | Status |
|---|---|
| Endpoint URL and id parameter | Shown |
| Changing id 10482→10483 returned a different invoice | Implied (screenshot only) |
| Invoice belongs to another customer | Implied (name blurred, so unverifiable) |
| "No login check" (unauthenticated access) | Missing (no logged-out request shown) |
| "Works on every invoice" | Missing (one sample only) |
| Request/response logs, test account details | Missing |
| Whether 10483 was the reporter's own invoice | Missing |
**2. Scope:** app.example-shop.co.uk is in scope. However, the reporter viewed what they say is a real customer's invoice, and testing against real customer accounts is out of scope. The report doesn't say whether a test account was used, so a possible rule breach needs raising with them.
**3. Duplicates:** SEC-212 (no rate limiting on the invoice endpoint) is related but distinct: it covers brute-force volume, not missing authorisation. SEC-198 and SEC-230 don't apply. This is not a duplicate, though fixing SEC-212 alone wouldn't resolve it.
**4. Impact:** If confirmed, high. Invoices likely contain names, addresses and purchase history. An attacker needs only a valid URL (and possibly any account), and sequential ids make enumeration trivial. Whether login is required is unknown.
**5. Safe checks (own test accounts only):**
- Create two test accounts with one invoice each. While logged in as A, request B's invoice id and check for 403/404 versus 200.
- Request A's invoice in a logged-out session or with no cookie.
- Review server logs for the reporter's requests around 10482/10483 and any sequential access pattern.
- Check the code for an ownership check on the download handler.
- Ask the reporter for the request/response and whether real customer data was accessed.
Run on Claude Sonnet 5.5, 02 Nov 2026. Automatic check: 2 out of 5.
Where it came from
Found on GitHub, shared by mdpsec: mdpsec/bug-bounty-hunting-prompts.
This is our own version of the idea, written and tested by us. The original may differ.