So…what’s going on at HackerOne lately? It might be time for a wellness check.
If you are new to the bug bounty space (1-3 years), you might not have any idea what I’m talking about.
But as a properly washed-up bug bounty hunter who lived through the golden era of HackerOne, I think it’s time to address the elephant in the room.
For some context, I started as a hacker on HackerOne in 2017. When I began working in tech, that hands-on experience was extremely useful for managing a bug bounty program, since I knew what researchers wanted, and how to interact with them.
As a result, I have managed multiple large bug bounty programs on HackerOne across various companies from 2018 to 2025 and I’ve been on both sides of the equation.
What I’m about to talk about comes from first-hand experience, both as a researcher and as a bug bounty program manager, and many, many years of direct conversations with HackerOne, both publicly and privately.
Background #
To start, I think it’s important to realize what HackerOne was originally designed to be.
In 2011, two ethical hackers, Jobert Abma and Michiel Prins, set out to find security vulnerabilities in 100 of the largest tech companies. They succeeded and found bugs in Google, Facebook, Apple, Microsoft, Twitter, and many others. At this point in time, the landscape for ethical security research was risky, legally dubious, and very scary for security researchers.
Not only was there significant personal liability, but there had been multiple instances of hackers being criminally charged and sentenced to jail time for finding and reporting security vulnerabilities prior to this. Much of this was due to specific arbitrary lines drawn in the sand which, if crossed, made you a bad actor, but if not crossed, made you a potentially bad actor but technically not one.
Bug Bounty Platforms like HackerOne were designed to directly address this issue. It created a safe mutual space for companies and hackers to connect, and it paved the way for ethical hackers to submit security vulnerabilities to companies, with full consent, and get paid for that work. This was a huge milestone. You no longer had to worry about getting dragged to court (or jail) for finding an IDOR that leaked customer data. Instead, you got a “thank you” and a cash payout for making everyone a little safer.
This operating model was the foundation for bug bounty and remained that way for the next 5+ years.
The Golden Age of HackerOne and Live Hacking Events #
During this period, there was a very strong and explicit focus for the business: how do we make this the best possible product for hackers?
The people running the business day-to-day were hackers, hacker-adjacent, and most (if not all) were face-to-face with hackers on a regular basis.
From 2017 to 2020, HackerOne was doing Live Hacking Events (LHEs) every few months. These were exclusive events where the top bug bounty researchers around the world would fly into a location, be given a target, and go absolutely ham finding critical vulnerabilities. LHEs were a huge value prop for programs. During a 1-3 day period, you would get more high and critical security reports than you would have received for the whole year otherwise.
Every event had a 1-of-1 custom designed poster with graphics, hacker usernames, stickers and challenge coins. It’s hard to overstate what an incredible and productive period this was for HackerOne and their top programs.
These events were exclusive and highly coveted; invites and +1s were practically their own currency. And the environment at these events was surreal. You would be given free flights and hotels around the world, and spend a few days surrounded by the best and most skilled bug bounty hunters in the world. These researchers would regularly find some of the most impactful bugs using their own novel techniques, and all while sharing tips and tricks in one-off conversations that could not be replicated anywhere else.
Prior to the advent of live hacking events, most security researcher circles were small, isolated, and sharing information publicly was practically unheard of. LHEs created a way for security researchers to connect with each other, and essentially created a whole new community within infosec. Most of my closest friends nowadays are people who I met through the live hacking scene, and I am extremely grateful to HackerOne for that.
LHEs were not the only area where HackerOne was building and establish a community for security researchers. They created a HackerOne Community space to organize meetups, online events, workshops, and CTFs. They created regional clubs, and appointed hackers who lived there as ambassadors to help foster and grow local researcher communities all around the world.
But slowly but surely, things began to change. The community groups and events lost momentum and fizzled out. The custom designed silkscreen LHE posters became cheap low-effort laser prints. The people who had dedicated years to creating and running incredible events were laid off or left. The LHE invitation and scoring systems became (even more) exclusive, gamified, and exceedingly calculated.
So one by one, the dominoes began to fall.
The Profit Problem #
Before going further, I think it’s important to get into the “why” behind these changes that started happening. Sometime around 2020 or 2021, HackerOne was forced to come face-to-face with a very important question that every business must ask itself at some point: “How do we make money?”
To understand how HackerOne even was able to survive as a business, you have to first know that HackerOne was basically running entirely on VC money for the first 10 years of its existence. Between 2014 and 2022, the company did a seed round almost every 2 years, raising a total of $160M. If a company is self-sustaining, there is little-to-no reason to continue raising money unless you have an incredibly high burn-rate, which would be odd for a company with such little infrastructure and technical innovation.
If you know anything about VC, you know how this tends to work; they give you money, and in return, you give them indirect control of the business through board seats, advisory positions, and other leverage mechanisms. The VCs gave the money, so the VCs get the power.
Rome did not fall in a day, and neither did HackerOne. The paradigm shift started slowly, and then all at once. The core technology driving the platform began to stagnate. Very little changed within the platform. The UI remained tired and “functional”. The performance remained lacking.
But the VCs looked at their playbook and realized that the easiest way to make money was simple: get more customers.
First, the founding CEO was replaced with a corporate CEO. Instead of a 20% cut of bounties paid, they shifted to capacity-based fee structures, annual contracts, and locking customers into multi-year deals.
And then, sales. SALES SALES SALES!! They were fully convinced that sales were the bread and butter of the business. So instead of basing the company around hackers, they leaned into sales.
More customers = more annual contracts = more predictable long-term revenue. Once a customer is locked in, they are fed stats and numbers and greased up to keep them happy, but also to keep demands low. When contract renewal comes up, they are given massive (30-60%) discounts in exchange for a multi-year contract in order to keep them locked in and paying.
Account Managers would have regular meetings with customers and encourage them to raise bounties to stay competitive and attractive to hackers. They would tell you, “Hackers want to spend time focused on the highest-paying programs”.
HackerOne was proud of this and encouraged the behavior internally. They gave out rewards, free vacations, and encouraged their rapidly growing sales team to sign new customers as much as possible.
As this continued, things continued to degrade for everyone involved.
For triagers, the best ones (who were hackers themselves) burned out and quit. The pay was too low and the workload was too much.
For hackers, the triage experience declined, and they became flooded with excessive amounts of low-quality programs.
For customers, the quality of reports went down, the costs went up, and the race to the bottom began.
And for everyone, the platform experience declined and never evolved.
Typically at this point, market economics would dictate that this is where a competitor takes your business and you must improve to retain market share. But bug bounty is an oligopoly, and there are 3 companies that control almost the entire market.
So instead, HackerOne was forced to create a new exclusive opportunity called the “Hacker Success Program” (HSP). This is a dedicated space for top hackers to get direct support from HackerOne for anything bug bounty related. They were assigned to a Hacker Success Manager (HSM) who was employed by HackerOne, and they could leverage that relationship to navigate miscommunications, bad program experiences, low or inaccurate bounty payouts, and much more. They also use this space to offer unique opportunities like H1 challenges for hackers in the HSP group.
One thing I want to call out is that while this is a great idea in theory, in practice it created a completely lopsided playing field for new hackers. You have basically zero ways to advocate or work through problems (good luck working with HackerOne support), so the rich get richer and you are given the option to deal with it or get lost unless/until you are a top hacker. Oddly enough, it would be much easier to become a top hacker if you had access to these resources in the first place.
Anyway, for some hackers, the HSP revolutionized what was previously an impossible brick wall. If you got screwed over by a company who failed to understand the security impact of your report, you could now lean on your HSM to help get a direct line of communication to the company and try to resolve that.
But for others, the HSP highlighted one of the core underlying failures that has plagued HackerOne for years: stagnating feature development. Even if you are part of the exclusive HSP group, you still don’t have the ability to do one important thing, which is to invoke change and development within the platform.
And yet, for some reason, HackerOne decided to take a performative approach to this, going as far as to create a dedicated platform feedback channel, but doing absolutely nothing with any of that feedback. I cannot even count how many pieces of individual feedback and suggestions have been posted in there, with positively zero action from HackerOne.
The AI Era #
And then, around 2021, we all entered a new period of human history: the rise of AI and LLMs.
Beginning around this time, we all began to witness the huge gains in velocity and the capabilities of LLMs. You could now one-shot features in a fraction of the time, build custom tools, and overall get more done in less time.
But this is where HackerOne took a confusing turn. It is truly baffling to me how HackerOne managed to fumble this technology in the worst way possible. They had a 10-year backlog of feature requests, and were handed one of the most powerful software development tools in the last 50 years. But instead of using this to improve the platform and add long-requested features, they decided to move toward creating “their own” AI assistant called Hai. Not only was Hai just a wrapper on top of OpenAI, but it barely had any real unique capabilities to help hackers or programs do what they had been requesting from HackerOne to add to the core platform.
On top of this, the driving force behind the company, the hackers and co-founders who started the business, were quietly shoved away into the dungeon of HackerOne. The website has them listed as part of the executive team, but they are puppets in their own business, barely getting to work on the product they built from the ground up.
The Enshittification of HackerOne #
For almost 10 years, Marten Mickos served as CEO of HackerOne. Some hackers loved Marten; others had mixed feelings. Personally, my interactions with him were somewhere between fine and good. But I do believe that he was very passionate about bug bounty and did a lot of good for the company during his time as CEO.
But in late 2024, Marten was replaced by Kara Sprague, the former Chief Product Officer at F5. You might be asking yourself, what does a CPO of a networking company know about hacking and bug bounty?
Honestly, I am not sure. What I will say is that there are mixed signals online regarding what happened to BIG-IP during her time as CPO at F5.
But that didn’t stop the board from deciding she was the right fit for the future of the company. And this was neither the first nor the last in a series of questionable business decisions made by HackerOne.
As AI agents continued to grow and shift into various identities, HackerOne’s identity also began to shift. Slowly but steadily, HackerOne rebranded itself around a newly invented industry category: “CTEM”, or “Continuous Threat Exposure Management”.
HackerOne quickly began to evolve into a soulless corporation obsessed with numbers, business objectives, and B2B sales. They switched from talking about bug bounty programs, live hacking events, and how they could help you stay secure, to promoting their in-house AI security product and continuous security monitoring tool.
Wait, what? What in-house AI security product?
Your Reports Are Yours, We Promise #
Sometimes, it all starts with a tweet.
In February 2026, well-known hacker zseano noticed that there was a surge in HackerOne employees leaving the company and asked why that would be happening.
This ended up revealing that HackerOne had made ToS updates which made it so that reports submitted on HackerOne could be used to train AI models.
As you might expect, this created quite a bit of noise, especially within the HSP chats. One thing I’ve noticed is that the modern day HackerOne only ever lets the founders out of the dungeon for damage control, and this was a perfect time to pull that lever.
Within 24 hours, Alex Rice, co-founder, CTO (and CISO…?) of HackerOne emerged from the dungeon to perform damage control. (This was the first time he had ever messaged in the HSP general chat since it was created two years earlier).
We do not train, fine-tune, or otherwise improve GenAI or large language models on researcher data. That includes Agentic PTaaS.
https://docs.hackerone.com/en/articles/10908081-hai-security-trust
And when asked to remove Section 3.1 of the ToS, Alex promised that this would be taken care of and made clearer in an upcoming update to the ToS.
Within a week, CEO Kara Sprague had been looped in and made a fluffy LinkedIn post explaining that
HackerOne does not train generative AI models, internally or through third-party providers, on researcher submissions or customer confidential data.
Researcher submissions are not used to train, fine-tune, or otherwise improve generative AI models. This applies across our platform, including capabilities used within our Agentic PTaaS offering and our in-platform AI, Hai.
Alex Rice even went on to the Critical Thinking Bug Bounty Podcast and did a guest spot to talk about this issue specifically and shut down any concerns about report data being used to train AI models.
Amazing, that’s settled then. HackerOne doesn’t use researcher data to train AI models.
…Right?
Just Kidding They Never Were #
Unfortunately for us, the present-day HackerOne follows a rather impressive PR damage control playbook:
- Address fears
- Ease concerns
- Don’t change anything
About two months after this drama, someone mentioned in the HSP chat that they had noticed a comment from hackerone-agent on one of their reports and wanted to know if this was an AI agent or an actual human.
The response from one of the HackerOne product managers was:
This is a preliminary review done by AI […] The H1 triage process has a step called “H1 Intake” […] which we’ve automated for certain reports to make sure they reach the “Validation team” faster.
And when asked whether “certain reports” meant certain report types or whether a program could enable it everywhere, they responded:
We’re running the analysis on all reports, the AI determines what can be sent directly to the validation team vs what needs to be reviewed by a human from the intake team first. […] The system also learns from behaviour so, if a recommendation is rejected […] it will take these into account with its recommendations as well.
Hang on a second.
I thought that researcher submissions are not used to train, fine-tune, or otherwise improve generative AI models.
But now all reports are being run through an AI system, and the system is using the outcomes of those reports to influence how it handles future reports. So is that technically “fine-tuning”? Technically, no.
So how can both of these things be possible?
Well, when I asked this, I received an incredible copy-paste response of what Alex Rice had said back in February:
Hai does not train, fine-tune, or otherwise improve GenAI or large language models on customer or researcher data: https://docs.hackerone.com/en/articles/10908081-hai-security-trust
They then followed up with an explanation that appeared to contradict this:
Storing learnings in our DB is something different than training/fine-tuning a model on how to behave. We store the rejection reasons in our DB to cross reference and augment the reasoning the agent does when determining next steps. […] The agent will pick this up from behaviour the customer has done on past reports and use that to memorize and augment the reasoning for new reports.
So yes, HackerOne is not building model weights from your report data or “training” on it in the traditional sense.
But that is a distinction without any meaningful difference to the researchers whose data is being used. The system is still learning from report data in the practical sense that matters: past reports change future automated behavior.
Call it memory, retrieval, contextual learning, or whatever you want. For the purpose of deciding whether researcher data is being used to improve the system, the distinction is functionally equivalent.
And as a cherry on top, a few days later, HackerOne published a blog post stating:
As AI-assisted submissions have grown, we’ve invested heavily in AI-powered triage and validation on our own platform. Our agentic AI system, Hai, now handles initial classification, deduplication, and validation of incoming reports, working alongside our human security analysts.
The Boiling Point #
By this point, I had lost all faith in HackerOne. I’d been around for so many years and through so many seasons that there was really no point in leaving anything off the table.
So I posted a long message in the HSP chat, echoing many of the things I’ve said in this blog.
What happened as a result was actually really surprising: many other top hackers in the HSP agreed, echoed the same concerns, and called for change.
I figured, surely HackerOne will have to respond to this.
And they did.
Co-founder Michiel Prins was allowed to leave the HackerOne dungeon to perform damage control with this absolute banger of an AI slop response:
You’re right to call this out. Parts of the platform and overall experience have not moved fast enough, and that’s frustrating.
We have been prioritizing work that improves outcomes for both customers and researchers. Triage is a clear example. Speed and consistency there have improved materially, and that matters for everyone on the platform. Report Assistant may not be targeted at the caliber hacker in this channel, but it has been a significant enhancement for the largest part of the community - hackers earlier in their career - and this has led to much clearer reports for triage to analyze and accelerate overall throughput.
At the same time, there is a bigger shift happening with AI. There is a lot of noise about AI replacing security researchers. We do not believe that. We are investing to make sure researchers become more important, not less. A lot of that work is happening on the customer side of the marketplace.
That said, the gap you are pointing to on day-to-day usability and acting on feedback is real. We need to do a better job there, and we need to show that progress more clearly.
And then, per the playbook, they waited for the community to move on, brushed it under the rug, and nothing changed.
We Must Calm the Masses #
Well that was true until June, when rez0 (co-host of the Critical Thinking Bug Bounty Podcast) asked about the new “HackerOne Continuous Testing” product that had just launched:
The page (before it was updated) very clearly stated:
Testing is sharpened using context from HackerOne’s 12+ years of real-world vulnerability data and your prior H1 Bounty findings, so agents know where to focus
HackerOne immediately tried to run this back and claim that this was actually not true. I find it hard to understand how a company can be so incredibly disconnected from its own values, but only when it’s brought up by hackers who look closely and ask questions.
All the behavior over the last few months embodies “oops we didn’t mean to say the quiet part out loud”, and certainly not “we don’t do that”.
And honestly at this point if you have to do this much damage control, you might as well just own it.
I won’t even begin to break these statements down because there’s so much word soup that it’s mind-numbing.
As I write this post, I am exhausted from trying to perform the mental gymnastics required to believe all this.
Actions speak louder than words, and it’s pretty clear at this point what’s going on.
Feel free to skip ahead, but in an effort to be fair I’ll provide the replies from not one but two HackerOne co-founders (wow a double dungeon release):
No change in direction. There is zero training on researcher data.
This language isn’t even talking about vulnerability discovery. What happens when you point a “recon agent” at an attack surface?
Noise.
That’s the context being talked about here – Scope. Out of scope. Informative. Ineligible findings. This same contextual feedback loop is available to researchers (and, increasingly, their agents) through our intake agents & full triage process.
We continue to need to do much better on accompanying simplified marketing language with technical architecture documentation, and we need to do a better job at reinforcing the defense in depth narrative – there are no silver bullets here. Nowhere in our vision is a 100% AI human-free future.
- Alex Rice
and
Sorry for the confusion this paragraph has caused. It was meant to capture how our recon agents find out where to focus and where not to focus based on prior results in a customer’s program (mapping the attack surface), not find new vulnerabilities based on researcher submissions. We have adjusted the paragraph in the H1 Continuous Testing page and buttoned up our documentation. H1 Continuous Testing is based on the same approach and methodologies as the H1 Agentic Pentest offering announced in January. Here is the documentation on how those agentic products reason & use context for security testing workflows.
But let’s focus on the underlying concern: is H1 using researcher submissions to then deploy agents and find that vulnerability using their techniques in other customers? No.
That is a model that can be a win-win-win for everyone in the long run, but we don’t yet have the foundations in place to provide proper recognition and rewards for researchers in such a model. We’re envisioning a platform where researchers drive the frontier, agents provide the scale, and researchers get proper recognition for their impact. Imagine this: you discover a novel technique to find a vulnerability. We operationalize it across every customer’s attack surface that shows signs of exposure. Customers get protected. You get compensated not just for one report, but proportionally to the impact you generate across the platform. That is fundamentally a better deal for researchers than the current one-bounty-per-report model. And it is also a win for customers as it narrows the exposure window.
But the reality is that it’s just a vision right now. We are not there yet. This requires careful work across product, policy and researcher engagement models to build it right. Right now, we are still focused on building foundational agentic capabilities for testing, accelerating validation and triage, prioritization, and remediation. These have to work reliably first before we can layer on a researcher-driven attack library and incentive model that does justice to the contribution. We also owe it to customers not to just dump findings on them without the tooling to act on them.
The long term is about partnership, not replacement. We want to build incentive structures that support this vision. It’s unexplored territory, and we want to get it right with you.
- Michiel Prins
along with a HackerOne official™ tweet to calm the masses:
Conclusion #
Today as I look at HackerOne, it’s hard to even recognize the company that was started back in 2012. The values have shifted, the soul has been gutted, and the core identity has been lost. A sad ending for our hero’s journey.
So, where do we go from here?
Well, I have some final thoughts for each party involved in this twisting tale.
To HackerOne: It was nice knowing you. All I can hope is that you can find your true identity again one day. Although I doubt that will ever happen.
To the founders: I hope you got paid well, that you can exit, and that you go do something cool again.
To the hackers: Know your worth. Bug bounty platforms cannot exist without hackers.
To the companies: You don’t need HackerOne anymore. A single year of HackerOne costs less than the tokens to build your own in-house platform.
And to whoever is fired up: The market is ready for a disruption. The tools are in your hands. Build what HackerOne could have been.
Godspeed and thanks for reading if you made it this far.