The problem

Most “AI and cybersecurity” takes collapse into one flat claim: AI makes attackers faster, so defenders need AI too. That framing hides the actual structural problem, which is that AI doesn’t accelerate both sides equally. It changes the economics of patching, it applies guardrails asymmetrically to attackers versus defenders, and it’s now producing genuinely novel exploits on hardened, high-value targets like Chrome’s V8 engine — while the benchmarks the industry uses to measure “AI hacking capability” are largely measuring the wrong thing. Any security team, CISO, or engineering org deciding whether to invest in a Rust rewrite, whether to trust a closed frontier model with real exploit payloads, or how much weight to put on a vendor’s “our model can find CVEs” benchmark is operating on this same shaky, oversimplified picture.

The approach

This is a research project, not a piece of software — the deliverable is a set of sourced, cross-referenced arguments I pulled apart from talks by practitioners actually doing this work (Jack Cable at Corridor, David Brumley’s exploitation-benchmark team, an NVIDIA local-models talk, and a policy-level AI conversation featuring David Sacks), then distilled into standalone, citable ideas rather than a summary of “what was said.”

The core argument set breaks into three pieces I’m building content around. First: systemic hardening beats whack-a-mole patching. Google’s own Android data shows memory-safety CVEs dropped from ~75% to ~30% of all Android bugs just by writing new code in memory-safe languages — no rewrite of legacy C/C++ required. Against AI-accelerated vulnerability scanning, a one-time investment in eliminating a whole bug class (Rust, Go) compounds in a way individual patches never can, because the guarantee holds against attack models that don’t exist yet. Second: guardrails on closed frontier models are handicapping defenders more than attackers. Attackers running open-weight models locally with the safety layer stripped face no such friction; defenders using a hosted commercial model get refused the moment a prompt contains a real exploit payload. Hugging Face hit this directly — trying to analyze a live AI-powered attack, US frontier models refused, so they switched to a Chinese open model run locally. Third: the benchmarks the industry uses to claim “AI can hack X%” of known CVEs are largely bogus, because they measure “did the program crash” rather than the actual exploitation chain (in-sandbox read/write → sandbox escape → arbitrary code execution). Brumley’s team reran the same 41 V8 CVEs on the real exploitation ladder and watched models that scored ~95% on “can it crash” drop straight to 0% on “can it actually take control.” That’s the gap between a headline capability claim and the number that should inform a real risk assessment — and it’s the throughline I’m using across the pieces this research feeds.

What I learned

The most useful finding wasn’t any single stat, it was a definitional fix: “trust” and “safety” get conflated constantly in the open-vs-closed-model debate, and they’re not the same axis. Trust is “do I know what this system does and will I keep having access to it” — which open weights answer better, not worse, because you can inspect them and you can’t have them revoked. Safety is a separate, orthogonal question about guardrails and misuse. Once you split those apart, a lot of “just use the safe closed model” advice in a security context stops making sense, because for red-teaming and defensive analysis work, the closed model’s safety layer is precisely what makes it operationally useless.

Where this could go

The next layer of this research is turning “AI finds genuinely novel exploits and the field has no consensus on how to publish that responsibly” into something concrete: what does a disclosure policy look like when an AI system’s raw transcript is itself a weaponizable zero-day chain against Chrome, Node.js, or a cloud edge runtime? Brumley’s team already had to withhold Mythic’s transcripts from public release for exactly this reason. For any enterprise running or evaluating AI-assisted red-teaming, that’s not an academic question — it’s a policy an internal security team needs before the first engagement, not after. The same goes for the memory-safety argument at org scale: “which service gets the Rust rewrite budget this quarter” is a resourcing decision that AI-accelerated attack timelines make more urgent, and this research is the backing argument for making that case with data instead of vibes.

Takeaway

The AI security story people are telling — “attackers get faster, so defenders need AI too” — is true but shallow; the real story is that guardrails, benchmarks, and patching economics are all breaking asymmetrically in the attacker’s favor unless teams deliberately correct for it.