What Happened to HackerOne? How the Bug Bounty Pioneer Became an AI Security Company

For people who discovered bug bounty hunting through HackerOne in the late 2010s, the company can feel almost unrecognizable today. The old HackerOne was easy to understand. Companies opened their applications and infrastructure to security researchers, hackers tested them, vulnerabilities were reported through a common platform, and researchers were paid when they found something worth fixing. Around that basic transaction, HackerOne built something that was arguably more important than the software itself: a community.

There were Live Hacking Events, private programs, meetups, ambassadors, workshops and a culture that made elite researchers feel like participants in the security ecosystem rather than simply users of a SaaS product. HackerOne’s own historical material describes those events as bringing researchers and security teams together for concentrated testing, with its first company-run Live Hacking Event taking place in Las Vegas in 2016. By the end of 2019, HackerOne said it had hosted 20 events in 12 cities, paid more than $7 million in bounties and received more than 5,000 reports through those events.

Today, HackerOne is still a major bug bounty platform, and it still works with human security researchers. But the center of gravity has moved. The company now sells a much broader security platform built around vulnerability validation, penetration testing, AI red teaming, agentic testing, continuous testing and Continuous Threat Exposure Management, or CTEM. Its AI system, Hai, is no longer simply presented as a copilot. It sits inside a larger collection of automated security workflows.

That change is not necessarily evidence that HackerOne has failed. In many respects, it is a rational response to what is happening to security research itself. AI is generating more vulnerability reports, increasing the volume of useful findings while also producing a large amount of low-quality material. HackerOne says submissions reached 46,947 in March 2026, up 76% year over year, with roughly one quarter being valid and exploitable. It also says the share of critical and high-severity findings rose to 32% of validated vulnerabilities.

The more difficult question is what happens to the relationship between HackerOne and the researchers who created much of the security knowledge around which the platform was built. That is where the recent arguments about AI, researcher submissions and HackerOne’s terms become important.

HackerOne was built around a simple problem

The original value proposition of HackerOne was not particularly complicated. Security researchers routinely discovered vulnerabilities in products they did not own. Before modern coordinated vulnerability disclosure became widespread, reporting those vulnerabilities could put researchers in an awkward legal position. A researcher might have no clear authorization to test a system, no established contact inside the company and no guarantee that the company would respond constructively.

HackerOne helped create a structured market around that relationship. A company could define what researchers were allowed to test, researchers could work within that authorization, and the platform could provide communication, triage and payment mechanisms. That model mattered because vulnerability information is unusual. A researcher may possess highly valuable information about a security flaw, but neither side necessarily has enough information about the other to make the transaction straightforward. Academic research into HackerOne’s marketplace found that online bug bounty platforms reduce information asymmetry and transaction costs between researchers and organizations. One study examined more than 14,000 researchers, more than 125,000 public vulnerabilities and more than 500 firms using data from 2014 through 2021.

HackerOne therefore became more than a website for submitting bugs. It became a marketplace and a coordination layer. This explains why the company’s relationship with researchers matters so much. The platform’s value has always depended on both sides being willing to participate.

The years when HackerOne felt like a hacker company

The strongest memories among longtime researchers tend to revolve around HackerOne’s community. Live Hacking Events were a particularly visible example. Researchers from different countries would be brought together for short, intense engagements focused on selected targets. HackerOne’s description of the format included special scopes, additional access, bonuses, leaderboards and awards, alongside social and knowledge-sharing activities. Its 2019 recap described 20 events across 12 cities and more than $7 million in cumulative bounty payments from those events.

The importance of those events was difficult to measure purely in dollars. They put researchers who normally worked alone in the same room. A person who had spent years specializing in authentication flaws could compare techniques with someone focused on mobile applications or business-logic vulnerabilities. Informal conversations could be as valuable as the official event itself. The original HackerOne-era community was partly built through these relationships.

The company also developed regional community initiatives and an ambassador program around meetups and local events. That helped create an identity around HackerOne that went beyond the commercial relationship between a customer and a software vendor.

Some of that culture inevitably changed as the company grew. That does not mean every community initiative disappeared, nor does it mean HackerOne stopped working with researchers. Its current platform continues to advertise Live Hacking Events, and HackerOne still positions human security researchers as a core part of its model. The change is better understood as a shift in emphasis. The community was once one of the clearest things HackerOne was selling. Today it is one component of a much larger enterprise security business.

The business had to change

There is another part of the story that is easy to overlook when looking back nostalgically at the early HackerOne. HackerOne was a venture-backed company. In January 2022, HackerOne announced a $49 million Series E investment and said its total funding had reached nearly $160 million. The company said the investment would support its continued growth in the enterprise security market.

What it showed is that HackerOne eventually had to operate as a conventional enterprise technology company. That means selling contracts, expanding revenue, supporting large customers and building products that enterprises are willing to purchase. The commercial model changed over time as well. HackerOne’s 2023 customer terms still documented a default 20% fee on monetary rewards, but the company subsequently moved toward subscription-based pricing rather than relying primarily on a percentage of bounty payouts.

There was also a significant restructuring in 2023. HackerOne cut about 12% of its workforce, with CEO Mårten Mickos attributing the decision to the broader economic environment and changes in customer purchasing behavior. None of this is unusual for a venture-backed security company. The important thing is that HackerOne’s incentives became broader. It was no longer enough to make hackers happy. The company had to make enterprise security teams happy, too. Those goals overlaped, but they are not identical.

A researcher wants an efficient platform, fair triage, good communication and appropriate compensation. An enterprise customer may care more about coverage, reporting, integrations, remediation speed, compliance and predictable costs. As HackerOne expanded, the second list became increasingly important.

The platform did not stop evolving. It changed what it was trying to become

One of the weaker arguments in the original criticism of HackerOne is that the company simply stopped innovating. The public record does not support that. HackerOne continued to invest in new security products, expanded beyond traditional bug bounty and introduced AI capabilities. In 2024, the company appointed Kara Sprague as CEO after Mårten Mickos. HackerOne said at the time that its pentesting and AI red teaming business had grown 200% over the preceding 12 months, while vulnerability findings and hacker rewards had grown 120%.

The change was therefore not from “innovation” to “no innovation.” It was from one kind of innovation to another. The company increasingly focused on the larger vulnerability lifecycle: discovering weaknesses, validating them, prioritizing them and helping customers remediate them.

That is where CTEM enters the story. Continuous Threat Exposure Management is based on the idea that organizations should continuously understand their attack surface, discover exposures, validate what is actually exploitable, prioritize risk and drive remediation rather than treating security testing as a collection of periodic exercises. HackerOne now positions itself directly in that space. That is a substantial change from the HackerOne many researchers remember, but it also makes sense against the current security environment.

AI changed the economics of bug bounty hunting

The timing matters. Large language models did not simply make security researchers faster. They changed the cost of producing a vulnerability report. A skilled researcher can use AI to automate repetitive tasks, generate test cases, analyze application behavior, write scripts and explore larger portions of an attack surface. HackerOne itself now describes researchers using AI to amplify their existing capabilities. In its April 2026 analysis, the company argued that the important change was not a single autonomous model finding every vulnerability, but researchers using AI to scale their own expertise.

At the same time, AI made it dramatically easier for inexperienced people to produce vulnerability reports. That creates a difficult problem for bug bounty platforms. Suppose a platform previously received 10,000 submissions and 2,500 were valid. If AI causes submissions to rise to 40,000 while the validation rate remains roughly constant, the platform is not dealing with a simple increase in workload. It has to process an additional 30,000 reports while still identifying the same proportion of useful findings.

That is exactly the kind of workload that pushes a company toward automation. HackerOne says this is already happening. Its March 2026 data showed 46,947 submissions, a 76% year-over-year increase, while the validation rate remained around 25%. At the same time, the company said remediation throughput had increased only 19% and the backlog had reached an all-time high.

This is why the AI story cannot simply be reduced to “HackerOne wants to replace hackers.” There is a real operational problem. If AI increases vulnerability discovery, someone has to process those findings. A human-only triage operation may simply stop scaling. HackerOne’s answer is Hai.

Hai is much more than a chatbot

Hai began as a generative AI copilot, but HackerOne’s current architecture is considerably more ambitious. Its documentation describes agentic security testing as a multi-agent system in which specialized agents work across areas such as reconnaissance, authentication, vulnerability analysis and exploitation. The system can adapt its testing based on observations rather than following a fixed sequence of scanner checks.

A traditional vulnerability scanner might perform a predefined set of checks:

Target
  ↓
Enumerate
  ↓
Run signatures
  ↓
Match responses
  ↓
Generate findings

An agentic system can maintain context throughout an engagement:

Reconnaissance
      ↓
Understand application
      ↓
Identify authentication model
      ↓
Map reachable functionality
      ↓
Form testing hypothesis
      ↓
Execute test
      ↓
Observe result
      ↓
Update testing priorities
      ↓
Attempt validation
      ↓
Produce evidence

HackerOne says its agents can reason about authentication, architectural signals, response patterns, scope constraints and evolving risk during an engagement. That does not make the system infallible. HackerOne’s own terms explicitly warn that AI-generated output can be incorrect or misleading and should receive independent human verification where appropriate. The technical shift is nevertheless significant. HackerOne is no longer merely using AI to summarize reports. It is building AI into the actual security-testing workflow.

Then came the question researchers were bound to ask

If HackerOne’s AI systems process vulnerability reports, what happens to the information contained in those reports? This is where the debate became much more complicated than a simple accusation that HackerOne was “training AI on hackers.” The concern gained attention after changes to HackerOne’s terms were noticed by researchers. The original article describes the controversy around language concerning the use of researcher submissions and AI. The concern was understandable because vulnerability reports can contain extremely sensitive information.

A serious report may include:

• a previously unknown vulnerability;
• exploit steps;
• proof-of-concept code;
• authentication details;
• internal API behavior;
• application architecture;
• attack chains;
• security controls and their weaknesses.

That information can have enormous value.

A researcher is therefore entitled to ask a straightforward question: if my report is processed by an AI system, exactly what is being stored, where is it going, how long is it retained, and can it influence systems used elsewhere?

Training and inference are different things

This is where some of the public discussion has become technically imprecise. An AI model can process a confidential report without using that report to train the model. There is a fundamental distinction between training and inference.

During training, data is used to update model parameters. A simplified representation looks like:

Training data
     ↓
Model optimization
     ↓
Updated parameters
     ↓
New model

The training process can alter the weights of the model.

Inference is different:

Existing model
     +
Prompt/context
     ↓
Inference
     ↓
Output

The model uses the supplied information to generate an answer or take an action, but the information does not automatically become part of the model’s parameters. There are also intermediate mechanisms such as retrieval-augmented generation, application databases and workflow memory.

A system can therefore remember a previous decision in an application database and retrieve it later without retraining the underlying language model. The current HackerOne documentation explicitly says that customer and researcher data is used for inference, not model training.

HackerOne’s April 2026 responsible-AI statement says it does not train, fine-tune or otherwise improve generative AI or large language models using confidential customer or researcher data. It also says approved AI partners, including AWS Bedrock and Anthropic, are required to provide zero data retention and not use inputs or outputs for model training.

Its technical documentation goes further. HackerOne says researcher submissions and vulnerability data can be included as submission context when AI systems perform specific security workflows. That is an important admission because it confirms that researcher data can be processed by the AI system. At the same time, HackerOne says that this data does not flow into model training, fine-tuning or model weighting.

That means two statements can simultaneously be true:

HackerOne’s AI can process a vulnerability report.

That vulnerability report is not used to train the underlying generative model.

Calling the first statement “AI training” would be technically incorrect. Calling the second statement proof that the data has no influence whatsoever on HackerOne’s AI ecosystem would also be too broad.

HackerOne does use researcher data as context

This is the part that deserves much more attention than the training argument. HackerOne’s current responsible-AI documentation explicitly lists “Researcher submissions and vulnerability data and metadata” among the information its AI system processes to deliver security outcomes.

Its Agentic Testing documentation says broader platform data, including vulnerability reports from bug bounty and conventional pentesting programs, is not used to train or improve the generative models. It also says platform data is not available to agents conducting runtime offensive testing unless a user explicitly provides an existing HackerOne report as testing context, for example when performing remediation retesting.

That is a much more precise description of what is happening. The system can use a report to perform a task. The report can therefore affect the output of that particular workflow. What HackerOne says it does not do is turn that confidential report into model training data or use it to update the model’s weights.

There is still a legitimate data-governance question

The fact that HackerOne does not train a general-purpose model on researcher submissions does not eliminate every concern about data rights. The current Community Member Terms, effective May 11, 2026, govern researchers participating in HackerOne programs and submitting findings. The terms also contain provisions governing Community Member Data and the rights HackerOne receives to operate and develop its services.

This is where researchers should read the actual legal language rather than relying on social-media summaries.

The important question is not simply:

“Does HackerOne train GPT on my report?”

The better questions are:

“What rights does HackerOne receive over the data I submit?”

“What purposes are permitted under those rights?”

“Which information can be processed by HackerOne’s own AI systems?”

“Which information can be shared with AI infrastructure providers?”

“How long is the data retained?”

“Can it be used to improve HackerOne’s products without changing an underlying model?”

“Can it influence internal security intelligence, workflows, validation criteria or product development?”

Those questions matter because “training an LLM” is only one possible way information can create commercial value.

The wording around HackerOne’s security intelligence is interesting

HackerOne’s current product pages make a statement that deserves careful reading. Its H1 Validation product says Hai continuously routes and refines testing based on the customer’s environment, the customer’s prior H1 Bounty findings and 12+ years of real-world vulnerability data. That language understandably raised questions when researchers first encountered it.

But HackerOne’s technical documentation provides additional context. The company says its security intelligence is based on expert-developed frameworks, ongoing research and development, industry standards and experience from its researcher community, rather than by aggregating or reusing confidential customer or researcher data. It says those frameworks inform methodology, validation criteria, risk evaluation and other security workflows.

There is a substantial difference between:

“Here is a database containing every private report submitted by researchers, which our AI searches to discover vulnerabilities for other customers.”

and:

“Our security experts have developed methodologies based on years of security work, and those methodologies are encoded into our testing and validation systems.”

The current documentation supports the second description. It does not establish the first.

Why the controversy did not disappear after HackerOne’s clarification

The reason the issue continued is partly communication. HackerOne’s product language, legal terms and technical documentation did not always present the same concept in the same level of detail. Marketing copy tends to be short. Technical documentation has to explain architecture. Legal terms are written to establish contractual rights. Researchers read all three differently.

A phrase such as “12+ years of real-world vulnerability data” can easily be interpreted as meaning that historical confidential reports are being fed into an AI system. HackerOne later clarified that its agentic systems were not being trained on researcher submissions and expanded its technical documentation around how context is actually used.

That clarification is important, but so is the fact that researchers had enough reason to ask the question in the first place. For a company whose entire business depends on trust between security researchers and organizations, ambiguity is expensive.

The bigger change is happening inside triage

The AI debate also distracts from something more concrete: HackerOne is already automating parts of the bug bounty process. HackerOne says Hai handles initial classification, deduplication and validation of incoming reports on its own platform. The company says this is necessary because submission volume has increased dramatically.

Its current H1 Validation product describes a workflow in which AI agents ingest findings, normalize and deduplicate them, evaluate them against false-positive patterns and attempt live reproduction in the customer’s environment. Where automated coverage is unavailable, HackerOne says elite researchers provide expert review.

This is arguably a much bigger change to bug bounty than the question of whether an LLM is being fine-tuned.

Historically, a report might pass through a human triager before reaching the program’s security team.

Increasingly, the first layer may look like:

Researcher submission
        ↓
AI intake
        ↓
Classification
        ↓
Duplicate detection
        ↓
Scope analysis
        ↓
Validation
        ↓
Human review when required
        ↓
Customer

The consequences are significant.

A researcher is no longer necessarily interacting with a human at the first stage of the process. That could improve response times and consistency. It could also make the platform feel less personal, especially when a complex report is reduced to a classification decision.

Both things can be true.

The AI problem is bigger than HackerOne

There is also a danger in treating HackerOne as though it created the problem.

It did not.

The entire bug bounty industry is dealing with an explosion in AI-assisted security research.

The Financial Times reported in 2026 that bug bounty platforms were dealing with large increases in AI-generated submissions, many of which were low quality or false. It also reported that researchers using AI effectively were becoming more productive, creating a difficult split between genuine AI-assisted research and automated report generation.

AI does not simply produce “good hackers” and “bad hackers.” It reduces the cost of producing both good work and bad work. A skilled researcher can use an AI system to automate repetitive analysis and spend more time reasoning about difficult attack paths. Someone with little security knowledge can use the same technology to generate dozens of speculative reports.

The platform sees both.

That is why HackerOne’s 25% validation figure matters. The company says the percentage of valid, exploitable vulnerabilities has remained relatively stable even as total submission volume rose sharply. The challenge is not necessarily that every new report is useless. The challenge is that there are far more reports to process.

That changes the economics of triage

Consider what happens when a researcher finds a serious vulnerability manually.

The researcher may spend hours or days:

• understanding the application;
• identifying an attack surface;
• finding the vulnerable behavior;
• confirming exploitability;
• developing a proof of concept;
• writing the report.

A platform’s triage team then has to repeat part of that work. The report must be checked for scope, validity, duplication, severity and impact. If AI reduces the cost of producing reports but does not reduce the cost of reviewing them, the system becomes unstable.

That is precisely why AI-assisted triage is economically attractive.

HackerOne’s position is straightforward: if AI increases discovery, the validation side also needs to scale. Its April 2026 analysis describes Hai as handling initial classification, deduplication and validation alongside human security analysts.

This is less sinister than it sounds. It is also more consequential than it sounds. Because once AI becomes part of triage, the platform begins making decisions about what humans see, what gets escalated and what receives attention. That makes the quality of those systems extremely important.

The researcher problem is really an incentive problem

The hardest question facing HackerOne is not whether AI can validate a bug. It clearly can do some of that. The harder question is who benefits when a researcher’s knowledge becomes reusable at scale.

Suppose a researcher discovers a novel way of identifying a particular class of authentication flaw. Today, the researcher may receive a bounty for the individual vulnerability. Now imagine that the same conceptual approach can be incorporated into an automated testing workflow and applied to thousands of applications.

The economic value of the original discovery has changed. The original report may have been worth one bounty. The technique could eventually influence thousands of security decisions.

HackerOne co-founder Michiel Prins has publicly described a possible future in which a researcher discovers a novel technique, HackerOne operationalizes that technique across customer attack surfaces, and the researcher receives compensation for the wider impact. The company describes that model as a future vision rather than something already implemented.

That idea deserves more attention. It could solve a problem that the traditional bug bounty model was never designed to address. The old model rewards individual findings. An AI-driven security ecosystem may need to reward research contributions that become reusable capabilities.

That would require an entirely new attribution and compensation system.

It would also create difficult questions around causality. If three researchers independently discover similar techniques, who gets credit? If an AI system independently finds a vulnerability using a technique already published by a researcher, how much credit belongs to the researcher? If a platform develops a generalized methodology from thousands of public reports, can that methodology reasonably be attributed to any individual?

There are no easy answers.

But these questions are likely to become more important as AI becomes better at security research.

HackerOne’s current position is clear: humans remain part of the model

It would be unfair to describe HackerOne’s current strategy as a plan to remove human hackers. The company repeatedly says the opposite. Its April 2026 responsible-AI statement describes the objective as human judgment amplified by AI. It says consequential actions remain subject to human oversight and that its agents maintain audit trails.

Its current documentation also describes human security researchers as part of the validation process when automated coverage is insufficient. The company still runs Live Hacking Events and continues to market its researcher community as a major part of its security offering.

The question is therefore not whether humans remain. The question is what role they will occupy. That role could become more valuable.

If AI handles enumeration, repetitive validation and routine analysis, experienced researchers may spend more time on the difficult problems that machines struggle with: novel attack chains, business logic, unusual trust boundaries, architectural weaknesses and vulnerabilities that require understanding how a system is actually used.

But there is another possibility.

If the platform increasingly owns the workflow, controls triage and supplies automated testing to customers, researchers could gradually become one source of security intelligence among many. That would be a very different relationship from the HackerOne of 2016.

The company itself is now dealing with a different bottleneck

HackerOne’s latest data makes the transformation easier to understand. The company says the volume of vulnerability discovery has increased 76% year over year, while remediation throughput has increased only 19%. Critical and high-severity findings account for 32% of validated findings, compared with a historical range of 26% to 28%.

In other words, the problem is no longer simply finding vulnerabilities. There are already too many findings for many organizations to process comfortably. That is the strategic logic behind HackerOne’s move toward validation and CTEM. The security industry spent years optimizing discovery. AI is now making discovery even faster. The bottleneck is moving downstream.

Organizations need to know which findings are real, which ones matter, which ones can actually be exploited, how they should be prioritized and whether the fix worked. That is exactly the problem HackerOne is positioning itself to solve. From a business perspective, it is a logical expansion. From a researcher perspective, it changes the center of the marketplace.

So, did HackerOne lose its way?

That depends on what you think HackerOne was supposed to be. If HackerOne’s identity was primarily the company that brought hackers together, ran legendary Live Hacking Events and built a community around bug bounty research, then the modern company is clearly different.

If HackerOne’s mission is to help organizations continuously discover and remediate security vulnerabilities, the current strategy is a natural extension of the original idea.

Both interpretations can coexist.

The company has not disappeared. It has not stopped working with researchers. It has not abandoned bug bounty. It has not, based on the evidence currently available, secretly trained a general-purpose AI model on private researcher submissions.

What has happened is more subtle. HackerOne has moved from being primarily a marketplace for human vulnerability discovery toward becoming a security platform that coordinates humans, software and increasingly autonomous AI systems across the vulnerability lifecycle.

That is a major change.

The real trust issue is bigger than model training

The most useful way to look at the current controversy is to stop treating “AI training” as the only question. A researcher should care about the complete data lifecycle. When a vulnerability report is submitted, what information is collected? Where is it stored? Which internal systems can access it? Which AI systems can process it? What is retained? What is deleted? Can the information be used for product development? Can derived knowledge be reused? Can it influence automated workflows? Can the researcher opt out? What happens when a customer asks for a report to be used in a future retest?

Those are much more meaningful questions than whether a model’s weights changed.

HackerOne has now published considerably more documentation addressing these issues than it had when the controversy began. Its current position is that researcher and customer data may be processed to perform authorized AI workflows, but is not used to train, fine-tune or otherwise improve the underlying generative models or agents. The company says its AI partners are similarly restricted from using the data for their own model training.

That is a concrete position.

Researchers can agree with it or remain uncomfortable with the broader data rights granted to the platform, but the distinction should be made accurately.

HackerOne’s next challenge is not technological

The technology is moving quickly enough. The difficult part will be trust. HackerOne built its original reputation by creating a trusted relationship between companies and people who were willing to find their security problems. That relationship depended on a fairly simple bargain: researchers find vulnerabilities, companies pay for useful discoveries, and the platform provides the infrastructure that makes the exchange possible.

AI complicates that bargain because information can now be reused at a scale that was previously impossible. A researcher who spends a week discovering something novel may create an insight that can potentially be encoded into an automated system and applied repeatedly.

That does not mean HackerOne is currently doing that with confidential researcher reports. Its current documentation explicitly says it is not. But the industry is approaching the point where the question will become unavoidable anyway. If human researchers create the discoveries, AI provides the scale and the platform controls the marketplace, how should the value be divided? That may ultimately be the defining question for the next generation of bug bounty platforms.

What happened to HackerOne?

HackerOne did not simply collapse. It grew up. The company that once distinguished itself through hacker culture and Live Hacking Events is now trying to become infrastructure for continuous security testing. The venture capital, enterprise market, changing pricing model, AI boom and growing volume of vulnerability submissions all pushed it in that direction. Its current products reflect that strategy clearly.

For researchers who preferred the old HackerOne, that evolution can feel like a loss. For enterprise security teams drowning in vulnerability data, the same evolution may look like a necessary response to reality. Both views have some merit.

The real test will be whether HackerOne can expand into AI and continuous testing without weakening the trust that made the platform valuable in the first place. That means being precise about researcher data, transparent about how AI systems use context, honest about what is automated, clear about where humans remain responsible, and eventually finding a fair way to recognize researchers when their discoveries create value far beyond a single bounty.

The original HackerOne succeeded because it gave hackers a reason to participate. The next version will have to give them a reason to stay and that may be the hardest part of the company’s transformation.