Dear Readers,
Shubs wrote a post this week called The Downfall of Bug Bounties and it resonated with a lot of people I talk to regularly. The short version: he submitted a critical PII leakage bug to Uber, where he’s been hacking for almost ten years and is ranked #1 on their program, and didn’t get a human response for 12 days. A bug that would normally get actioned in one to three days just sat there. For Uber that’s 12 days of unpatched PII exposure with real regulatory consequences, reported by someone with a decade of track record on that exact program.
The easy take is that AI slop broke triage and that’s why everything is slow. I wrote about this in Replaced by a Goldfish and the numbers are ugly, curl killed their HackerOne program over it, confirmation rates dropped below 5% as AI garbage flooded in. But I think blaming AI alone lets the platforms off the hook for something they should have fixed years ago.
Platforms never invested in the human side#
Bug bounty started with something that actually worked. Companies opened up their attack surface to skilled researchers, researchers found real bugs, everyone benefited. In the early days there was a real symbiosis between researchers and companies, you’d interact with actual security teams, build a relationship with program managers, get recognized for consistent good work over time. Both sides saw each other as people and that’s what made the model sustainable.
Platforms scaled that by stripping out the human parts. Researchers became ticket numbers, triage became a faceless queue, and the relationship between the person finding the bug and the team fixing it got intermediated by a system optimized for throughput. The irony is that the same platforms that reduced researchers to anonymous inputs never stopped bragging about them to land customers. “Access to 500,000+ security researchers worldwide” looks great on a sales deck. The community is the product when you’re pitching enterprise deals, but the moment that community actually submits a report, they’re ticket 4091 in a queue that treats everyone the same. For a while that was fine because the volume was manageable and most of the people submitting actually knew what they were doing. But by turning researchers into anonymous inputs and triage into a processing pipeline, the platforms built the perfect system for AI to exploit without even realizing it. If a report is just a ticket with no human context behind it, then a well-written AI-generated ticket looks exactly the same as a legitimate one. There’s nothing to differentiate them because the platform never made researchers into more than their last submission.
That’s how you end up with Shubs’ Uber situation. The platform has all the data it needs to tell a top-ranked veteran apart from a zero-reputation account running an AI agent, submission history, accuracy rate, severity distribution, years of program-specific context, but none of it is wired into anything that actually affects how reports get prioritized. That data has been sitting there for years doing nothing useful while triage slowly fell apart under the weight of increasing volume.
Triage was already broken#
Nobody talks about triage the way they should. Triage is the most important function in the entire bug bounty ecosystem and it has been treated like a cost to minimize for as long as I can remember. The person doing triage is the one who decides whether a vulnerability gets seen or dies in a queue. They’re the bridge between the researcher who found the bug and the engineering team that needs to fix it. That job requires real security knowledge, the ability to read a report, understand the impact, reproduce the issue, and make a judgment call about severity and urgency. It’s skilled work and it matters.
But the platforms never treated it that way. Triage was always driven by numbers, tickets closed per hour, average time to first response, SLA compliance rates. The people doing it were measured on throughput, not on quality of judgment. When your KPI is how many reports you can process in a shift, the incentive is to move fast and move on, not to sit with a complex report and really understand what the researcher found. That pressure existed long before AI showed up. Triagers were already overworked, underpaid relative to the skill level the job actually requires, and evaluated by metrics that rewarded speed over understanding. Some of the best triagers I’ve interacted with clearly knew their stuff, but the system they worked in didn’t give them the space to use that knowledge properly.
The AI slop didn’t create this problem, it just made it impossible to ignore. Adding a firehose of generated submissions on top of an already stretched pipeline exposed how fragile the whole setup was, but the fragility was there long before anyone was prompting Claude to find bugs. Filtering the bad stuff is half the problem, getting the good stuff seen quickly by someone who can actually evaluate it is the other half, and nobody seems to be working on that part.
The people running HackerOne want it both ways#
What makes this worse is watching HackerOne’s leadership go all-in on AI while their own researcher community is telling them it’s destroying the ecosystem. CEO Kara Sprague told McKinsey that “agentic testing capabilities that incorporate the latest frontier models can find the same vulnerabilities that adversaries using models such as Claude Opus and Mythos would find — but agentic testing does it sooner.” Co-founder and CTO Alex Rice was at RSA 2025 talking about “the shift from talk to real AI.” Co-founder Michiel Prins has been pushing the same line. In January they launched Agentic PTaaS, a product that uses AI agents to do reconnaissance, exploitation, and validation across enterprise attack surfaces. The entire C-suite is betting the company’s future on replacing human effort with agentic AI.
The researchers noticed. When the Agentic PTaaS announcement dropped, the community response was immediate. One researcher put it bluntly: “We’re literally training our own replacement.” Another: “As a former H1 hunter, I hope you haven’t used my reports to train your AI agents.” The backlash got loud enough that Sprague had to issue a public clarification insisting HackerOne doesn’t train models on researcher submissions. “You are not inputs to our models,” she wrote. “Hai is designed to complement your work, not replace it.”
But look at the product roadmap and the marketing copy. “Continuous, expert-verified pentesting at enterprise scale.” “AI agents for reconnaissance, exploitation, and validation.” The message to customers is unmistakable: you’ll need fewer humans. And the message to researchers is supposed to be the opposite: don’t worry, you’re still essential. That math doesn’t add up. You can’t sell automation to enterprise buyers on one page and promise researchers their livelihoods are safe on another. And you definitely can’t do it while your own platform is drowning in the AI-generated slop that’s breaking triage for those same researchers. HackerOne is simultaneously building the spam cannon and complaining about the spam.
The best researchers have options#
Here’s what the platforms keep forgetting: their top researchers don’t need them. Shubs doesn’t need HackerOne to find bugs at Uber. He has the skills, the reputation, and the direct relationships. He uses the platform because it’s supposed to be convenient, a structured way to report, get paid, and move on. The moment that convenience disappears, the moment a critical sits untouched for 12 days, the calculus changes. Why go through a broken pipeline when you can reach the security team directly, sell the research to a broker, or just publish it?
I’ve been watching this happen all year. Experienced hunters quietly moving to private programs where they actually talk to humans. Others skipping platforms entirely and going straight to vendor security teams. Some just publish independently because at least then the work gets seen. These aren’t people rage-quitting over one bad experience, they’re making a rational decision. The platform costs them time, adds friction, and increasingly doesn’t deliver. The researchers the platforms can least afford to lose are exactly the ones with the most alternatives.
The data was always there#
The maddening part is that none of this had to happen. The platforms have had years of reputation data on every researcher, submission history, accuracy rate, severity distribution, program-specific track record. Everything you’d need to tell a veteran apart from a drive-by. But that data was only ever pointed outward, at customers. “Our top hackers have found X critical vulnerabilities” in the case studies, researcher stats on the sales page. The community was always the product being sold, never the customer being served.
If even a fraction of the engineering effort that went into Agentic PTaaS had gone into reputation-weighted triage, into making sure a critical from someone like Shubs actually gets seen faster than a medium from an account created last Tuesday, the AI slop problem would be manageable right now. Filter noise at the edges, fast-track signal from people you already trust. Instead the platforms chose to build AI products they could sell to enterprises while letting the infrastructure their own community depends on rot. That’s not a technology failure, it’s a priorities failure.
Until next time 🙂
