GitHub's Bug Bounty Restructure Answers AI-Generated Reports With a Price, Not a Filter

Starting today a critical finding pays $10,000 in GitHub's public program and $30,000 or more in the invite-only tier. Nothing in the new rules attempts to detect a machine-written report.

As of today, a critical vulnerability in GitHub is worth $10,000 if you are a member of the public and $30,000 or more if GitHub already knows your name. Same bug. Same proof of concept. The variable is your track record.

That is the design, and GitHub says so in a single sentence. Catherine Cassell's announcement on July 22 puts it plainly: "you don't earn more by submitting more. You earn more by submitting better." Reports filed on or after July 27, 2026 get assessed under the new structure. Everything already in the queue is grandfathered under the old one.

Read the mechanism instead of the payout table and something more interesting shows up. GitHub has a machine-generated report problem. It built no machine-generated report detector. It changed the price of submitting instead.

What actually shipped

Two tables and a gate.

The public program moves to static payouts: $250 low, $2,000 medium, $5,000 high, $10,000 critical. No ranges anywhere. GitHub's stated reasoning is that ranges "sound flexible" but in practice create uncertainty for researchers and overhead for triage, and that discretionary bonuses stay available for work that goes past the bar. Help Net Security reads the new numbers as a cut of roughly half or more at every severity, which they are.

The permanent VIP program is private and invite-only, paying $1,000, $7,500, $20,000, and $30,000 or more across the same four severities. The entry ladder is published as a floor: one critical finding, or two highs, or four mediums, or seven lows. Full criteria are promised on GitHub's HackerOne page. VIP members also get faster response times and direct contact with GitHub's security engineering team, which for a serious researcher may matter more than the money.

The gate is a HackerOne Signal requirement on the public program. Researchers below the threshold get up to four initial submissions to establish a track record. Cassell frames it as runway rather than a wall, and names the target directly: "the volume of low-effort and AI-generated reports."

Four submissions is not much runway. It is also exactly enough to make submitting garbage expensive, because a report closed as Not Applicable damages the Signal you need in order to keep submitting at all. The cost of a bad report used to be your own wasted afternoon. Now it is your ability to file the next one.

The half of this story that ran in May

The July announcement is the visible piece. The policy it implements landed two months earlier, in a post by Jarom Brown that is far more specific about what GitHub will and will not pay for.

Brown's position on AI is not the one the headlines suggest. "We have no problem with researchers using AI tools," the post says, and GitHub uses AI across its own internal security programs. The standard is validation. An AI-assisted finding that has been verified, reproduced, and submitted with a working proof of concept is a good submission. Unvalidated model output pasted in as-is is not. GitHub applies the same rule it has always applied to scanner output and static analysis: the human researcher is accountable for accuracy. The tool is not the issue. Ownership of what the tool produced is.

Then comes the section worth your attention if you build with agents.

GitHub publishes a shared responsibility table, and one row of it reads: prompt injection via content the user chose to feed to an AI tool, why it falls under shared responsibility, "the user decided to trust that content." Another row: an LLM producing unexpected output when processing untrusted input, "the user chose to provide that input." Two more cover git hooks executing in a repo you checked out and malicious content in a repo you cloned. Cloning, GitHub writes, is an act of trust.

The company hosting over 600 million repositories is stating on the record that deciding which of them to feed your agent is your job. If you point a coding agent at a hostile repository and the agent does something you did not want, GitHub's position is that no GitHub security control was bypassed, so there is no bounty behind it.

I think that call is defensible. I also think most teams have not priced it in. There is no vendor patch coming for this one, and no argument to be had at triage time.

Put this into practice

If you submit to GitHub, three things change your outcome this week.

Read the ineligible findings list and the scope page before you write a word. Reports covering known-ineligible categories close as Not Applicable, and that hits your Signal, which is now the gate on everything else. DMARC and SPF configuration, user enumeration, and missing security headers with no demonstrated attack path are all named examples.

Ship one working proof of concept instead of three theoretical writeups. GitHub's stated format is short: a summary of the issue, reproduction steps with evidence such as screenshots or HTTP requests, and an impact statement naming what an attacker actually achieves. Brown singles out multi-page theoretical narratives and AI-generated filler as things that slow triage precisely because the real finding gets buried in them.

Know what pays. Valid submissions that lead to a code or documentation fix without demonstrating meaningful security impact now earn GitHub swag rather than a bounty. That is not a trick, it is a published rule, and it should change how you allocate a weekend.

If you run any inbox that AI made cheap to flood, the transferable move is the one GitHub made. It did not try to classify submissions by origin, because at triage speed nobody reliably can. It attached a cost to the act of submitting and let reputation do the sorting. That pattern generalizes: support queues, drive-by pull requests, grant applications, hiring pipelines. Price the submission, do not fingerprint the submitter. A reputation gate has the useful property of being right about incentives even when it is wrong about any individual case.

And if you ship agents, treat the shared responsibility table as a design document. Every row marks a place where the platform has told you the failure is yours to contain. Sandbox the checkout rather than trusting the repo. Scope the token to the task rather than the user. Decide what your agent is permitted to read before it reads it, because after it reads it you are already past the boundary GitHub drew.

Where this gets uncomfortable

The signal gate is circular for newcomers. You need Signal to submit freely, and the fastest way to lose Signal is to submit something that closes as Not Applicable, which is exactly what a new researcher misjudging scope will do. Four submissions is enough runway for someone with a real finding and a careful read of the scope page. It is not enough for someone learning the craft by trying things.

The payout cut is a payout cut. GitHub frames the whole restructure around report quality, and the effect on a legitimate public-program researcher who has never touched an AI tool is a smaller check for identical work. The VIP tier restores the money, for people who clear a bar that today is described in outline rather than published in full.

GitHub also gives no numbers. The May post says submission volume grew "significantly" and that low-impact submissions rose "sharply." No percentage, no report counts, no breakdown of how much of the queue is machine-written. A company asking researchers for evidence-backed submissions is describing its own problem in adjectives. Fair is fair.

And the shared responsibility boundary is genuinely contested. The industry has not settled whether prompt injection against a user's own tooling is a platform's problem, and GitHub's answer happens to be the one that costs GitHub nothing. The reasoning holds together on its own terms. That does not make it the last word, and it is worth watching whether other platforms adopt the same line or draw it somewhere more expensive for themselves.

What to do with this

A bug bounty is a small market with a very clear signal running through it. AI made producing a plausible-looking security report nearly free, and the first serious platform response is not detection. It is a reputation price, plus a narrower definition of what counts as GitHub's problem in the first place.

Both halves of that will reach whatever you work on. If you are on the receiving end of AI-cheapened volume, you have a worked example of a response that never requires you to guess which text a model wrote. If you are on the sending end, the bar moved: fewer submissions, better ones, a proof of concept every time.

Start with the ineligible list. It is the highest-value ten minutes in this entire story, and it costs nothing.

Sources: GitHub Blog, "Next chapter: Restructuring GitHub's bug bounty program" (Catherine Cassell, July 22, 2026); GitHub Blog, "Raising the bar" (Jarom Brown, May 15, 2026); GitHub Bug Bounty scope and ineligible findings; Help Net Security.