Do not ban AI tools in your policy. Ask for what makes any report useful: a working reproduction, a clear statement of impact, and the reporter's own words. One widely used open source project asks reporters to write "in your own human voice" and not paste massive AI-generated explanations. Judge the evidence, not the tool.
What curl asks of reporters
The curl project's security page covers this in a short passage about writing style. It asks contributors to explain issues briefly and clearly in their own human voice, and not lazily paste massive AI-generated explanations, noting that clear writing reduces maintainers' daily burden. The page does not set a penalty or require disclosure of AI use. It says reports go to a platform where a team member acknowledges them, accepts or rejects each, and writes to the reporter with reasons if rejected. It also says all reports, valid or not, should be disclosed and made public, and that the project offers no bounty.
Treat that as one project's choice, not a standard.
What problem you are solving
A low quality report costs your team time whether a person or a model wrote it. The usual signs are a vague description, a function name that does not exist, no steps, and an impact claim far beyond the evidence. Your policy can address those directly.
Wording you can add
- Ask for a minimal reproduction: exact version, exact steps, exact output.
- Ask the reporter to confirm they ran it themselves against a current release.
- Ask for a short impact statement in their own words.
- Say that reports lacking a reproduction may be closed with a request for more detail.
- Say how you treat repeated unverified reports, for example by lowering response priority.
Triage steps for suspect reports
| Check | Why |
|---|---|
| Does the named file and function exist | Models sometimes invent code paths |
| Can you reproduce in five minutes | A real flaw usually reproduces |
| Is the attacker position realistic | Many claims need access the attacker already has |
| Is the version current | Old versions waste time |
Reply politely every time. A short note asking for steps costs little and treats the human behind it fairly. See handling duplicate and out of scope reports and the first reply template.
Do not forget the opposite case
Some real findings come from AI assisted research. A good report is a good report. Accept it, validate it yourself, and credit it accurately, as in AI-found vulnerabilities and credit.
Quick check
Should a policy forbid AI-assisted reports?
Usually not. Require evidence and a reproduction so quality is judged, whoever or whatever drafted the text.
What is the fastest way to spot a bad report?
Try to reproduce it against a current release. If the named code path does not exist, say so and ask for steps.
Safeguard's policies and guardrails govern AI tooling in your own pipelines, and you can run a free scan on your code.
Sources
Last reviewed: 19 October 2026.
