QWE AI Academy Greg Kroah-Hartman’s Security in the LLM Age talk just hit YouTube and immediately lit up Hacker News. The stable-kernel maintainer didn’t sell doom. He sold a workflow.
Key takeaway: treat LLMs as noisy pattern-matchers you run locally, demand a patch with every report, and never paste non-public code into a cloud frontier model. That single habit change beats most of the hype cycle.
I watched the full Kernel Recipes session, cross-checked his netdev slides, and spent an afternoon wiring up the stack he pointed at. Two paths showed up fast.
Background: why this talk landed now
On the slides, mean time-to-exploit collapses hard: 63 days in 2018, 32 in 2020, 5 in 2024, then -7 days for 2026. The old disclose-then-patch cadence assumed a slower adversary. That adversary is gone.
LLMs didn’t invent new bug classes. They industrialised fuzzy matching against decades of prior patches and CVEs. Mythos-style claims of “79 kernel vulns” looked terrifying in press releases. Turns out the breakdown Greg walked through was blunt – 24 no detail, 14 not a bug, 3 made-up data, 15 already fixed, and of the rest only about ten were real, mostly obscure fixes. He called the noise out for what it was.
HN matched what maintainers already feel: exhaustion at long, confident, wrong reports – and relief that someone with the actual inbox said “don’t panic” and then named tools instead of vibes.
Method A vs Method B for LLM security work
First move most people make: paste a function into ChatGPT/Claude/Gemini and ask “find vulnerabilities.” Fast. Also the path Greg’s slides flag with a hard line – NEVER upload non-public information.
Method B is what he recommends running: local (or fully private) model + an agent that can read the tree + specialised review prompts + every finding ships with a patch. Code stays on your side of the firewall.
| Aspect | Method A (cloud paste) | Method B (local agent) |
|---|---|---|
| Data exposure | Instant training/public risk | Stays local if you set it up right |
| False-positive load | High; model wants to please | Still high, but you control the loop and can demand patches |
| Cost at scale | Token bills add up fast ($10k case study on slides) | Hardware + electricity; predictable |
| Reproducibility | Vendor model changes overnight | Pinned GGUF + prompts you own |
| Greg’s verdict | “NEVER upload any non-public information” | “Run local models internally” |
Method B wins for anything you wouldn’t want on the front page tomorrow. Walkthrough below.
Hands-on: Greg-style local LLM security review
Goal: a disposable agent that reviews your code the way kernel folks are starting to – without leaking it.
1. Dedicated account (non-negotiable)
Create a user whose entire home directory you can wipe:
sudo useradd -m -s /bin/bash ai-reviewer
sudo passwd ai-reviewer # or better, key-only
sudo -iu ai-reviewerEverything below runs as this user. No SSH keys that matter, no browser profile, no production secrets. Willy Tarreau’s HAProxy write-up (linked from Greg’s slides) is the cautionary demo: agent “sandboxes” are mostly polite suggestions. An uncensored model or a prompt-injected source file will happily cat whatever the process can read – ~/.ssh, shell history, the lot.
2. Local inference
Grab llama.cpp (or ramalama if you prefer containers) and a coding-capable GGUF from Hugging Face. As of late 2026, Qwen-class MoE quantised models are a common sweet spot for speed vs quality on a single GPU; dense models if you have the VRAM.
# example shape only - pin versions yourself
./llama-server -m ./Qwen-Coder-Q4_K_M.gguf -c 131072 --port 8080 -ngl 99Keep context sized to your RAM. You do not need the absolute newest frontier weights. Greg’s point on the slides: today’s local models already catch the pattern-match class of bugs that matter for triage. Ignore the “model of tomorrow” marketing; fix what you find today. Rough horizon he gave: ~18 months ahead, not infinity.
3. Agent + Greg-pointed prompts
Greg listed agents that can use tools (bash, read, grep, edit) against a checkout: OpenCode, pi, goose, kres. Maintainers have already blogged OpenCode + local Qwen via llama.cpp as one concrete path.
Then pull the prompt set from the slides:
git clone https://github.com/masoncl/review-prompts.git
cd review-prompts
./setup.sh opencode kernel # or claude/goose/etc + your projectmasoncl/review-prompts gives /kreview-style flows, subsystem patterns, and false-positive checklists tuned for kernel-shaped C. Not on the kernel? Steal the structure anyway: review → verify → demand evidence. Force a unified diff plus a short repro note, or the agent outputs nothing.
Pro tip: End the prompt with “If you are not at least 80% sure it is a real bug under a realistic threat model, say so and stop. Output a unified diff or nothing.” Sycophancy drops hard when the model is allowed to shut up.
4. The actual loop
- Point the agent at one subsystem or one recent diff – not the whole monorepo on day one.
- Run the review skill.
- For every claimed issue require: file:line, why it is reachable, and a patch.
- Push back once in plain language (“this path is only hit by CAP_SYS_ADMIN”). Real bugs usually survive; hallucinations fold.
- Human-test the patch on real hardware or a VM before you upstream anything.
Kernel security adaptations on the same slides line up with that last step: start documenting the threat model, CC maintainers on security docs, request an initial patch with reports, plus funding talk for a full-time helper on [email protected]. Concrete work filters the flood better than severity theatre.
One resource Greg marked for managers: the OpenSSF guide Securing Open Source in the Age of AI. Handling AI-generated reports without burning out maintainers is half the job.
Where the local workflow still bites you
False positives never hit zero. Best models are still wrong about a quarter of the time – Greg’s own closed-frontier testing and the Mythos autopsy both land there. Bots pattern-match, want to please, dump changelog text, and over-comment. Budget human triage time. The win is noise that arrives with a patch you can reject in seconds instead of a five-page essay.
The catch is tool access. Give the process network or your main UID and you have not followed the talk. Dedicated unprivileged account is the floor; optional network namespace helps. Policy-only sandboxes are not isolation.
Bulk “scan the world” jobs still cost real money or GPU days. Anonymous case study on the slides: 200 targets, ~$10k tokens, 3 days, 11 concurrent sessions, 108 “verified” critical findings – most still need humans. Warning, not a goal. Start narrow. Local inference flips the economics, but only after you plan GPU/RAM instead of pretending tokens are free.
Some trees will reject LLM cleanups on sight. Greg’s staging stance is public: no LLM-generated patches in drivers/staging except hardware-tested security fixes – staging exists for human learning. Disclose AI assistance when the project asks. Hiding it reads as bad faith and can get you ignored or banned from that tree.
Is eighteen months of rough triage the new normal, or will the signal-to-noise ratio climb once everyone runs the same local filters? Greg left that open. The tools to stop being a victim of the flood are already on the slides.
FAQ
Do I need a big GPU to follow Greg’s advice?
No. A quantised coding model that fits your RAM is enough. CPU-only works for single-file or small-diff review – it’s just slower. Buy hardware after the workflow sticks, not before.
What if the model keeps inventing bugs in my project?
Normal. Say your CLI only runs as root on localhost and you ask for auth bypasses – the model still writes a dramatic report. Reply: “under our threat model this is unreachable – confirm or drop it.” After two push-backs most hallucinations collapse. Keep only the ones that still emit a clean patch plus a realistic repro, then test those yourself.
Is uploading public open-source code to a cloud model fine?
Confidentiality risk is lower if the tree is already public. Greg’s brighter line still holds: if you would not paste it on a public mailing list today, do not paste it into a vendor chat. Local stays simpler.
Clone the review-prompts repo, spin up one local model under a throwaway user, and run it on your next non-trivial diff before the day ends. That is the concrete move the talk is actually selling.