Exploits at Scale: When Token Throughput Becomes the Bottleneck

Added Jan 19
Article: NegativeCommunity: PositiveDivisive
Exploits at Scale: When Token Throughput Becomes the Bottleneck

LLM agents successfully generated dozens of exploits for a QuickJS zeroday under modern mitigations, with results scaling predictably with token spend. This suggests exploit development is primed for ‘industrialisation,’ where token throughput supersedes human headcount as the bottleneck. The author urges public, large-scale evaluations on real targets and warns that while post-access tasks may be harder, SRE automation will signal when they’re next.

Key Points

  • Exploit generation shows clear token-for-results scaling: agents autonomously produced many working exploits, with GPT-5.2 solving all scenarios tested.
  • Industrialisation hinges on two ingredients: autonomous search across the solution space and automated, accurate verification—both well-suited to exploit development.
  • Current results likely generalize, but QuickJS is simpler than major browsers; nonetheless, the limiting factor increasingly appears to be token throughput, not human experts.
  • Post-access tasks (lateral movement, persistence, exfiltration) are harder to industrialize due to adversarial, irreversible consequences—SRE automation is a relevant ‘canary.’
  • Frontier labs and AI Security Institutes should publicly evaluate models on real, hardened targets with zerodays and large token budgets, moving beyond CTFs and synthetic tests.

Sentiment

The overall sentiment is one of concerned agreement. The community largely accepts that LLM-driven exploit generation is a real and significant development, but there is substantial debate about the magnitude of the threat and whether the specific experiments fully justify the industrialization framing. Security professionals take the findings seriously, while some push back on methodological details. The tone is technically engaged and substantive with genuine worry about implications, tempered by some optimism about defensive applications of the same technology.

In Agreement

  • LLMs are demonstrably capable of generating working exploits against real software with modern mitigations, and the quality of output depends heavily on proper agent harness design with verifiable success criteria.
  • The bottleneck for offensive cyber capability is shifting from human headcount to token throughput, representing a genuine industrialization of exploit generation.
  • The offense-defense asymmetry is fundamental and favors attackers: they need to find any single exploitable bug, while defenders must find and fix all of them.
  • Current models have not plateaued in capability; the real bottleneck is generating tasks hard enough to benchmark against.
  • The distinction between low-quality AI-generated bug reports and sophisticated agent-driven exploit generation is about the skill and tooling of the operator, not the underlying model capability.
  • Frontier labs and AI Safety Institutes should evaluate models against real hardened targets rather than toy benchmarks.
  • The combination of lowering barriers to software creation and lowering barriers to exploitation is an explosive and dangerous dynamic.

Opposed

  • The LLM is largely regurgitating known exploitation techniques from training data rather than demonstrating genuinely novel offensive capability.
  • QuickJS is a small, under-maintained C project with known unpatched problems; demonstrating exploits against it is far less impressive than exploiting hardened production software.
  • The sandbox scenario is less impressive than it sounds — the goal was merely writing a string to a file, not achieving arbitrary code execution or sandbox escape.
  • LLMs are symmetric tools that defenders can also use, running LLM Red Teams in CI analogous to fuzz testing, which could shift the balance back toward defense.
  • Defenders have structural advantages attackers lack: access to source code, design docs, threat models, and the ability to redesign architecture.
  • Software and hardware have been getting structurally more secure over time, and memory-safe languages will raise the bar against exploitation faster than LLMs lower it.
  • The exploits did not demonstrate novel breaks in any protection mechanism — they used the same known gaps that human exploit developers use.
  • Writing an exploit from a known vulnerability is the easier part; the truly hard challenge is finding exploitable vulnerabilities in the first place.