AI Agents Are Entering the Kernel
The real benchmark for AI security research is whether a finding survives maintainer review, lands upstream, and gets carried into the software people actually run. The public record is starting to show ours does.
The kernel is where security claims go to get humbled.
A benchmark can be patched. A demo can be staged. A leaderboard can measure the wrong thing. The Linux kernel process is different. You send a patch to public mailing lists. Maintainers read it. Reviewers challenge the premise, the fix, the Fixes: tag, the stable backport story, the locking argument, the reproducer, and the style. If the work is wrong, the archive keeps the rejection.
That is why the most interesting question in AI security is no longer whether a model can suggest a bug. It can. The harder question is whether an AI-assisted research system can turn a candidate into a maintainer-reviewed upstream fix.
The public record is starting to answer that question.
The Public Receipts
Lore is the public archive for Linux-kernel mailing-list work. Search it for 0sec and the result is no longer a single launch artifact. It is a live trail of kernel-security work: original patches, maintainer replies, bot reports, stable backport reviews, and follow-up revisions.
As of 2026-07-15, the public Lore search for 0sec shows threads across MCTP, VXLAN, GENEVE, Bluetooth, NFC, HID, Wi-Fi, DSA, AMD XDNA, Xen, io_uring, TIPC, and mac802154.
Some examples:
| Thread | What it shows |
|---|---|
| MCTP serial zero-length frame overflow | A KASAN-proven heap out-of-bounds write, revised after maintainer feedback, with Assisted-by: 0sec:multi-model. |
| MCTP maintainer review | The maintainer accepted the analysis and suggested a cleaner fix shape. |
| VXLAN/GENEVE capability-gate series | A fuzzer-blind authorization bug class, reproduced in QEMU with user namespaces. |
| VXLAN review | A reviewer agreed with the patch direction and corrected the Fixes: tag. |
| TIPC stable backport | A 0sec-authored TIPC use-after-free fix carried into stable review by Greg Kroah-Hartman. |
| mac802154 stable backport | A 0sec-authored mac802154 fix carried into stable review, with Intel review on the original patch. |
That public trail matters more than a claim on a website. It shows the whole path from analysis to review, including the unglamorous parts: revisions, reviewer corrections, duplicates, stable metadata, and style fixes.
0sec Isn’t the Only One Doing This
Several teams are pushing in this direction, and that is the point.
Anthropic has publicly described Project Glasswing, where Mythos Preview was used to find and chain vulnerabilities in large software systems, including operating-system targets. Theori’s Xint team has written about Copy Fail, CVE-2026-31431, a Linux-kernel vulnerability where Xint Code helped surface the bug after a human operator identified the attack surface. Google has published Big Sleep and CodeMender work around AI-assisted vulnerability discovery and repair. Independent researchers have also shown real kernel results with frontier models, including Sean Heelan’s writeup on using o3 to find CVE-2025-37899 in Linux ksmbd.
The credible set is small, but it is real: frontier labs, a few elite research teams, a few independent researchers, and now small labs like 0sec with public kernel-mailing-list receipts.
That is the market shift. The frontier is AI-assisted vulnerability research that can survive public review, not “AI writes code.”
The Difference Between a Patch and a Finding
Kernel maintainers do not need more plausible reports. They need correct, minimal, reviewable fixes.
That changes what a security agent has to optimize for.
It is not enough to say “there may be a race here.” The system has to answer:
- Is the path reachable?
- Is the bug already known?
- Does the proposed fix cover the real root cause?
- Does it break the subsystem’s intended behavior?
- Is the
Fixes:tag correct? - Should this go to
[email protected]? - Can the claim survive someone who knows the subsystem better than you do?
This is where many AI security demos collapse. They produce candidate bugs. They do not produce upstreamable work.
The kernel process rewards the opposite behavior: narrow claims, exact reproductions, short patches, explicit threat models, and fast correction when a maintainer points out a better fix.
What Our Current Status Actually Supports
The claim we can support today is precise:
0sec has authored nine fixes that are now in the mainline Linux kernel, across seven subsystems: Bluetooth, TIPC, mac802154, mlx5e, xen-blkfront, NFC, and the AMD XDNA NPU driver. Several of those have been released or queued across the supported stable trees (TIPC and mac802154 in 6.12.95 and 6.6.144, the Bluetooth fix fully released, and the mlx5e fix added to all five active stable trees). Recent July threads show additional reported or under-review work in MCTP, Bluetooth L2CAP, VXLAN, GENEVE, HID, Wi-Fi, DSA, ocfs2, and the ARM Ethos-U NPU.
We should not inflate that into “nobody else can do this.” That would be false. Anthropic, Theori/Xint, Google, and independent researchers using frontier models are visibly operating in the same broad arena.
The defensible claim is narrower and stronger:
0sec is one of a small number of teams with public evidence that AI-assisted vulnerability research can reach Linux-kernel depth: original patches, maintainer replies, stable backports, and explicit tooling attribution in the public archive.
That is the bar we care about.
The Duplicate Problem Is Part of the Story
The public archive also shows the failure mode.
One io_uring patch we sent was correct, but not first. Gabriel Krisman Bertazi pointed out that the same bug had already been fixed in three concurrent postings.
That is useful, not embarrassing.
AI increases the volume of plausible findings. That makes deduplication, freshness checks, and maintainer-aware routing more important, not less. After that thread, our pre-send gate treats Lore deduplication as a required step before sending kernel patches.
The next generation of security tooling has to learn a harder skill than finding bugs: how not to waste maintainer time.
The Real Benchmark
The real benchmark for AI vulnerability research is this:
- Find a candidate.
- Prove it against a real tree.
- Deduplicate it against public work.
- Minimize the fix.
- Send it to the right maintainers.
- Respond to review.
- Get it merged.
- Get it backported when the impact justifies it.
Everything else is a proxy.
That is also why the kernel is such a useful forcing function for 0sec. It punishes vague claims. It punishes overbroad patches. It punishes missing context. It turns “AI found a bug” into a public, reviewable artifact.
A Better Proof Of Work
This is also the kind of work we want more people to try.
It’s a small, realistic challenge: read a subsystem or application, find the invariant, identify the missing guard, prove the behavior, and write the smallest patch that a maintainer would not hate.
So we are shaping a public 0sec challenge track around that idea: part CTF, part code review, part vulnerability research. Kernel and application tracks. Realistic targets. No synthetic “guess the trick” puzzles. The output should look like the thing we actually value: a concise report, a reproducer, and a patch or mitigation that survives review.
If you think you can do this, the challenge is the cleaner way to prove it: take an unfamiliar codebase, find the bug, prove it, deduplicate it, and explain the fix.
The first version is not live yet. If you want to be in the first group when it is, use the careers option on the contact page and say you want the 0sec CTF/research challenge.
The goal is to reward the same behaviors the kernel process rewards: careful reasoning, reproducible evidence, clean patches, honest deduplication, and respect for the maintainer on the other side of the email.
Because that is where the field is going.
AI agents will produce more candidate vulnerabilities than maintainers can absorb. The scarce skill will be turning that volume into work the ecosystem can actually accept.