GitHub will start paying some bug bounty hunters in swag instead of cash
Bug bounties have served as one of cybersecurity’s core pressure valves for decades, giving independent researchers a structured way to disclose vulnerabilities before attackers can exploit them. But a deluge of AI-assisted reports is upending parts of that system.
GitHub announced last week that it’s tightening standards across its bug bounty program as submission volumes rise sharply alongside the growing use of AI tools in security research.
In a blog post, Jarom Brown, senior product security engineer for GitHub’s bug bounty program, said the company was seeing a growing number of submissions that lacked proof-of-concept validation, demonstrated impact, or clear evidence that an exploitable security boundary had actually been crossed.
“Programs across the industry are grappling with the same challenge, and some have shut down entirely,” Brown writes.
The AI slop deluge
GitHub stressed that it was not opposed to researchers using AI. In fact, the company said it expected AI to become increasingly central to modern security research workflows. The problem, according to GitHub, is the growing volume of speculative or poorly validated reports generated with AI assistance.
“The tools don’t matter. The quality of the work does.”
“The tools don’t matter,” Brown continues. “The quality of the work does.”
The news comes a week after Anthropic launched its first public HackerOne bug bounty program, opening its security reporting pipeline to external researchers after previously relying on more tightly controlled safety-testing efforts.
That launch itself came only weeks after Anthropic unveiled Claude Mythos and Project Glasswing, a restricted-access cybersecurity initiative centered around a more advanced frontier model the company claims can identify and chain together software vulnerabilities more effectively than its current public systems.
Anthropic positioned Mythos as part of a broader effort to strengthen defensive cybersecurity capabilities before more powerful offensive AI tooling becomes widespread. Yet the company’s simultaneous expansion into a conventional human-led bug bounty program also highlighted a growing tension inside the AI security industry: even as companies market capable autonomous cyber systems, there’s still a clear reliance on human researchers to identify, validate and reproduce real-world vulnerabilities.
Proof-of-concept now required
Under the updated standards, GitHub says researchers will now face stricter requirements around working proof-of-concept demonstrations, demonstrated security impact, validation of scanner or AI-generated findings, and adherence to GitHub’s published list of ineligible vulnerabilities.
Reports that identify low-risk hardening opportunities or documentation gaps may also no longer qualify for cash rewards. Instead, GitHub says some lower-severity findings that still result in fixes will receive company swag rather than bounty payouts.
The company also urged researchers to make submissions shorter and easier to verify, arguing that overly elaborate reports were making it harder for security teams to identify genuinely exploitable findings. And yes, part of the problem again is down to AI.
“The clearer and more direct your report, the faster we can act on it.”
“Verbose reports such as multi-page theoretical narratives, restated background context, or AI-generated filler slow down triage because the actual finding gets buried,” Brown writes. “The clearer and more direct your report, the faster we can act on it.”
cURL’s earlier warning
GitHub’s comments follow growing frustration across parts of the open source security community over what has come to be known as “AI slop” bug reports. In January, Daniel Stenberg, founder and lead developer of the open source data transfer tool cURL, said the project would shut down its bug bounty program after maintainers became overwhelmed by low-quality AI-assisted submissions.
“We are effectively being DDoSed,” Stenberg wrote at the time. “If we could, we would charge them for this waste of our time. We still have not seen a single valid security report done with AI help.”
Stenberg later clarified that he was not opposed to AI-assisted security research itself, pointing to examples where researchers had successfully used AI tooling to uncover legitimate bugs and code issues. His criticism focused on poorly validated submissions generated in pursuit of bug bounty payouts.
And this aligns with GitHub’s position. The company emphasizes that AI-assisted findings remain welcome — provided researchers validate them properly before submission.
“The human researcher is accountable for the accuracy of the submission.”
“The human researcher is accountable for the accuracy of the submission,” Brown writes.
Where GitHub draws the line
GitHub’s post devoted significant attention to what it described as misunderstandings around the platform’s security boundaries, particularly involving AI tools, malicious repositories and prompt injection attacks.
The company argues that many reports involving harmful AI outputs or malicious repositories often fall under what it calls a “shared responsibility model.” GitHub says users remain responsible for deciding which repositories, scripts, workflows and AI-generated outputs they trust or execute.
“When an ‘attack’ requires the victim to actively seek out and engage with attacker-controlled content,” Brown writes, “the security boundary is the user’s decision to trust that content.”
GitHub points to several examples of what it generally doesn’t consider to be bounty-eligible vulnerabilities, including prompt injection attacks involving content deliberately fed into AI systems, malicious Git hooks inside cloned repositories, and AI tools producing dangerous outputs after processing untrusted inputs.
The distinction is important because prompt injection attacks and malicious AI-generated code have become central concerns as AI coding agents grow more autonomous and more deeply integrated into software development environments.
For GitHub, the line appears to be whether an attacker bypassed an actual GitHub-controlled security boundary — or simply convinced a user to trust hostile content.
