For years, the basic economics of bug bounty programs were straightforward. Security researchers spent scarce human time searching for vulnerabilities, organizations paid for the relatively small subset of findings that turned out to be real, and triage teams absorbed the cost of separating useful reports from noise. Artificial intelligence has begun to overturn that balance.
On October 1, 2026, Google temporarily stopped accepting new product vulnerability submissions through its Open Source Software Vulnerability Reward Program, better known as the OSS VRP. Google said the pause followed a significant increase in automated submissions and that the vast majority of those submissions were invalid. The company plans to continue reworking this part of the program and has committed to providing an update in the first quarter of 2027. Existing reports are not affected, and supply-chain vulnerability reports remain in scope. ヘルプ・ネット・セキュリティ
That distinction matters. Google did not simply abandon open-source security research, nor did it shut down every component of its OSS vulnerability program. The decision is narrower and more interesting than that. Google effectively concluded that one particular vulnerability-reporting channel had become economically difficult to operate because automation had made it too cheap to generate plausible-looking security claims without making it equally cheap to prove them.
This is the core of what might be called the AI Bug Bounty Crisis.
Generative AI has dramatically reduced the cost of reading source code, searching for suspicious patterns, producing vulnerability hypotheses and writing professional-looking security reports. But it has not reduced the cost of validating those hypotheses by the same amount. An LLM can describe a convincing hypothetical buffer overflow, race condition, path traversal or authorization flaw in seconds. A maintainer may still need half an hour, several hours or even several days to determine whether the supposedly vulnerable code can actually be reached under realistic conditions.
When millions of tokens can be generated more cheaply than human engineering time can be consumed, the asymmetry becomes dangerous. An attacker—or merely an overly enthusiastic bounty hunter—does not need every report to be correct. They only need report generation to be almost free. The recipient, meanwhile, must still perform expensive human verification because dismissing the one real critical vulnerability hidden among hundreds of false positives could be catastrophic.
Google’s pause therefore represents something larger than a temporary change to a bounty program. It is an early example of a security institution being forced to redesign itself around a world in which finding generation is abundant but trustworthy validation remains scarce.
What Google Actually Paused in the OSS VRP
Google created its Open Source Software Vulnerability Reward Program in 2022 to reward researchers who find security problems in open-source software maintained by Google. The program has covered prominent projects and ecosystems that may ultimately affect a large number of downstream users.
The October 2026 change does not mean that every form of open-source vulnerability reporting has disappeared. According to Google’s announcement and current program guidance, the pause applies to new OSS VRP product vulnerability submissions. Reports submitted before October 1, 2026 remain unaffected. Supply-chain reports continue to be accepted, and some vulnerabilities involving Google Cloud-maintained open-source repositories may still qualify under the separate Cloud VRP when the vulnerability has an impact on a Google Cloud product. ヘルプ・ネット・セキュリティ
Google also directed researchers toward its other vulnerability reward programs where appropriate. That matters because the underlying message is not that external vulnerability research has stopped being useful. Instead, Google is attempting to route scarce triage capacity toward findings where security impact can be demonstrated with greater confidence.
The pause had also been foreshadowed months earlier.
On March 19, 2026, Google published a major set of OSS VRP rule changes explicitly citing what it described as a massive surge in AI-generated reports. Google said it was increasingly receiving submissions containing incorrect or hallucinated explanations of how vulnerabilities could be triggered. Other reports identified genuine coding errors, such as memory-safety problems, but failed to establish meaningful security consequences because the relevant code paths were unreachable or because the supposed vulnerability did not violate the project’s actual security model. Google Bug Hunters
That is a crucial technical distinction. A bug is not automatically a vulnerability.
Software contains enormous numbers of suspicious states, edge cases, assertions, crashes and imperfect coding patterns. Security research becomes valuable when the researcher connects one of those conditions to an adversary-controlled input, a reachable execution path, a violated security boundary and a meaningful impact.
AI systems are getting very good at identifying the first element.
They remain far less reliable at proving the entire chain.
Google Had Already Tried Raising the Proof Threshold
Before pausing new product vulnerability reports entirely, Google attempted a more incremental response.
Its March OSS VRP changes introduced project tiers ranging from OT0 flagship projects to OT3 lower-priority projects. Projects such as Bazel, Angular and Go were cited as examples of the highest-priority OT0 class. Google also tightened the requirements for certain categories of vulnerability reports.
For memory-corruption findings affecting OT0 and OT1 projects, Google began requiring stronger evidence such as exact OSS-Fuzz reproduction steps using an existing fuzz target or a merged patch. For lower-tier projects, Google later removed monetary rewards and credit for product vulnerabilities and certain other security issues. Google Bug Hunters
The direction of travel is obvious: the program increasingly moved away from paying for the assertion that a vulnerability might exist and toward rewarding evidence that a vulnerability does exist and matters.
That sounds like a minor administrative change. It is actually a major philosophical shift in vulnerability research.
Traditional security programs have historically tolerated a certain amount of incomplete analysis because finding subtle vulnerabilities requires creativity and uncertainty. A human researcher might discover something unusual but lack access to the exact production environment needed to demonstrate maximum impact. Mature triage teams therefore helped connect the dots.
That model becomes much harder to sustain when automated systems can manufacture thousands of incomplete dots.
If a model can generate fifty vulnerability hypotheses before breakfast, asking maintainers to finish the research on each hypothesis effectively turns the target organization into the researcher’s unpaid validation team.
The incentives stop working.
The Fundamental Problem: AI Makes Suspicion Cheap
To understand the AI Bug Bounty Crisis, consider what modern language models are actually good at.
An LLM can ingest a source file and notice that user-controlled data eventually reaches a filesystem operation. It can see a call to memcpy() and notice that the source length may be derived from external input. It can identify string construction around SQL queries. It can detect an apparently missing authorization check or suspicious deserialization routine.
Those observations may be valuable.
The problem begins when the model transforms a potentially dangerous pattern into a confident vulnerability narrative without performing the necessary adversarial validation.
Imagine code resembling the following:
void process_packet(struct packet *p) {
char buffer[256];
if (p->length > sizeof(buffer)) {
return;
}
memcpy(buffer, p->data, p->length);
}A basic code-analysis model should recognize memcpy() as worth examining. But vulnerability analysis requires understanding the branch conditions, the origin and type of p->length, integer conversions, upstream parser constraints, memory ownership and whether an attacker can actually invoke the function with the required state.
Now imagine a more complicated repository containing a suspicious function:
def extract_file(base_dir, filename):
destination = os.path.join(base_dir, filename)
with open(destination, "wb") as output:
output.write(get_payload(filename))A language model can easily propose a path traversal vulnerability using ../../etc/passwd.
But what if ファイル名 is not attacker controlled? What if an upstream parser normalizes paths? What if the function is only called with identifiers generated internally? What if base_dir lives inside a sandbox where traversal does not cross a meaningful security boundary? What if the supposedly vulnerable function belongs to a test utility that is never included in production builds?
A convincing report can still be written.
It can contain a vulnerability title, severity estimate, hypothetical attack chain, CWE classification and even a polished proof-of-concept snippet.
And the entire thing can be wrong.
That is the new problem.
AI Hallucination Becomes Much More Expensive in Security
Hallucination in a general-purpose chatbot may produce an incorrect historical date or a nonexistent citation. Hallucination in vulnerability research behaves differently because the output is handed to engineers who have an obligation to investigate potentially serious security claims.
A report might say that an attacker can trigger a function through a specific API endpoint even though that endpoint does not exist. It might claim remote code execution where the affected function is only reachable by a local administrator. It might assume an attacker controls a parameter that is actually generated by trusted server-side code. It might describe an authentication bypass while misunderstanding that the allegedly bypassed check is intentionally performed elsewhere in the request pipeline.
These errors can be subtle.
The report does not necessarily look like spam. In fact, generative AI makes it easier than ever for low-quality research to look professional. Headings are clean. The attack description is confident. CWE references appear plausible. The severity section invokes CVSS terminology. Mitigations sound reasonable.
Presentation quality has therefore become partially decoupled from research quality.
That creates a serious problem for vulnerability triage because many of the visual and linguistic signals historically associated with competent researchers are now trivial to synthesize.
A poorly written but technically brilliant report may contain more value than a beautifully structured ten-page report generated from a false premise.
Security programs increasingly need to evaluate evidence rather than prose.
Google’s broader VRP rules now explicitly emphasize reproducibility and quality. Its guidance says strong reports should clearly explain the vulnerability, attack preconditions and impact while supplying complete reproduction steps and relevant output. Google’s reward-quality guidance even identifies factually incorrect communication and “AI slop” as characteristics associated with low-quality submissions. Google Bug Hunters
That is a remarkable indication of how quickly generative AI has changed vulnerability intake.
A Bug Is Not a Vulnerability
One of the most important lessons from Google’s March announcement is the distinction between a coding defect and exploitable security impact.
Google specifically described reports that correctly identified programming problems but had negligible security significance because of the project’s security model or because the affected code was not reachable. Google Bug Hunters
This distinction has always mattered, but AI makes it impossible to ignore.
Consider five layers of reasoning that separate suspicious code from an actionable vulnerability:
| レイヤー | Question | Common AI Failure |
|---|---|---|
| Defect | Is something technically wrong with the code? | Treats suspicious syntax as definite bug |
| Reachability | Can an attacker reach the vulnerable code path? | Assumes theoretical call path is externally reachable |
| コントロール | Does the attacker control the required input or state? | Invents attacker influence |
| Boundary | Does exploitation cross a security boundary? | Ignores intended trust model |
| インパクト | What confidentiality, integrity or availability loss actually occurs? | Exaggerates hypothetical consequence |
LLMs can often perform the first stage surprisingly well. The difficulty rises dramatically across the remaining stages because proving them requires context that may live across build configurations, runtime behavior, documentation, deployment assumptions and multiple repositories.
A report that stops at the first layer is useful static-analysis output.
It is not necessarily vulnerability research.
Reachability Is Becoming the New Scarce Resource
Modern vulnerability discovery increasingly produces what could be called candidate vulnerabilities: pieces of code that deserve investigation.
For traditional static analyzers, this was already familiar. Tools such as CodeQL, Semgrep and compiler sanitizers can deliberately trade precision for coverage. Security teams expect false positives and build workflows around filtering them.
LLM-based security agents change the scale and presentation.
Instead of producing a terse warning such as:
Potential uncontrolled path construction at filesystem.py:182an agent can produce an entire vulnerability report:
Critical Path Traversal Allows Arbitrary File Write
An unauthenticated remote attacker can manipulate the filename
parameter to escape the intended extraction directory and overwrite
arbitrary system files, potentially leading to remote code execution.The second output feels more authoritative even though it may contain no additional evidence.
The difference between those two outputs is mostly narrative confidence.
This is why future AI security systems need to treat reachability as a first-class engineering problem rather than a paragraph-generation problem.
A serious autonomous vulnerability researcher must demonstrate a chain resembling:
attacker-controlled input
↓
reachable interface
↓
parser / transformation
↓
vulnerable operation
↓
security boundary crossed
↓
observable impactEvery arrow requires evidence.
If any arrow exists only because an LLM inferred that it “probably” exists, the report remains a hypothesis.
The Economics of Bug Bounties Have Flipped
The traditional bug bounty model worked because searching was expensive.
Suppose one skilled researcher needed two days to investigate a complex project and produced one report. Even if 80% of incoming reports turned out to be invalid, the number of reports remained constrained by human effort.
AI destroys that constraint.
An automated system can clone hundreds of repositories, divide them into files, generate vulnerability hypotheses, ask additional agents to write attack scenarios, assign CWE identifiers, calculate approximate CVSS scores and automatically submit polished reports.
The marginal cost of report number 500 may be close to the cost of report number five.
The recipient does not receive the same scaling benefit.
A vulnerability triager still needs to read the report, inspect the affected code, identify the relevant version, understand the project architecture, reproduce the behavior and determine whether the claimed impact violates an actual security boundary.
The economics may therefore look approximately like this:
AI researcher:
Generate candidate ≈ seconds
Generate explanation ≈ seconds
Generate PoC-like code ≈ seconds
Submit another report ≈ near-zero marginal effort
Maintainer:
Read report ≈ minutes
Understand context ≈ minutes/hours
Build project ≈ minutes/hours
Reproduce claim ≈ minutes/hours
Trace reachability ≈ hours
Explain invalidity ≈ additional timeAutomation scales the supply side much faster than the validation side.
Once that imbalance crosses a threshold, a bounty platform can become a denial-of-service mechanism against maintainers even when no participant intentionally means to cause harm.
The AI Vulnerability Report as an Economic Attack
There is a useful way to think about low-quality automated vulnerability reporting: it resembles a form of asymmetric resource exhaustion.
The submitter spends very little.
The defender spends a lot.
The report does not have to contain malware or malicious payloads. It simply creates an obligation to investigate.
This is especially damaging for open-source projects, where the individuals receiving security reports may be volunteers or members of very small engineering teams.
A report claiming a critical remote code execution vulnerability cannot simply be ignored because it “looks AI generated.” Doing so could cause the project to miss a genuine zero-day.
The maintainer must establish why the claim is wrong.
That creates a peculiar inversion in which the person making the security claim can provide weak evidence while the maintainer must provide strong evidence to dismiss it.
At sufficient volume, the workflow becomes unsustainable.
Curl Had Already Reached the Same Breaking Point
Google is not the first major open-source security program to experience this problem.
In January 2026, curl founder Daniel Stenberg announced the end of curl’s bug bounty program. The project had operated a formal bounty since 2019, confirmed 87 vulnerabilities and paid more than $100,000 in rewards. But Stenberg said the situation deteriorated sharply as AI-generated security reports increased. According to his account, curl historically saw more than 15% of submissions result in confirmed vulnerabilities, while in 2025 the confirmation rate fell below 5%. daniel.haxx.se
That number reveals why the economics become painful.
A declining validity rate does not merely reduce the program’s usefulness. Each rejected report still consumes review capacity.
Curl removed monetary rewards at the end of January 2026. The project initially moved vulnerability reporting away from HackerOne, although it later returned to the platform as its private reporting channel while keeping the bounty itself discontinued. daniel.haxx.se
The distinction is important. Curl still wanted security reports.
What it no longer wanted was an incentive structure that encouraged people to mass-submit questionable findings.
That is almost exactly the problem Google is now confronting at much larger scale.
This Is Becoming an Industry-Wide Problem
Bug bounty platforms have been adapting as well.
HackerOne’s current Code of Conduct allows and encourages responsible use of AI during research, including reconnaissance, vulnerability discovery, proof-of-concept development and report improvement. But the company explicitly requires human validation. Researchers remain responsible for proving the finding, connecting the attack chain and demonstrating a reproducible vulnerability.
HackerOne specifically prohibits large volumes of low-signal reports, fabricated or unverified vulnerability claims and submissions relying on hallucinated technical details. Its enforcement guidance allows escalating sanctions for repeated large-scale submission of low-quality or unverified reports. ハッカーワン
In May 2026, HackerOne reported that the industry had experienced a greater-than-100% increase in report volume after more capable AI models and security tools appeared earlier in the year. The company emphasized that some of the increase represented valuable research, while another portion consisted of duplicates, unverifiable reports or submissions lacking sufficient depth to act on. ハッカーワン
This is why the phrase AI Bug Bounty Crisis should not be interpreted as “AI is bad at finding vulnerabilities.”
That would be too simplistic.
AI is good enough at vulnerability discovery to radically increase the number of things worth investigating.
The problem is that the ecosystem lacks equally scalable mechanisms for deciding which of those things are real.
The Real Problem Is Not AI-Assisted Bug Hunting
There is another important distinction that should not be lost in the backlash against AI-generated reports.
AI-assisted security research can be extremely useful.
A skilled researcher can use an LLM to understand an unfamiliar codebase, identify attack surfaces, generate test harnesses, suggest fuzzing targets, compare authorization paths, produce symbolic execution ideas, translate crash traces and automate repetitive reconnaissance.
None of that inherently lowers research quality.
The problem is delegating epistemic responsibility to the model.
A responsible workflow looks like:
AI generates hypothesis
↓
researcher investigates
↓
researcher reproduces
↓
researcher validates attacker control
↓
researcher demonstrates impact
↓
report submittedThe problematic workflow looks like:
AI generates hypothesis
↓
AI generates PoC-looking text
↓
AI generates CVSS score
↓
AI writes report
↓
report submittedThe difference is not whether AI was involved.
The difference is whether somebody established that the claim is true.
What an Invalid AI Vulnerability Report Often Looks Like
Several recurring failure modes are likely to dominate AI-generated bug bounty noise.
The first is unreachable vulnerable code. The model identifies a dangerous operation but never proves that the relevant function can be triggered from an attacker-accessible entry point.
The second is false attacker control. A parameter appears to flow into a dangerous sink, but it is generated internally, sanitized upstream or restricted to trusted administrators.
The third is incorrect deployment assumptions. The model analyzes source code as though every optional feature, debug configuration or test harness were enabled in production.
The fourth is security-model confusion. A capability available to privileged users is described as privilege escalation even though the documented threat model explicitly grants those users the capability.
The fifth is impact inflation. A denial-of-service condition becomes “remote code execution” through several speculative steps that were never tested.
The sixth is version blindness. An agent finds vulnerable-looking code in a branch, stale fork, example project or already-fixed revision and reports it against the current product.
The seventh is duplicate rediscovery. Multiple researchers using similar models identify the same obvious issue and submit near-identical reports.
The eighth is synthetic proof of concept. The model generates plausible exploit code but the researcher never runs it against the actual software.
The resulting report may be grammatically excellent and technically decorated.
It is still unverified.
Why Proof of Concept Is Becoming More Important
Google’s emphasis on reproducibility suggests where the industry is heading.
A security claim should increasingly function like a scientific result: another competent person should be able to reproduce it.
A useful report therefore needs more than an assertion such as:
User-controlled input reaches an unsafe file operation and may allow arbitrary write.
A much stronger report establishes the environment, version, input and observable result:
Affected commit:
8f71c8a...
Build:
make release
Configuration:
FEATURE_IMPORT=true
Trigger:
POST /api/import
Content-Type: application/json
Payload:
{"path":"../../tmp/poc.txt","data":"AI_BUG_BOUNTY_TEST"}
Observed result:
/tmp/poc.txt created outside the configured import directory.
Security boundary:
Unauthenticated network client can write outside the application's
designated data directory.That structure changes the economics of triage.
The maintainer no longer needs to invent the attack for the researcher.
They only need to confirm it.
OSS-Fuzz Reproduction Is an Important Signal
Google’s earlier decision to require exact OSS-Fuzz reproduction for certain memory-corruption reports deserves particular attention.
A sanitizer crash can be interesting, but a security report becomes much stronger when the crash is reproducible through an established fuzzing target using a concrete testcase.
Instead of saying:
This parser may contain an exploitable heap overflow.the researcher can provide:
python3 infra/helper.py reproduce project_name fuzz_target crash_inputalong with AddressSanitizer output showing the exact invalid access.
This does not automatically prove remote exploitability, but it significantly reduces ambiguity.
More broadly, the industry is moving toward what could be described as proof-carrying vulnerability reports.
The claim arrives together with the evidence required to evaluate it.
From Bug Reports to Proof-Carrying Vulnerabilities
A future vulnerability report may need to contain several machine-verifiable artifacts:
| エビデンス | 目的 |
|---|---|
| Affected commit/version | Prevent stale-code reports |
| Reproduction environment | Make testing deterministic |
| Minimal trigger | Show the vulnerable state is reachable |
| Executable PoC | Demonstrate actual behavior |
| Runtime evidence | Sanitizer trace, debugger output, response or filesystem change |
| Attack preconditions | Establish realistic accessibility |
| Security boundary | Explain why behavior is a vulnerability |
| Impact proof | Demonstrate confidentiality, integrity or availability consequence |
| Fix validation | Show patched version blocks exploitation |
This requirement would naturally reduce low-effort automated submissions.
An LLM can produce prose describing these elements.
Generating valid artifacts for all of them is significantly harder.
That is precisely the point.
The Future Bug Bounty Report May Be Executable
One of the most promising responses to the AI Bug Bounty Crisis is to make vulnerability reports increasingly executable.
Imagine that instead of receiving a ten-page Markdown description, a project receives a container containing:
Dockerfile
affected_commit.txt
build.sh
trigger.sh
expected_result.json
actual_result.json
README.mdRunning:
docker build -t vulnerability-repro .
docker run --rm vulnerability-reprowould reconstruct the vulnerable environment, execute the trigger and demonstrate the security impact.
The triage platform could run the container automatically.
If the expected result cannot be reproduced, the report might never reach a human.
This does not work for every vulnerability class. Authentication bugs, complex distributed systems and vulnerabilities requiring cloud infrastructure can be difficult to package deterministically.
But the general direction is powerful.
AI generated the report.
Automation should verify the report before a human sees it.
Bug Bounty Programs Need Machine-to-Machine Triage
Trying to solve AI-generated report volume purely by hiring more human triagers is unlikely to work.
The attacker—or merely the enthusiastic researcher—has automation.
The defender needs automation too.
An effective future bug bounty intake pipeline may resemble:
Submission
↓
Schema validation
↓
Repository/version verification
↓
Duplicate clustering
↓
PoC execution
↓
Reachability checks
↓
Static/dynamic consistency analysis
↓
Impact sanity check
↓
Researcher reputation weighting
↓
Human triageLLMs themselves can participate in this filtering process, but they should not be the only judge. A model deciding whether another model’s hallucination is real can simply create a second layer of hallucination.
Deterministic evidence needs to sit underneath the language models.
Duplicate Detection Will Become Critical
AI security agents often converge on the same obvious patterns.
If thousands of researchers use comparable models, identical prompts or similar code-analysis agents, they may all discover the same issue within a short period.
This creates a new duplicate problem.
Traditional duplicate identification frequently relies on human analysts reading reports and comparing symptoms. At AI scale, platforms need semantic clustering that groups reports by vulnerable function, source location, call graph, root cause and exploit primitive.
A mature system could fingerprint a finding using something closer to:
repository
+
commit ancestry
+
affected function
+
sink
+
source-to-sink path
+
security boundary
+
observable impactrather than merely comparing report text.
Otherwise, generative paraphrasing can make identical findings appear superficially different.
Researcher Reputation May Become More Important Than Ever
Bug bounty platforms have long maintained reputation systems, but autonomous research will increase their importance.
When report generation is cheap, submission rights themselves become valuable.
Programs may eventually assign researchers dynamic submission budgets based on historical precision.
For example, someone whose previous fifty reports produced thirty confirmed vulnerabilities might be allowed higher submission volume and faster triage.
An account with fifty submissions and zero validated vulnerabilities might face stricter requirements, mandatory automated reproduction or rate limits.
This changes the incentive from:
submit as many things as possibleに：
protect your precision rateThat incentive is much better aligned with maintainer interests.
Bug Bounty Programs May Adopt Submission Costs
A more controversial possibility is the introduction of economic friction.
If submitting a report costs nothing but reviewing it costs significant engineering time, the system invites spam.
A program could theoretically require a refundable deposit, reputation stake or compute-based verification token for some categories of report.
Valid finding:
stake returned + bounty paidRepeated invalid automated submissions:
stake partially lostSuch systems introduce fairness problems and could exclude talented researchers without financial resources, so they would need careful design.
Reputation-based costs are probably more realistic than literal monetary deposits.
Still, the underlying economic principle is difficult to avoid: when one participant can impose expensive work on another at zero cost, abuse becomes predictable.
Google Is Moving From Discovery to Demonstration
Perhaps the most significant aspect of Google’s response is the shift in what counts as valuable research.
The scarce thing used to be discovering suspicious code.
The scarce thing is increasingly demonstrating that suspicious code creates a real vulnerability.
That distinction may reshape vulnerability research careers.
A researcher who merely operates an AI scanner will have little differentiation when everyone has comparable models.
A researcher who understands systems deeply enough to transform a machine-generated hypothesis into a reliable exploit chain remains extremely valuable.
In other words, AI may commoditize the first 60% of vulnerability research while making the final 40% more important.
That final portion includes understanding architecture, privilege boundaries, runtime behavior, deployment assumptions and real-world consequences.
Those are precisely the areas where shallow automated analysis tends to fail.
Security Researchers Need to Change Their Workflow
For researchers using AI coding or security agents, the lesson from Google’s pause is straightforward: do not submit the model’s answer.
Use it as a lead.
Before sending a vulnerability report, the researcher should be able to answer several questions in precise technical language.
Where does attacker-controlled input enter the system?
What transformation occurs between source and sink?
What exact code path reaches the vulnerable operation?
What privileges does the attacker require?
What security boundary is crossed?
Which versions are affected?
Can the behavior be reproduced from a clean environment?
What changes after successful exploitation?
Can another researcher independently reproduce the same outcome?
If those questions cannot be answered, the finding is probably not ready for a bounty submission.
A Better AI-Assisted Vulnerability Research Pipeline
A more defensible workflow starts with broad automated discovery but progressively increases the burden of proof.
The agent first performs repository reconnaissance: architecture, interfaces, parsing boundaries, authentication systems, privileged actions, dependency structure and trust boundaries.
It then produces candidate findings.
Those candidates should not immediately become reports. They should become tasks for additional validation agents.
例えば、こうだ：
Candidate:
Possible path traversal in archive extraction
Validation agent 1:
Determine whether filename is attacker-controlled
Validation agent 2:
Trace normalization and sanitization
Validation agent 3:
Build affected revision and execute payload
Validation agent 4:
Determine whether extraction escapes sandbox
Validation agent 5:
Search history/issues for existing report or fix
Human researcher:
Review evidence and assess impact
Only then:
Submit reportThis is fundamentally different from asking a model:
Find vulnerabilities and write bug bounty reports.The first workflow is an autonomous research pipeline.
The second is a report-generation machine.
Agents Should Be Optimized for Precision, Not Report Count
The current AI security market sometimes rewards benchmarks based on how many potential bugs an agent can identify.
Bug bounty programs care about something different.
Precision matters.
An agent producing ten findings with eight genuine vulnerabilities may be far more useful than an agent producing 10,000 findings containing twenty real vulnerabilities.
The latter system technically finds more vulnerabilities.
It also creates 9,980 false positives.
For an internal security team that can automatically filter those results, such recall may sometimes be acceptable.
For an external vulnerability disclosure program where every submission creates human work, it can be disastrous.
Security-agent evaluation therefore needs metrics such as:
precision
reproduction success rate
duplicate rate
impact accuracy
reachability accuracy
human triage minutes per valid vulnerabilityrather than raw finding count.
“Human in the Loop” Cannot Mean Clicking Submit
HackerOne’s current AI guidance emphasizes human-in-the-loop operation for automated security agents and makes researchers responsible for validating AI-assisted outputs. ハッカーワン
But the phrase “human in the loop” can become meaningless if the human merely approves whatever the model generated.
A genuine human validation layer requires the researcher to understand the claim.
If asked:
Why is this function reachable remotely?
the researcher should not need to ask the model again.
If asked:
What security boundary is violated?
the researcher should know.
If asked:
Did you personally reproduce this exploit?
there should be a concrete answer.
Human approval without human understanding does not solve AI slop.
It merely adds a button.
AI Could Still Make Bug Bounties Much Better
None of this means autonomous security research is a dead end.
The opposite may be true.
Once verification pipelines improve, AI could dramatically increase the number of genuine vulnerabilities discovered before attackers exploit them.
Agents can already reason across source code, generate fuzz harnesses, automate patch analysis, identify suspicious commits and rapidly compare implementations across languages.
The long-term opportunity is enormous.
But autonomous discovery needs autonomous falsification.
For every agent asking:
How could this code be vulnerable?another agent should ask:
Why might this finding be wrong?A third should attempt to execute the proposed exploit.
A fourth should compare the claim against the documented threat model.
A fifth should search for duplicates and prior fixes.
Only claims that survive adversarial validation should be surfaced to humans.
Security Agents Need an Internal Skeptic
Current language models have a natural tendency to complete the task implied by their prompt.
Ask:
Find an RCE vulnerability in this repository.and the model is implicitly rewarded for producing something that resembles an RCE vulnerability.
A safer research architecture separates discovery from falsification.
One model proposes:
Hypothesis:
Integer truncation allows undersized buffer allocation.Another is instructed:
Assume the vulnerability claim is wrong.
Find all reasons this exploit cannot work.A runtime agent then attempts reproduction.
Only if the hypothesis survives all stages does the system escalate it.
This resembles scientific peer review more than ordinary code generation.
That is probably what serious autonomous security research will need to become.
What Google’s Decision Means for Open Source Maintainers
For open-source maintainers, the Google OSS VRP pause is a warning about what is coming.
Open repositories are perfect targets for autonomous vulnerability agents because source code is freely accessible and testing can often be performed locally.
As AI coding agents improve, maintainers should expect increasing numbers of machine-discovered candidate vulnerabilities.
Projects therefore need explicit disclosure rules.
A modern SECURITY.md may eventually need to specify not just where vulnerabilities should be reported but what evidence is required.
例えば、こうだ：
Reports must include:
- affected release or commit
- concrete attack preconditions
- reproduction steps
- working proof of concept where technically possible
- observable security impact
- confirmation that the issue was reproduced by the reporter
Unverified automated scanner or AI-generated findings
without demonstrated impact may be closed without investigation.Such language does not ban AI.
It bans outsourcing validation to maintainers.
That is a much healthier distinction.
What Google’s Decision Means for Bug Bounty Platforms
Platforms such as HackerOne and similar services now sit in a difficult position.
They want to support AI-assisted research because AI can uncover genuine vulnerabilities. At the same time, platforms cannot permit unrestricted automated submissions because the external cost is paid by their customers and maintainers.
HackerOne’s 2026 policies illustrate the emerging compromise: AI is permitted and even encouraged as a research tool, but researchers remain accountable for validation and large-scale low-quality submissions can result in penalties. ハッカーワン
We should expect much stronger technical enforcement of those principles.
Future platforms may automatically execute PoCs, inspect repository state, compare findings against known duplicates and calculate confidence scores before allowing reports to enter normal triage queues.
The bounty platform itself may become a security-agent orchestration layer.
What Google’s Decision Means for AI Security Startups
The AI Bug Bounty Crisis also has implications for companies building autonomous penetration-testing and vulnerability-discovery systems.
“Find more bugs” is no longer enough.
Customers will increasingly ask:
How many findings are reproducible?
How many require human investigation?
How often does the system hallucinate attack paths?
Can it automatically validate exploitability?
Can it distinguish a coding defect from a security vulnerability?
Can it explain the security boundary being crossed?
Can it produce artifacts that another engineer can reproduce?
Can it prove that a vulnerability still exists in the current version?
These questions shift competitive advantage away from pure LLM reasoning and toward integrated systems combining static analysis, dynamic execution, fuzzing, sandboxing, browser automation, exploit verification and evidence collection.
The most valuable security agents will not simply be good at generating hypotheses.
They will be good at killing their own false hypotheses.
The Coming Transition From AI Slop to Autonomous Verification
The current explosion of poor reports may ultimately be a transitional phase.
The first generation of AI vulnerability systems made discovery cheap.
The next generation will need to make verification cheap.
That evolution is familiar from other areas of software engineering. Compilers do not merely generate assembly and hope it works. CI systems do not trust that code builds because a developer says so. Tests exist precisely because claims about software need executable validation.
Security research is moving in the same direction.
A future AI agent may be expected to submit something equivalent to a failing security regression test:
def test_unauthorized_file_read(): attacker = unauthenticated_client() response = attacker.get( "/download", params={"path": "../../private/config"} ) assert response.status_code == 403On the vulnerable revision, the test unexpectedly succeeds.
On the patched revision, it fails as intended.
That is vastly more valuable than three pages explaining that a path traversal “could potentially” expose confidential data.
AI Bug Bounty Crisis Is Really a Validation Crisis
The easiest interpretation of Google’s decision is that AI-generated vulnerability reports have become annoying.
The deeper interpretation is that the security industry has reached a validation bottleneck.
AI can now generate more vulnerability hypotheses than humans can realistically investigate.
That changes where economic value resides.
Yesterday:
scarce resource = vulnerability discoveryToday:
scarce resource = vulnerability validationTomorrow:
scarce resource = high-confidence autonomous validationThis transition will reshape vulnerability reward programs, security tooling and offensive-security research.
Will Google Reopen OSS VRP Product Vulnerability Submissions?
Google has not announced a definitive reopening date.
The company said it will continue restructuring this aspect of the OSS VRP and provide an update in Q1 2027. Reports submitted before October 1, 2026 remain unaffected, and supply-chain reports continue. ヘルプ・ネット・セキュリティ
The interesting question is therefore not merely when the submission channel returns.
It is what it will look like when it does.
A redesigned OSS VRP could introduce stricter reproduction requirements, automated pre-triage, tighter eligibility rules, researcher reputation controls or additional evidence requirements.
Google had already begun moving in that direction months before the pause.
The October decision suggests those measures were not enough.
Why Google’s Pause Matters Beyond Google
Google operates some of the largest security programs in the world. When a company with Google’s engineering resources concludes that automated invalid reports are creating enough overhead to suspend part of a vulnerability reward program, smaller organizations should pay attention.
A five-person open-source project cannot solve the same problem by hiring fifty security triagers.
Volunteer maintainers certainly cannot.
The entire responsible-disclosure ecosystem therefore needs defenses against report-generation abundance.
The solution cannot simply be “ignore AI reports,” because AI will also discover genuine vulnerabilities.
It cannot be “ban AI,” because enforcement would be nearly impossible and would exclude useful research.
The workable rule is simpler:
AI-assisted discovery is acceptable. Unverified claims are not.
The Definition of a Good Bug Hunter Is Changing
For years, elite bug bounty researchers differentiated themselves through intuition, persistence and deep understanding of unusual application behavior.
Those skills remain important.
But another skill is becoming central: the ability to convert machine-generated suspicion into defensible evidence.
The researcher of the autonomous-agent era may spend less time manually reading every line of code and more time deciding which hypotheses deserve investigation, designing reliable experiments, proving attack chains and understanding the security model of complex systems.
That is not the disappearance of human researchers.
It is an elevation of the part of vulnerability research that requires judgment.
Models can produce possibilities.
Researchers must still establish reality.
Conclusion: The Bug Bounty Era Is Not Ending, but the Rules Are Changing
Google’s October 2026 decision is one of the clearest signals yet that generative AI has changed the economics of vulnerability disclosure.
The company did not stop caring about open-source vulnerabilities. It paused a specific category of OSS VRP submissions after automated reports—most of which Google said were invalid—created an unsustainable signal-to-noise problem. Months earlier, Google had already warned about AI-generated hallucinations, unreachable code paths and findings without meaningful security impact, while tightening the evidence requirements for its highest-priority projects. Google Bug Hunters
Curl reached a similar breaking point. HackerOne has strengthened its rules around unverified AI submissions. Other bounty programs are increasingly demanding working proof of concept and real demonstrated impact. daniel.haxx.se
The pattern is becoming difficult to dismiss.
Artificial intelligence has solved part of the vulnerability-discovery problem faster than the security ecosystem solved the vulnerability-validation problem.
That mismatch is the real AI Bug Bounty Crisis.
The next generation of security agents therefore cannot be judged by how many vulnerabilities they claim to find. They will be judged by how reliably they can prove those vulnerabilities are real.
A useful AI security system should be able to find suspicious code. A serious one should be able to reproduce the issue. A trustworthy one should be able to explain why the attack works, demonstrate the crossed security boundary, eliminate alternative explanations and produce evidence another engineer can independently verify.
Until automated vulnerability research reaches that standard, programs such as Google’s OSS VRP will continue facing an uncomfortable paradox: AI makes it easier than ever to find potential security problems while simultaneously making it harder than ever to know which reports deserve human attention.
And in the age of autonomous bug hunting, attention may become the most expensive security resource of all.
Japanese 
English 
German 
French 
Spanish 
Portuguese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew