Bug Bounty is Dead!!!
For fifteen years the deal was simple. A researcher finds a flaw, reports it, and gets paid. The company fixes it before the criminals find it. Everyone wins.
That deal just broke, and the companies that built it are the ones saying so.
Google has suspended new submissions to its Open Source Software Vulnerability Rewards Program, the bounty that paid researchers to find flaws in Golang, Angular, Protocol Buffers, Fuchsia and other code much of the internet runs on. The reason is a flood of automated, mostly invalid, AI generated reports. Google says a reworked program will arrive in the first quarter of 2027. Since 2010 it has paid researchers more than $81.6 million, including a record $17.1 million last year, so this is not a company that stopped caring about security.
Google is not alone. The curl project ended its bounty in January. HackerOne paused payouts from the Internet Bug Bounty in April, saying the balance between finding flaws and fixing them had "substantively shifted." In mid September Intel removed every cash reward from its program. Microsoft warned in May that AI is speeding up vulnerability discovery, and last month it shipped patches for 966 flaws, two of them already under active attack.
The bottleneck moved
When I wrote Secure by Design in the Age of AI™, Volume VII of The Operating Discipline for AI Library, the bounty programs were still running. The numbers were already pointing here:
"AI-assisted vulnerability discovery has made candidate generation cheap and moved the bottleneck from finding to validating, triaging, patching, and releasing; the constraint is now the defender's remediation throughput, not the attacker's discovery rate."
That is what Google just ran into. Finding bugs is no longer the scarce skill. A model can produce candidate vulnerabilities all day. What is scarce is the human time to check whether each report is real, write the fix, test it, and ship it. Bug bounties paid for the part that became cheap and did nothing for the part that became the constraint.
The window is hours, not weeks
In The AI IT Security Implementation & Strategy™, Volume VI, I put the timing problem this way:
"A patch that takes 72 hours to test, approve, and deploy is a 72-hour exposure window against an adversary that can weaponize and deploy an exploit in under four hours."
Every organization that patches on a human schedule is living inside that gap right now. The attackers have AI too, and they do not wait for the change advisory board to meet on Thursday.
You cannot hire your way out
The instinct is to add people: more triage analysts, more maintainers, more reviewers. In Cloud and Infrastructure Security in the Age of AI™, Volume IX, the arithmetic answers that:
"The gap is not a headcount problem. It is a structural feature of machine operated infrastructure, and it only closes through controls that act at machine speed and evidence that is captured at machine speed."
Open source maintainers are already proving it. Many are volunteers, and the Linux kernel team reports more credible AI found bugs than it can triage. No budget makes a volunteer read faster.
The only real choice: let AI patch
Here is the part most leaders do not want to hear. When AI discovers a vulnerability, AI has to fix it. Writing, testing and shipping the patch has to happen at machine speed, because nothing slower closes the window. The research I cited in Volume VII says the defender actually has the advantage here, if the defender is built for it:
"The same agents that exploit also patch, and they patch better: on real bounty targets, agents patched ninety percent of the vulnerabilities they were given and exploited about half, which favors the defender who has a pipeline that can accept a patch at machine speed."
That does not mean handing the keys to a chatbot. It means the humans stop deciding during the event and start deciding before it. From the same volume:
"No human reacts at that speed, and no human has to, because the humans decided in advance."
"The fix authority was pre-signed as policy: what the pipeline may ship alone, by tier, and what still waits for a name."
Leadership writes the rules. Which systems AI may patch on its own, at what confidence, inside what blast radius, and which changes still need a named person's signature. Then every machine written fix goes through the same gates as any other change: the regression suite, the reproduction of the original flaw, and a sampled human review.
Where leaders get this wrong
The failure I expect to see is performative adoption. A company buys an AI triage tool, puts it in front of the same human queue, and calls the problem solved. The evidence warns against exactly that. In Volume VII I noted that models used to screen bounty reports tended to over-accept invalid ones, so a model as gatekeeper just moves the noise somewhere else.
The fix is not a tool. It is a governance decision about who is allowed to ship what, written down before the next flood arrives, with incentives that reward the people who build the pipeline rather than the people who clear the most tickets by hand.
Bug bounty as we knew it is dead. Security research is not. What replaces it is machines finding flaws, machines fixing them, and humans governing both. The organizations that make that decision now will patch in hours. The ones that wait will keep paying for reports nobody has time to read.