Google has paused new product-vulnerability reports in its open-source bug-bounty programme after a surge in automated submissions. The change leaves other reporting routes intact—and puts the burden of proving an AI-generated finding more firmly on the researcher.
The change took effect on 1 October 2026 under Google’s Open Source Software Vulnerability Reward Program rules. It does not affect outstanding reports or OSS VRP supply-chain reports.
Google’s Bug Hunters team attributed the pause to a “significant rise in automated submissions”, saying the vast majority were invalid. The company plans to rework this part of the programme and provide an update in the first quarter of 2027.
For developers using AI to inspect code, the practical distinction matters: generating a plausible vulnerability report is not the same as demonstrating a security problem another person can reproduce.
What Google has paused—and what remains open
This pauses a particular submission category, not the closure of every Google vulnerability-reward programme.
| Reporting category or milestone | What the announcement means |
|---|---|
| New OSS VRP product-vulnerability reports | No longer accepted from 1 October 2026. |
| Outstanding reports | Not affected by the pause. |
| OSS VRP supply-chain reports | Not affected by the pause. |
| First quarter of 2027 | Google has committed to an update, not a confirmed reopening date. |
Because the restriction applies to the submission category, writing a report manually does not bypass it. Equally, the announcement should not be read as a company-wide ban on AI-assisted security research.
Researchers considering another programme should check that programme’s current scope and acceptance requirements before testing or submitting. A closed route is not permission to send the same out-of-scope claim into a different queue.
Google had already raised the evidence requirements
The October pause follows earlier restrictions. In a March 2026 rules update, subsequently amended in April, Google described rising volumes of AI-generated reports and tightened the evidence required for certain submissions.
For memory-corruption reports affecting its flagship and important project tiers, those changes required reproduction through an existing OSS-Fuzz test target or a merged patch. Google also stopped awarding money or credit for product vulnerabilities in its two lower project tiers.
Google identified two different problems: reports with invented or incorrect explanations, and reports pointing to genuine coding errors with negligible security impact or involving unreachable code paths.
That distinction matters. A model can correctly notice suspicious code without establishing that an attacker can reach it, control the relevant input or cross a security boundary.
The October notice refers to automated submissions, not an AI-only breakdown. It does not establish which models were involved or quantify the review cost attributable to generative AI.
HackerOne and Bugcrowd are tackling the same pressure differently
Google’s announcement does not change either platform’s rules. Both have already described their own responses to low-quality reporting.
In an update published on 2 October, HackerOne recapped changes made earlier in the year. Its April conduct update made researchers responsible for validating AI-assisted findings and prohibited large-scale submission of unverified or low-quality reports. HackerOne also described expanded automated checks against programme scope, policy and previous submissions.
Those checks can close certain reports automatically when confidence is high. HackerOne says lower-confidence flags go to analysts, while researchers can reopen automated closures or seek mediation. This is an attempt to automate parts of verification—not simply prohibit AI.
Bugcrowd’s May announcement described mandatory identity verification for Managed Bug Bounty submissions, restrictions on the number of outstanding submissions from low-performing accounts, and stronger enforcement against submission farming. These measures predate Google’s October pause.
The approaches differ, but the practical message for researchers is consistent: using an automated tool does not transfer responsibility for the report to that tool.
What researchers should include before submitting
Define the affected environment. Identify the repository, version or commit, relevant configuration and necessary permissions. Check the programme’s scope first, and test only in an authorised environment.
Provide reproduction evidence. Supply the smallest practical example that demonstrates the problem, with the steps actually executed and the resulting output-separate observed behaviour from the model’s proposed explanation. Do not present predicted logs or an untested example as a completed test.
Explain realistic impact. Show what an attacker could control, what security boundary would be crossed and which assumptions must hold. A crash, warning or unusual code pattern should not automatically become a claim of account compromise or remote code execution.
HackerOne’s reporting guidance similarly emphasises reproducibility, scope and impact. AI can help organise that evidence, but longer prose does not fill a gap in the underlying research.
The metric maintainers should watch is review effort
DIY AI assesses that report-generation speed is the wrong measure of success on its own. A workflow can make submissions cheaper for the sender while leaving the recipient with more work.
We would evaluate an AI-assisted security workflow using confirmed, actionable findings alongside the human time needed to assess all its submissions—including duplicates and false alarms. “Review minutes per confirmed finding” would be a useful operational measure. It is a proposed metric, not a figure Google has published.
For smaller projects, a sensible starting point is a structured intake form requiring affected versions, reproduction steps, observed output and impact. Duplicate checks and explicit scope rules can support that process, while a human escalation route should remain available for credible reports that do not fit the usual template.
Submitted scripts and attachments should also be treated as untrusted material. Reproduction belongs in an isolated test environment, not a maintainer’s everyday workstation.
For teams comparing AI coding tools and workflows, this adds another evaluation question: does the tool reduce the work required to verify and fix an issue, or merely generate more issues to inspect?
What to watch next
Google’s next substantive update should clarify how this submission category will operate and whether it will reopen. Until then, the confirmed position is a targeted pause, excluding supply-chain and outstanding reports.
The broader lesson is not that AI cannot contribute to security research. It is that a suspected flaw only becomes useful when someone supplies enough evidence to establish what happens, why it matters and how to reproduce it.
