Bug Bounty Alternatives: What AI Security Testing Replaces, and What It Doesn't

A bug bounty tells you what somebody happened to find. It does not tell you what nobody looked at.

That distinction is the whole question behind this page. Teams shipping several times a week increasingly ask what an AI-driven alternative to a bounty programme looks like, and the honest answer is that the two are not substitutes in most of the places people assume they are. A bounty is an open invitation to researchers within a defined scope, without requiring them to follow a fixed testing schedule. Continuous offensive testing is a bounded, repeatable exercise that runs whether or not anyone finds your application interesting this week. Each is good at something the other is structurally unsuited to.

What follows is what each model actually covers, where the boundaries fall, and what an evaluator should ask before replacing one with the other.

What a bug bounty is genuinely good at

Start with the case for keeping one, because it is stronger than most replacement pitches admit.

A bounty buys access to attacker diversity: people with different backgrounds, tooling and instincts can investigate the same application. They are not constrained by the assumptions of the team that built it. That matters, because your threat model encodes your assumptions, and the interesting bugs tend to live exactly where an assumption was wrong. An internal team, or a tool configured by that internal team, can inherit some of the same assumptions the application was built with. An external researcher brings a different set of assumptions and incentives.

It also pays for outcomes rather than effort. You are not buying testing hours, you are buying findings, and a quiet month costs nothing. For an application with a large, mature, public surface, that is hard economics to argue with.

And it does not normally require a scheduled testing window for every researcher. Someone may look at your password-reset flow on a Tuesday in March because they decided to investigate it.

None of that should be assumed to disappear just because automation gets better. A vendor claiming that an automated system completely replaces external attacker diversity should be able to demonstrate that claim, not just assert it. The question is not whether a bounty finds real bugs. It is whether a bounty is the right instrument for the parts of your application you actually need assurance on.

Where the model's boundaries are

These are properties of the model, not failures of any platform running it.

Coverage is chosen by the researcher, not by you. A programme defines a scope, but within that scope nobody is obliged to look anywhere in particular. Researchers have to allocate their limited time somewhere, so effort naturally follows the expected value of a finding relative to the work required to discover it. That can leave functionality that is expensive to understand or validate with less researcher attention than a simpler, more immediately testable surface. Billing logic and permission models can fall into that second category because understanding them often requires more application context than testing a single endpoint. That is where business logic vulnerabilities can arise.

There is no completed state. A point-in-time engagement can give you a defined record of what was tested during a defined period. A conventional bounty, by contrast, does not inherently tell you that a particular flow was systematically checked after your latest change. Silence remains ambiguous: either nobody found a vulnerability, or nobody investigated that path deeply enough to find one.

Duplicate handling shapes what gets reported. HackerOne's own documentation describes closing a report as a duplicate of an earlier one, with the second reporter shown only high-level metadata unless the programme explicitly adds them to the original. Bounty eligibility for duplicates depends on the programme's rules. In many programmes the first valid report receives the primary reward, but HackerOne's current guidance also recognises cases where a later report adds meaningful attack paths, evidence or remediation insight and should receive additional compensation. Where duplicate rewards are limited, researchers have an economic reason to prioritise areas where they believe they can establish a distinct finding rather than simply reproduce something another researcher has already reported. Your well-trodden critical paths are the ground everyone else is standing on.

Multi-tenant testing needs an arrangement, not a discovery. Establishing whether organisation A can reach organisation B's records requires multiple identities with known permission levels. Bounty programmes such as HackerOne and Bugcrowd can provision these accounts, but the available authenticated context and test infrastructure varies by programme.

The models side by side

None of those rows is a criticism of the others. They describe different purchases. Continuous pentesting sits in the last row, and it is the only one whose value depends on being wired into how you ship.

The bounty platforms are shipping this too

It would be convenient to frame this as crowd against machine. That framing is already out of date.

On 26 January 2026 HackerOne announced Agentic Pentest as a Service, which it describes as combining "autonomous agent execution with elite human expertise", with agents covering reconnaissance, setup, exploitation and validation across a large attack surface while human experts provide validation. In the same announcement it takes a clear position on the fully autonomous end of the market, saying such tools promise speed but often deliver "shallow, unverified results that create noise rather than insight". Synack describes a comparable pairing of an agentic engine with its own researcher pool on its blog.

That criticism deserves a straight answer rather than a rebuttal, because it is the right question to put to any autonomous platform: what makes a finding trustworthy when no human has checked it?

For us, the useful distinction is not the confidence score. It is whether the system attempted the relevant action and observed what happened. A finding that says a pattern matched is a candidate. A finding that says this request, sent as this user, returned another organisation's record, is an observation, and it arrives with the steps to reproduce it. The engineer receiving it does not have to trust the tool. They have to run four lines and watch. Where a suspected weakness cannot be exercised against the running application, it should be reported as exactly that, rather than promoted to the same confidence as one that was.

So the useful evaluation question for anything in this category, Borg included, is not how autonomous it is. It is: what did reading the code contribute to the exploit you are showing me, and what did the running system contribute?

What an automated platform actually takes over

The parts of a bounty's output that continuous offensive testing genuinely displaces are the systematic ones. Enumerating every endpoint that resolves a record by an identifier supplied by the caller, then checking which of those carry an ownership check, is patient work rather than creative work. So is re-checking the same authorisation paths after every change.

That is where Borg's Mjolnir runs. It reads the repository to decide which paths are worth attacking, executes against the running application, reports findings with reproduction steps, and retests once a fix lands. Gungnir applies a narrower version of that approach to pull requests, reviewing security-sensitive changes before they reach production. Huginn handles continuous asset discovery and monitoring of the external attack surface as it changes. Findings collect in Odin, which is the dashboard the other three report into.

What does not transfer is the part that made the bounty worth having. An unfamiliar mind with no stake in your assumptions, chaining two harmless behaviours into one that is not harmless, is not a scheduling problem. The important question is therefore how far each platform has actually solved it, and what evidence it provides for that claim.

One further limit worth stating plainly: code-aware testing can only reason from what is represented in the code and the context supplied to the system. A permission set configured only in a cloud console, a third-party service configured through its own dashboard, or an invariant that exists only in someone's head may be outside what repository analysis can tell you.

What to ask before you switch

Five questions that separate the platforms in this category from each other, and that a vendor should be able to answer without reaching for a case study.

What did reading the code contribute to this finding? Ask it about a specific finding, not in general. The useful answer names something the repository revealed that crawling would not have: an unlisted route, an authorisation helper applied to nine handlers out of eleven, a version of the API still in service. If the answer is that code access improves coverage generally, code access is not doing much.

What happens to a suspected issue that cannot be reproduced? You want it reported as unproven, or dropped, rather than shipped at the same severity as one that was reproduced against the running system. A platform that presents both with equal confidence has moved the triage work back onto you and called it coverage.

How do you test something that needs two accounts? Tenant isolation, role escalation and cross-organisation access all need more than one identity at known permission levels. If the platform cannot describe how it establishes that, it is not testing the boundary that does the most damage when it fails.

What happens after we fix it? A finding is not closed because a ticket moved. Ask whether the fix is retested automatically, and what state the finding lands in if the retest fails.

Where does the output arrive? A finding in a portal your engineers do not open is not much better than a PDF. Ask which trackers it writes to, what triggers a ticket, and who can change a finding's state from the tracker side.

None of these is a trick question, and any vendor you are seriously evaluating should be able to answer all five directly. Vague answers are particularly revealing when they concern evidence, authentication, reproduction and retesting, which are the parts of the workflow that decide whether a finding is actionable at all.

Choosing between them

The question is not which model is better. It is which failure you cannot live with.

If the failure you fear is a boundary you rely on breaking quietly, tenant isolation, an authorisation check on a refactored route, or a billing state reachable out of order, then the control that fits is systematic testing of those paths on a cadence you set.

If the failure you fear is an attack path your team did not anticipate, external researchers provide a form of attacker diversity that automated testing does not automatically reproduce. That remains a strong reason to keep a bounty alongside automation.

If what you need is a formal assessment tied to a defined scope and testing period that you can hand to a customer or auditor, a point-in-time engagement may still be the most appropriate instrument.

Many organisations use more than one of these models because they address different assurance needs. A sensible approach is often to cover the paths you can name first, because those are the ones you can test systematically, and use external researchers to challenge the assumptions you cannot fully enumerate. Once findings exist, where they land matters as much as what they say, which is why the route from finding to ticket and verified fix is worth deciding before you pick the model that generates them.

Conclusion

A bug bounty and a continuous offensive platform answer two different questions. A bounty tells you what researchers reported. A continuous offensive platform can give you repeatable evidence about the paths it was configured and able to test at a particular point in time. Teams often start looking for a complementary control when they realise they have been using a bounty to answer a coverage question it was never designed to answer systematically.

Borg tests the exploitability layer, auth flows, APIs, access control, tenant isolation and business logic, continuously and with the repository as context, and delivers findings with reproduction steps into the tracker your engineers already use. Book a walkthrough to see what that turns up against your own application.