Intel just stopped paying for bugs. The top reward was $100,000. The new reward is a thank-you note.
The change surfaced on Friday, September 19, 2026.
Intel's page on the Intigriti platform now describes a responsible disclosure program without bounties, and a check of the board shows the old paid program listed as suspended.
Intel gave no reason and made no announcement. The page simply changed.
That is a strange thing for the largest x86 chipmaker to do quietly, and the reason it did is the actual story. It is not about Intel's budget. It is about a shift in where the hard part of security now lives.
Why this lands on a code-review company's blog: the bottleneck that broke these programs is triage, which is the work of telling a real vulnerability from a plausible-looking false one. CodeAnt AI does that work at the pull request, before a report is ever written. This article explains the shift, then where automated review fits it.
What Happened to the Intel Bug Bounty Program
The facts first, separated from the interpretation, because the interpretation is where this gets interesting.
Intel's bounty program launched invite-only in 2017 and opened to all researchers in 2018, covering software, hardware, firmware, and open-source projects. It paid based on report quality and severity, with awards documented from $500 up to $100,000.
It mattered to Intel's own security posture. The company has said that 105 of the 231 CVEs it addressed in 2020, almost half, came through the bounty program.
The reward structure was tiered.
Tier | Reward range |
|---|---|
Tier 1 | $2,000 to $100,000 |
Tier 2 | $1,000 to $30,000 |
Tier 3 | $500 to $10,000 |
Tier 4 | $250 to $5,000 |
The timeline into suspension is quick and worth reading closely. Intel expanded the program's scope to include web services in the second half of 2025.
Then on a January 6, 2026 update, the company said it was evaluating "enhanced bounty and bonus criteria." Eight months later, the program is suspended. Researchers can still submit vulnerabilities through the replacement program. It just pays nothing for them.
Intel is Not the First, and That is the Whole Point
If this were only Intel, it would be a cost-cutting footnote from a company that has had a visibly difficult year. It is not only Intel. curl closed its bug bounty program in 2026, with maintainers citing a flood of AI-generated reports that consumed triage time and produced nothing.
HackerOne paused the Internet Bug Bounty program effective March 27, 2026. The stated reason, in the program's own words, was that AI-assisted research is expanding vulnerability discovery across the ecosystem, increasing both coverage and speed. The program continued paying queued submissions and stopped taking new ones.
Three independent, well-run programs, at a chipmaker, an open-source project, and a platform, all reaching the same decision inside a few months. That is not three budgets tightening. That is a structural change in the economics of a bug bounty, and it has a single cause.
What is AI Slop, and Why it Broke Bug Bounties
AI slop is low-quality, machine-generated content produced at volume with little human oversight. In a security context it has a specific and damaging form. A plausible-looking vulnerability report, generated by a language model, describing a bug that does not exist or cannot be reproduced.
The reason it is corrosive is not that any single report is hard to dismiss. It is the ratio. A bug bounty program is an inbox. Before AI, the scarce and expensive input was a researcher capable of finding a real bug, and the volume of reports was naturally limited by that scarcity.
Triage was tractable because the flow was human-limited. Generative models removed the limit on the input without improving the quality. Anyone can now generate a hundred well-formatted, confident, entirely wrong vulnerability reports in an afternoon.
Each one still has to be read and refuted by a skilled human, because the one in a hundred that is real cannot be allowed through. The maintainer signal is unambiguous. On the Linux kernel, CVEs have approached 2,000 per release, roughly a fourfold increase, with maintainers describing themselves as completely overwhelmed.
Linus Torvalds has said that duplicate AI reports on the kernel security list are almost entirely unmanageable. That is the sentence that explains Intel, curl, and HackerOne together. The cost of producing a report collapsed. The cost of refuting one did not.
The Bottleneck Moved, and Most People are Looking At the Wrong End
Here is the reframe that the celebratory coverage of AI-powered offense keeps missing.
For thirty years, the scarce resource in security was finding the bug. Offense was hard, expensive, and slow. The entire bug bounty model was built to pay for that scarcity, to route rare talent at hard problems and compensate it when it succeeded. AI did not make offense expensive. It made offense cheap. And in doing so it moved the scarce resource one step downstream, from finding bugs to telling which ones are real.
Before cheap AI offense | After | |
|---|---|---|
Cost to find a candidate bug | High, rare skill | Near zero, automated |
Volume of reports | Human-limited | Effectively unlimited |
Cost to verify one report | Moderate | Unchanged, still a skilled human |
The bottleneck | Discovery | Triage and verification |
What a bounty pays for | The scarce thing | No longer the scarce thing |
A bug bounty pays for discovery. When discovery stops being scarce, the model is paying for the wrong thing, and the thing it is not paying for, verification, is now the constraint.
That is why suspending the payout is a rational response rather than a stingy one. The payout was solving a problem that no longer exists, while the real problem sat unfunded in the triage queue. Offense did not get expensive. Defense stopped being able to afford the triage that cheap offense created.
Why "AI Finds More Bugs" is the Wrong Headline
The dominant narrative in AI security right now is a celebration of discovery. A model found a vulnerability class at scale. An agent chained an exploit. Coverage is up, speed is up.
All true, and all beside the point for a defender, because a found bug is not a fixed bug and a reported bug is not a real bug. Between discovery and remediation sits verification, and that is precisely the step generative volume has overwhelmed.
There is a concrete illustration from the same period. OpenAI paid researchers a $6,500 bounty for an exploit chain, and the discovery used a rival lab's model as a tool. AI-assisted discovery is genuinely productive.
The point is not that the reports are all worthless. The point is that separating the $6,500 chain from the ninety-nine confident hallucinations around it is now the expensive part, and no amount of additional discovery helps with that.
The useful question is not how do we find more bugs. It is how do we raise the ratio of real to plausible before a human has to adjudicate it.
Where Verification Actually Belongs
If the bottleneck is telling real from plausible, the leverage is to answer that question as early as possible, on the cheapest possible artifact, before a report is ever written.
The earliest artifact is the code change itself. A vulnerability enters a codebase in a pull request. That is the first moment it exists, the moment it is cheapest to catch, and the moment the surrounding context, the diff, the intent, the adjacent code, is richest.
Catching it there inverts the entire economics described above. Instead of a real bug escaping into production, being discovered later by an external researcher or an automated scanner. And arriving as one report among a hundred that a human must sift, it is found and ranked at the point of introduction, by a reviewer that has the full context of the change.
This does not eliminate external research, and it should not. It changes what reaches the triage queue, by removing the class of real bugs that never needed to become external reports in the first place. And by giving the team a verified, ranked view of what is genuinely wrong in their own code rather than a queue of unverified external claims.
How CodeAnt AI Addresses the Triage Problem
Three capabilities map directly onto the shift this article describes.
Finding the real bug in the pull request. AI code review analyses each change with the context of the surrounding code, surfacing security defects at the point of introduction rather than after they ship. This is verification moved to the earliest and cheapest artifact, which is exactly where the economics favour the defender.
Ranking, not just flagging. The problem with generative volume is undifferentiated output. The AI penetration testing pipeline scores findings deterministically by severity, by the value of what they touch, and by proximity to real data, so the output is an ordered list of what matters rather than an undifferentiated pile. That ordering is the missing function in an inbox full of slop.
Proof over plausibility. The deliverable is the confirmed exploit path, not the flagged possibility, on the principle that a detected vulnerability is not a confirmed leak. More than 500 agents chain findings to demonstrate what an attacker actually reaches. A report that carries proof does not need a human to adjudicate whether it is real, which is the single most expensive step in the current model.
The track record is the relevant credential here.
CodeAnt has found 150+ CVEs, including a CVSS 10.0 vulnerability in pac4j that went undetected for six years, across projects representing 2B+ monthly downloads protected. That last figure is the point in miniature. A maximum-severity flaw sat for six years in reviewed, open-source, widely deployed code.
It was not found by generating more reports. It was found by examining the code carefully, which is the capability that scales in the direction the industry now needs.
We Found this Problem the Hard Way
The clearest illustration we have of why triage is the bottleneck comes from our own research, on an AI agent platform called Manus. Manus runs an agentic assistant inside a real cloud VM with a shell, a browser, and a remote desktop, and its shared Projects feature carries a persistent instruction field that applies to every member's tasks.
The platform had a safety filter that read those instructions and rejected malicious ones. It worked. A direct payload got refused, and the agent warned the user. The finding was not a better jailbreak. It was noticing that the filter judged the wrong thing. The instruction did not need to contain the attack. It needed to contain a fetch.
Read that as a classifier would. Nothing is hostile. It is a setup script, indistinguishable from half the getting-started guides on the internet, so it sails through. The agent then fetches the real payload, which no filter ever inspected, and executes it inside the victim's sandbox.
The malice arrived later, over HTTP, addressed to a process that already had permission to run. The result was environment secrets exfiltrated from a stranger's VM, and eventually, through a static desktop password sitting in that same environment, interactive control of their remote desktop. It was reported to Meta's bug bounty program, initially closed, refiled for reconsideration, and fixed on September 16, 2026.
The lesson connects straight back to Intel. Every control in that system correctly judged the thing it was handed. Not one of them was handed the actual attack. Telling a benign-looking instruction from a genuinely benign one is a verification problem, and it is the same verification problem, at the model layer, that AI slop created at the bug-bounty layer.
Finding the fetch line was cheap. Proving it reached a live desktop, which is what Meta's triage correctly demanded, was the expensive part. That gap between a plausible claim and a proven one is the entire subject of this article.
What Defenders Should Actually Do
Five practical responses to a world where discovery is cheap and verification is scarce.
Move verification left, to the pull request. The cheapest place to confirm a real bug is where it enters the code. Automated review at the diff catches the class of defects that would otherwise become external reports.
Rank everything by proximity to real impact. An undifferentiated queue is the problem. Any incoming finding, internal or external, should carry a severity and a distance-to-data score before a human sees it.
Demand proof, not plausibility. Weight reports that carry a reproduction or a proven path above reports that carry a description. This is the filter that AI slop cannot pass, because generating a plausible description is cheap and producing a working proof is not.
Constrain the blast radius by default. Least privilege, egress control, and short-lived scoped credentials mean that a bug which does slip through is capped in what it can reach. The Manus takeover was possible only because a static admin password sat in a readable environment.
Do not mistake more discovery for more security. The celebratory metric is bugs found. The metric that matters to a defender is real bugs fixed before they ship, and those are different numbers now.
The Future of Bug Bounties Is Verification, Not More Reports
Intel's bug bounty suspension is one visible sign of a broader shift. That is why effective AI security testing and API penetration testing cannot stop at identifying suspicious code or missing authorization checks. The critical step is proving what an attacker can actually reach, how the attack works, and whether the reported weakness produces a meaningful security impact.
That was also the pattern behind the security research in this article. The useful work was not simply identifying a suspicious path. It was following that path far enough to establish what happened in a live environment and distinguish a real vulnerability from a plausible one.
CodeAnt AI applied that same approach in its security research, including the Manus investigation discussed above. The research moved from the apparent weakness to the actual execution path, showing why proof, context, and exploitability matter more as automated vulnerability discovery continues to scale.
The next phase of application security will not be defined by who can generate the most findings. It will be defined by who can determine, quickly and reliably, which findings are real, which ones matter, and what an attacker can actually do with them.
Sources
Tom's Hardware, Intel suspends bug bounty program that paid up to $100,000 per flaw, September 19, 2026
Phoronix, Intel Bug Bounty Program Ends, September 18, 2026
Intel Vulnerability Disclosure Program, Intigriti program page
Tom's Hardware, Linux kernel nears 2,000 CVEs per release as AI bug hunters scour 40 million lines of code
Tom's Hardware, Linus Torvalds says AI bug reports have made the Linux security mailing list almost entirely unmanageable
