In the last week of January 2026 Daniel Stenberg committed a file to curl's repository with a title that needed no explanation: "BUG-BOUNTY.md: we stop the bug-bounty end of Jan 2026". The week before, the bounty had produced seven submissions. Some of them found bugs, mind, though not one described a vulnerability. His stated aim was to "remove the incentive for people to submit crap and non-well researched reports to us. AI generated or not."
Nine months later, on 24 October, the moderators of r/opensource went further and banned every project made with AI or built for it. Asked how they would tell a vibe-coded project from one that had merely used a language model to check for bugs, the lead moderator answered with admirable honesty: "There's no 'objective' way to implement this policy." Contributors who do not write in English were told to find another community, because the moderators "cannot distinguish between AI-written and AI-translated".
More projects will follow. Closing the door is the wrong answer, and a better one already exists in pieces, waiting to be put together.
Why the door is closing
The case for shutting it deserves to be made in full, because it is strong.
The numbers first. Between 1 January and 23 October 2026, 86,292 CVEs were published, which is 79 per cent more than in the whole of 2025. CVE records that credit an AI system as the finder rose from 34 to 769 over the same period, and 376 of those 769 are rated high or critical. The machines are finding things, and a fair share of them matter.
The burden lands on very few people. Linus Torvalds, announcing a kernel release candidate on 18 May, wrote that "the continued flood of AI reports has basically made the security list almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools". His practical advice was spot on: "If you found a bug using AI tools, the chances are somebody else found it too." By the middle of 2025 curl had already counted that only about 5 per cent of its bounty submissions were genuine vulnerabilities, with around 20 per cent looking like machine-written noise; Node.js raised the bar on its HackerOne programme after more than thirty such reports arrived over a holiday. On 27 October, Michael Aiello, OpenAI's cyber executive in residence, said at a panel in Washington what maintainers had been saying for a year. Faced with hundreds of machine-found reports, "they've just stopped taking" them.
The same overload shows elsewhere. In the first days of October a single developer published clean-room clones of seven Adobe applications, written in Rust by eight parallel coding agents. Steam had passed its 2025 total by mid-October. One analysis attributes between 60 and 90 per cent of the growth in monthly releases to games that disclose AI use. Making has become cheap, while checking costs what it always did, and the people who check were never asked whether they had the time.
So the instinct to shut the door is a small team protecting its evenings. Calling it Luddism would be unkind, and also rather accurate.
What a ban leaves behind
A ban removes the reports from the inbox, and the bugs stay in the code where they were.
Aiello, whose company sells the tools, conceded the central point in the same breath: "In most cases, they're likely real bugs of some degree." The 769 CVEs credited to AI finders this year were not imagined. If a maintainer stops reading machine-found reports, the flaws in those reports do not leave the code. They wait, and someone else reads them.
That someone may not be friendly. The tools that write the reports are available to anybody with a credit card, and Torvalds' observation cuts both ways: if three researchers found the same bug with the same tool on the same day, an attacker can find it on the same day as well. The kernel's own documentation has drawn the conclusion. "If you resorted to AI assistance to identify a bug, you must treat it as public." A project that bans the reports merely makes sure that it hears about them last.
And a ban cannot be enforced honestly. r/opensource admitted as much in its own announcement, and the first casualties were contributors writing in a second language, whose only offence was a translation tool. A rule that cannot tell its target from its bystanders will be applied to whoever looks suspicious, which is a poor basis for any community and a worse one for security.
Resignation also makes the overload worse. The machines will not stop finding bugs because a subreddit disapproves. The volume will keep rising, and a team that stops reading will sooner or later stop maintaining as well. The bans come out of exhaustion, and they leave the exhaustion where it was.
Triage with rules
The alternative is to stop reading anything that has not passed a set of rules first, and to make the machines do most of that checking. The pieces exist already; nobody has yet put them into one place. Imagine a service built like a code forge, where every report enters at one end and leaves at the other either confirmed, merged or returned, and where each step has a rule.
A form, with a self-assessment. Every report names the affected version, the observed behaviour and a reproducer, and states whether AI was used. The reporter also classifies the report themselves: kind of flaw, suspected impact, how it was found. That answer says something about intent and skill before anyone reads further, and the system holds it against what its own checks find later. A self-assessment that fits the rules a little too perfectly earns more agents and a stricter reproduction, though never a rejection; the rejection belongs to the reproducer alone. The Linux kernel already demands most of the form, in plain text, and its documentation sets the standard in one sentence: "By definition if an issue cannot be reproduced, it is not exploitable, thus it is not a security bug." The OpenSSF working group on vulnerability disclosure has drafted the same expectation for the wider ecosystem: "A working reproduction, not a source-pattern guess."
The reproducer arrives as a whole system. On FreeBSD a reporter can hand over the entire environment, ready to run. A jail holds a fault in userland; for a kernel fault, a Linux one included, a bhyve virtual machine on a ZFS volume does the same job. One snapshot records the system before the trigger and another after it, and both travel as a ZFS stream that the maintainer receives and runs, byte for byte as the reporter had it, without rebuilding anything. Because a reproducer for an unfixed flaw should not be public, the stream can be sent raw from an encrypted dataset: zfs-send(8) describes such a stream as data sent "exactly as it exists on disk", which "may then be received on an untrusted machine", and only the maintainer holds the key. My book carries a small tool, the Jail Ferry, that moves environments between machines in exactly this way. If the stream does not reproduce, the report goes back to its sender, and no maintainer has spent a minute on it.
FreeBSD earns this link, although most of the reports point at Linux, because the usual tools each carry part of it and none carries all of it. A container image cannot hold a kernel fault at all: Docker's own security documentation explains that a container is a set of kernel namespaces created on the host, which means it runs on the host's kernel and takes none of its own along. Btrfs can send incremental snapshots, but the kernel's file encryption, fscrypt, currently supports ext4, F2FS, UBIFS and CephFS, so a confidential Btrfs stream needs a further layer bolted on. OpenZFS itself runs on Linux as well, and there it lives outside the kernel: Debian ships it as zfs-dkms in its contrib section, compiled on each machine for each new kernel. On FreeBSD jails and bhyve come out of the same tree and the same release as ZFS, and one command sends any of them as a checksummed, incremental and, where needed, encrypted stream. A reporter and a maintainer who both run it need agree on nothing more than the pool features.
Several agents, several angles. A single model errs in one direction. Four models with separate briefs, one for reachability, one for the code path, one for the threat model and one for duplicates, rarely err together, and each writes a protocol with the evidence for its answer. The kernel asks reporters to judge impact against its published threat model and to "stick to verifiable facts"; the agents can be held to exactly the same document. Determinism lives in the process: fixed questions in a fixed order, with a record anyone can audit. Nobody needs the model itself to be deterministic.
Duplicates become chains. If the same tools find the same bug, ten reports of it count as one finding with ten votes. The more interesting step goes further. Flaws of a similar nature, or flaws that only matter together, are grouped into a meta-record, a chain, and the chain is made reproducible through the same snapshots. Attackers have always chained bugs; the CVE system still files them one at a time. A chain that can be replayed is also the honest way to approach the uncomfortable question of whether a capable attacker's model will always find something in the interplay of hardware and software.
Measured by effect. The CVE count rose 2.2 times this year; the number of vulnerabilities actually exploited in the wild rose by about 20 per cent, from 163 to 195. Counting reports measures diligence. Every confirmed finding or chain is therefore measured instead: criticality, kind of flaw, whether it can be reached, and how long it has been lying there, with the attackers' own tools, fuzzers first, working on the defenders' side.
A fix proposal, and people who sign it off. Each confirmed finding leaves the pipeline with a simple proposed fix in code, and nothing is closed until a set number of people from the project have accepted it. Three is a sensible default, and each project sets its own number when it installs the service, because it is their software. The kernel encourages machine-written fixes in so many words: "Many AI tools are actually better at writing code than evaluating it." OpenAI's own programme, by Aiello's account, has developed and tested 661 patches, of which maintainers accepted 458.
Whoever reports by machine pays for the check. This is the contentious link, and it is offered as a proposal. A deposit per report, returned when the finding holds, would end the economics of the drive-by submission overnight; the platforms and AI vendors who profit from the volume could fund the infrastructure that absorbs it. Bounty programmes have paid for findings for years; charging for noise would use the same machinery the other way round.
None of this is theoretical. The Adobe clones mentioned above were built the same way: eight agents work on separate subsystems, around 1,700 tests and a composite oracle that compares every render with Photoshop's own output decide whether a commit counts as progress, and a human integrates and releases. Whatever one thinks of what was built there, the method is the one this triage needs. The tools I run my own projects with work in exactly this way. Up to nine agents with different skills share a job, each drawing on whichever of several language models suits its part best, one after another or side by side, and a council of further checks reviews the result before a developer ever sees it. That costs a good many tokens, and in return it is very precise. This morning one of them refused to record an answer as an approval, because the question it answered had never been asked, and an answer to another dialogue gives no gate. The rule is unremarkable, and it caught a mistake that a quicker process would have let through.
Training follows from the process. The catalogue that instructs the agents doubles as the training for the people who read their output; machine and maintainer then judge by the same criteria. Building all of it is a tall order, and it is the sort of shared infrastructure the foundations exist to fund. Should anybody be minded to build it, the blueprint is above.
The limit
Triage does not touch the copying. For artists and small studios who find their work reproduced at scale, rules for bug reports change nothing. The flood of cheap clones on storefronts is a different problem with a different owner, and for the people who spent years on the original it is a disgrace that no triage repairs.
Making without understanding remains a risk. Software built by someone who cannot read what was built produces exactly the kind of bugs this flood consists of. Triage handles the consequences; it does not teach the craft.
The deterministic tools mostly do not exist yet. The kernel's documentation, the OpenSSF draft, the oracle behind the Adobe clones and the patch programmes are separate pieces. Assembling them into one service that a three-person project can use is work that somebody has to fund, and so far nobody has. The snapshot streams assume ZFS with matching pool features on both sides, and a project with a single maintainer has, in the end, one pair of eyes to sign with.
A triage model is still a model. It can be wrong, and it can be gamed by reports written to pass its catalogue. That is why the final word stays with a person, and why the catalogue is public, so that its failures can be seen.
Closing the door feels like control. It is control over the inbox, and the code was never in the inbox.