What happens when the bots you build get good enough to flood the people you were trying to help?
That question stopped being hypothetical on October 1, 2026. Google suspended product vulnerability submissions to its Open Source Software Vulnerability Reward Program, the OSS VRP, after an overwhelming influx of invalid AI-generated reports. The announcement came through an official X post, pointing participants toward other VRP programs while the team works on reformatting this part of the operation. Google promised an update by the first quarter of 2027 and noted a commitment to a more sustainable model for handling AI-assisted security research.
I build bots for a living. I write tutorials about agent architectures, retry logic, tool-calling loops. So I want to sit with this one honestly, because the failure mode here is something I have personally shipped.
The agent that works perfectly and ruins everything
Picture the pipeline. You point an agent at a repository. It clones the source, reads files, reasons about memory handling or input validation, and drafts a vulnerability report in the format the program expects. Then it does the same thing for the next repo. And the next. You wake up, skim the output, and submit.
Nothing in that chain is broken. The clone works. The reasoning produces plausible text. The report matches the template. Every component passes its own test. The system still generates garbage at a rate no human triage team can absorb, because “plausible vulnerability report” and “actual vulnerability” are different targets, and the agent was only ever optimizing for the first one.
This is the part that should bother anyone building automation. The bug is not in the code. The bug is in what we chose to measure. An agent that produces well-structured output gets scored as working. Whether that output is true is a separate question, and it is almost always the harder one to answer programmatically.
Volume is a cost you push onto someone else
Bug bounty triage has always been asymmetric. Submitting takes minutes. Verifying takes real engineering time, often from maintainers who already have day jobs. Open source projects run on that thin margin of volunteer attention.
AI tooling collapsed the submission side to near zero while leaving the verification side exactly where it was. That is not a scaling problem you can fix with a better queue. It is an economics problem. When one side of a transaction gets a thousand times cheaper and the other does not, the system does not get more efficient. It breaks.
Google suspending submissions is the only sane move available. You cannot rate-limit sincerity. You can only stop accepting input while you redesign the gate.
What this means if you ship agents
I have been rethinking a few defaults in my own work, and I would suggest the same to anyone reading this site for architecture advice.
- Put verification inside the loop, not after it. If your agent claims a bug exists, it should produce a reproduction that actually runs. No proof of concept, no submission. Make the agent prove itself before a human ever sees the output.
- Treat throughput as a risk signal, not a win. If your pipeline can file a hundred reports a day, ask who absorbs that load. “My bot is fast” and “my bot is useful” are unrelated claims.
- Stop letting a human be the last filter by default. Rubber-stamping agent output is not review. If you cannot personally defend a submission, you are not the author of it, you are the delivery mechanism.
- Design for the receiving system. Most of us build agents as if the world has infinite patience for our output. It does not. A good agent respects the constraints of whatever sits downstream.
The uncomfortable mirror
Agents are genuinely good at reading code. They spot patterns across files faster than I do, and I have found real problems in my own projects by asking one to look. The capability is not fake.
What is missing is the judgment to stay quiet. A security researcher who reads a codebase for two hours and finds nothing writes nothing. That restraint is a feature, and it is exactly what we failed to build into our tooling. We built systems that always have an answer, then pointed them at programs that depend on people only speaking up when they are sure.
Google’s suspension is a specific program closing a specific door, with a stated plan to reopen it in some new shape. But it is also a early data point on something broader. As agents get cheaper to run, every open intake channel becomes a target of accidental abuse. Public issue trackers, support queues, code review, peer review, moderation reports. Anywhere humans volunteer attention to sort through contributions, the same math applies.
The fix will not come from better models. It will come from builders deciding that quiet confidence beats loud volume, and designing accordingly. That is a culture problem wearing an engineering costume, and we are the ones who get to solve it.
🕒 Published: