How to Report a Security Bug You Found With AI
Reproduce the bug yourself, use the project's official security channel, and write a report a stranger can verify in ten minutes. Includes a template.
Reproduce the bug yourself before you report it, send it through the project's official security channel, and write the report so a stranger can confirm it in about ten minutes. An AI model can help you find and describe a flaw, but it cannot vouch for it. Reports that skip the reproduction step are the kind that just led Google to pause part of its open source bug bounty.
Step 1: Reproduce it yourself
A model saying "this code is vulnerable" is a lead, not evidence. Evidence is you running a specific input against a copy of the software and seeing the failure. If you cannot do that, you do not have a report yet, you have a suspicion. Ask the model for a minimal test, run it, and note exactly what happened.
Step 2: Only test what you are allowed to test
Run your tests against a local install or a copy you own. Do not probe somebody's live service, and do not touch data that is not yours. If a bounty programme exists, read its policy for scope and for any safe-harbour language before you test anything.
Step 3: Find the right channel
Look for a
SECURITY.mdfile in the repository, or asecurity.txton the website.Check whether the vendor runs a bounty or reporting programme. What an AI bug bounty program is explains how they work.
Report privately. A public issue tells attackers before the fix exists.
If a vendor will not respond, CISA runs a coordination process. See CISA's coordinated vulnerability disclosure page.
Step 4: Write the report
Keep it short and concrete. This template covers what a maintainer needs.
Summary: one sentence on what is wrong and where.
Affected version: exact version or commit you tested.
Steps to reproduce:
1. ...
2. ...
Expected result: what should happen.
Actual result: what happened, with the exact output.
Impact: what an attacker could do, in one sentence.
Environment: OS, runtime, configuration.
How AI was used: for example, found with a model, then reproduced by hand.Step 5: Say how AI was used
One honest line is enough. Maintainers now triage reports knowing some are model output, and a note saying you reproduced the issue by hand moves yours up the pile. Do not paste a chat transcript as proof.
Step 6: Give them time
Agree a timeline with the maintainer. If a vendor is unresponsive, CISA says it may disclose a vulnerability as early as 45 days after the first attempt to contact the vendor. Treat that as a reference point, not a rule for your own report.
Weak report or strong report
Weak | Strong |
|---|---|
"The model says this is a critical SQL injection" | "This request returns another user's record, steps below" |
No version | Exact version or commit |
Pasted chat log | Minimal reproduction |
Several unrelated issues in one message | One issue per report |
Severity guessed at 10 out of 10 | Impact described in one plain sentence |
If the fix is yours to make, a bug report for your own coding agent follows similar rules. For a CVE number and what the severity score means, see what a CVE is, and for the limits of AI bug-finding, can AI find security vulnerabilities in your code. The wider category is in the AI risks guide.
Frequently asked questions
Should I tell the maintainer an AI found the bug?
Yes. It costs nothing and sets accurate expectations. The thing that earns trust is that you reproduced it yourself.
Do I need a CVE number to report?
No. Report first. A CVE can be requested later, usually by the maintainer or the vendor.
Can I get paid for a bug found with AI?
That depends on the programme's scope and rules. Some are paused or restricted, as Google's open source programme now is for new product reports.
What if nobody replies?
Follow up after a reasonable gap, then consider a coordinator such as CISA. Do not post the details publicly while the flaw is unfixed.
How did this land?
About the author

Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.


