Back to Research

TECH EVOLUTION // 03

Tech EvolutionJul 26, 20269 min

Attackers Don't Have to Be Right

AI's security asymmetry isn't offensive capability — offense tolerates being wrong and defense can't, so the cost of verification per action, not model quality, decides where autonomous defense lands.

Two things happened to open-source security in January 2026, a day apart, using the same technology.

On January 26, the curl project killed its bug bounty after seven years and $90,000 paid out for 81 real vulnerabilities. Cause of death: AI-generated reports. Valid submissions fell from north of 15% to under 5%; a single week of junk consumed roughly 20 volunteer hours from a seven-person security team.

On January 27, OpenSSL shipped a release fixing 12 new zero-days. All 12 were found by one AI system, including a high-severity stack overflow that triggers before any cryptographic verification — a class of finding that historically averages less than one per year in that codebase. Three of the bugs had been sitting there since 1998–2000. One predates OpenSSL itself.

Same year, same capability, opposite outcomes. Most commentary picked a side and called it the story of AI in security. It isn't. The difference between those two weeks is the most useful thing in the field right now, and it has almost nothing to do with model quality.

Where we actually are

The offense side is no longer speculative. Check Point's AI Security Report 2026 documents intrusions where AI ran exploitation workflows autonomously — thousands of executed commands across dozens of sessions with minimal human direction between steps. In one case, a single operator against nine government agencies produced 5,317 AI-executed commands across 34 sessions. Anthropic's disclosure of GTG-1002 reported an espionage campaign against roughly 30 organizations in which the model handled an estimated 80–90% of hands-on intrusion work.

Downstream, the clock collapsed. VulnCheck's State of Exploitation data has 28.3% of exploited vulnerabilities weaponized within 24 hours of disclosure, against a median time-to-exploit that used to be measured in months. Check Point's read is blunt: exploits now routinely arrive within hours of public disclosure, and the speed of testing and deploying patches has become the primary bottleneck.

Now the defense side, which is where the interesting part lives — because it is not losing everywhere. It is losing in exactly one kind of place.

Where defensive AI is winning, it is winning decisively. The AISLE result above is one example; DARPA's AI Cyber Challenge is another. At its final round, autonomous systems were given 54 million lines of code and four hours of compute each. They found 54 of 63 injected vulnerabilities and patched 68% of them — plus 18 real-world bugs disclosed to maintainers, with all seven finalist toolchains released open source. On the enterprise side, IBM's 2025 Cost of a Data Breach found organizations using AI and automation extensively cut breach lifecycle by roughly 80 days and about $1.9M in cost.

Where defensive AI is losing, curl is the archetype: not out-hacked, but buried in plausible work. Ninety-five percent false positives, each one requiring reproduction, discussion, and a polite close.

Put those two failure modes next to each other and the pattern is obvious once you see it. Offense doesn't have to be right. Defense does.

An attacker running ten thousand AI-generated attempts needs one to land; the 9,999 failures cost nothing but compute. A defender acting on ten thousand AI-generated findings needs to be right nearly every time — a wrong block breaks production, a wrong patch ships a regression, a wrong triage burns the one analyst who can tell the difference. Offense converts volume into outcomes directly. Defense has to pass every unit of volume through verification first, and verification is exactly the thing AI has not made cheap. That was the bottleneck in software delivery I wrote about last week; in security it's the same bottleneck with a shorter fuse.

Which explains curl and OpenSSL as one phenomenon rather than two. AISLE's system worked because verification in that context is cheap and external: the patch compiles, the test suite passes, the maintainer confirms, a CVE gets issued or it doesn't. Ground truth is available and objective. Bug bounty triage has no such property — validity is a judgment call requiring a human to reconstruct intent from a narrative that AI is very good at making sound convincing. Same technology; one domain had cheap verification and one didn't.

The trajectory

Cost-of-verification, not model capability, will determine where autonomous defense actually lands. Security tasks with cheap objective oracles — fuzzing, crash reproduction, patch validation, config drift, regression tests — will automate fast and far. Tasks whose ground truth is contextual judgment — is this alert real, is this report valid, is this access legitimate — will stay stubbornly human-gated no matter how good the models get, because the failure cost is asymmetric and there's nothing to check the answer against. Expect vendor claims to blur these two categories; expect deployments to discover the difference.

Trust-building will get formalized, and the ceiling will be lower than the pitch. The pattern already converging in AI SOC practice — shadow mode, then low-risk auto-execution, then supervised medium-risk, with confidence thresholds around 90–95% before automated suppression is trusted — is the market pricing verification cost honestly. Autonomous triage is arriving; autonomous response on irreversible actions is not, and the constraint isn't the model.

Attackers will keep monetizing the defender's verification budget directly. Curl is the mild version, unintentional. The weaponized version is obvious and cheap: flood the queue with plausible-but-false signal and walk in through the alert nobody had time to read. Any defensive process whose cost scales linearly with inbound volume is now an attack surface, not just a workflow.

The limits of these extrapolations, explicitly. AISLE's OpenSSL result is contested as a generalization — one credible objection notes that zero of the 12 CVEs applied to BoringSSL, Google's fork, which suggests the target may have been unusually amenable rather than representative of hardened code everywhere. The most dramatic breach numbers come from security vendors selling the remedy: trust the direction, discount the magnitude. Several experts have publicly questioned how genuinely novel or "large-scale" the AI-orchestrated campaigns were versus conventional tooling with an LLM bolted on. And the strongest counter to my whole framing is the IBM data: in aggregate, defenders adopting AI are measurably ahead — shorter breach lifecycles, lower costs. If verification were an absolute wall, that number would not exist. It does. My claim is that the wall shapes where automation lands, not that defense is losing.

What if...

This section is speculation, clearly flagged. These may or may not happen. For each, what would need to be true.

What if verifiability becomes an architectural requirement, the way testability did? The reason defense can't act at machine speed is that its actions are expensive to undo. But that's a property of how we build systems, not a law. If defensive actions were reversible by construction — quarantine instead of delete, credential rotation instead of account lockout, staged blocks with automatic rollback on error signal — then being wrong gets cheap, and being fast stops requiring being right. Autonomy follows reversibility. What would need to be true: reversibility engineered in at the platform layer, with the blast radius of a wrong automated action bounded by design rather than by an analyst's caution. We did this once already, in the 2010s, when "testable" became a design constraint instead of a virtue.

What if the human verification market gets repriced rather than abandoned? Curl's bug bounty died because reporting was free and triage was expensive — the economics inverted the moment generation got cheap. The obvious repair is symmetry: make submission cost something (a stake, a reputation bond, a paid-triage tier) so that volume carries its own verification cost. That may sound hostile to independent researchers, and the risk of pricing out honest ones is real. But the alternative, visible right now, is the programs closing entirely. What would need to be true: a stake mechanism that doesn't gate out the exact good-faith researchers the program exists to attract — the unsolved design problem, not the unsolved idea.

What if I'm wrong about the asymmetry, and defense wins structurally? Here is the strongest case against my own thesis. Foundational infrastructure is finite. Most of the internet inherits its security from a few hundred libraries — OpenSSL, curl, SQLite, the kernel. If AI drains the vulnerability stock from that layer faster than new bugs enter it, the returns compound across every system downstream, permanently, in a way no attacker campaign can match. AISLE's own read is that this favors defense, and the AIxCC tools being open-sourced points the same direction. What would need to be true: the stock has to be finite in practice, and the introduction rate has to stay below the discovery rate. That second condition is the shaky one — AI is also writing an enormous amount of new code, at 1.7× the defect density of human code. We may be draining a pond while the river runs.

What I'm doing about it

I run a fleet of autonomous agents that operate real accounts and real workflows daily. Every one of them is, structurally, an insider with credentials — which means I've had to answer the machine-speed question at small scale, on a system where I'm both the attacker's target and the defender's staff.

The design conclusion I reached is the one this article argues for: I stopped trying to make my agents right and started making being wrong cheap. Concretely — every agent's state lives in plain files a human can read and diff, so verification costs seconds instead of a forensic session. Actions that can't be undone need a human boundary; actions that can are autonomous. Capability is bounded by need rather than by filtering: an agent with no reason to touch a shell doesn't get a shell, which is a boundary you can verify by inspection rather than a rule you have to enforce at runtime. And there's a stand-down protocol — when the watchdog sees anomalous conditions, the fleet's default is to stop, not to proceed carefully. Silence fails closed.

That last one has fired repeatedly across documented anomalies, and every time it cost me a skipped run instead of an incident. That's the trade the whole industry is negotiating right now, and it's worth saying plainly: the cheap thing was never the intelligence. It was always the verification, and it still isn't cheap.

Attackers don't have to be right. Build so that you don't have to be either.


Sources are linked inline. Next week: another field, same discipline — where we are, where the data points, and what might happen, honestly labeled. Research home: blackicelabs.ca

Written by Levon Azevedo

Discussion

This article was also published on LinkedIn.

Get the next one by email.

Subscribe