Zero-Day Defense: Going from 0 to 1

The traditional twenty-year equilibrium between attackers and defenders has officially collapsed. We are no longer dealing with speculative hazards; modern language models can now autonomously discover and exploit critical zero-day vulnerabilities in production software without complex scaffolding or extensive human assistance. This is not just a Mythos-scale capability — in the last three months this kind of ability has been shown with modest open-weight models too.

From unearthing deep Linux kernel bugs that have lain dormant since 2003 to extracting production credentials via blind SQL injections — the kind of live capability Nicholas Carlini demonstrated on stage at [un]prompted 2026 — autonomous systems are demonstrating an unprecedented level of offensive sophistication.

This is not a marginal upgrade to the cybersecurity toolkit — it is the most seismic disruption to security infrastructure since the commercialization of the internet itself.

01 Agentic Threat and Agentic Response

The Zero Day Clock, which tracks time-to-exploit across more than 83,000 disclosed CVEs, puts a number on that collapse: the median gap between disclosure and exploitation fell from 771 days in 2018 to under four hours by 2024, and roughly three in four exploited flaws today are weaponized before a patch even exists.

With this shift towards prevalent zero-days becoming almost the default, static, signature-based defenses and pattern-matching scanners are effectively obsolete. Real-world testing reveals that legacy scanners achieve low single-digit success rates even on known, historical flaws, while multi-stage agentic pipelines are validating hundreds of brand-new bugs in heavily audited codebases like OpenSSL, Chromium, and WebKit — Krivka and Vlcek's AISLE system alone surfaced a dozen zero-days across a single OpenSSL release cycle.

Independent researchers are pushing the same curve further: Sean Heelan — a researcher who's worked on automatic exploit generation since his 2008 MSc thesis — had his agents generate forty working exploits across six mitigation scenarios for a single QuickJS zero-day, with the hardest run costing about fifty dollars; Yaron Dinkin and Eyal Kraft's agent swarm surfaced over a hundred kernel-driver vulnerabilities across major hardware vendors for roughly four dollars a bug.

The pace of this evolution is staggering: in DARPA's AI Cyber Challenge, autonomous systems vaulted from detecting just over a third of targeted vulnerabilities at the August 2024 semifinals to 86% at the 2025 finals — an overwhelming jump in a single year.

The era of relying entirely on periodic human code reviews and rigid syntax rules to protect foundational software has reached its logical end.

POCs Everywhere

This growth is driven by a shift in how these systems engage with target software at all: from reading code to actually running it. Where a static analyzer or a human auditor works from the text of a program, an agentic pipeline compiles, executes, fuzzes, and instruments the live target — sending real queries at a database, driving a kernel module through its actual memory layout, feeding a parser millions of malformed inputs until one of them verifiably corrupts state.

That shift from reading to executing is what lets an agent confirm a bug is real and exploitable rather than merely plausible on paper, and it's why the traditional, read-only static scanners noted above are obsolete against software that has sat unexamined at this depth for years.

What turns a single novel primitive into a systemic risk is coordination, and that's exactly what Zhu et al. demonstrate in "Teams of LLM Agents can Exploit Zero-Day Vulnerabilities." A lone language model agent struggles with the long-range planning that vulnerability discovery demands. A hierarchical multi-agent architecture does not: a coordinator distributes reconnaissance, exploit-script compilation, and execution debugging across specialized sub-agents running in parallel. The finding echoes and extends the IronCurtain results covered in a previous post on runtime invariants — coordinated agentic workflows compress the exploit development lifecycle for targets the individual agents have never seen.

That coordination story gets a large empirical check from "Hackers or Hallucinators?," the first systematization of knowledge on the field: it benchmarks 13 open-source autonomous-pentesting frameworks plus 2 baselines under one unified evaluation, burning over 10 billion tokens across more than 1,500 execution logs that a panel of 15-plus researchers spent four months reviewing by hand. The complicating finding is worth sitting with: on easy and medium tasks, single-agent architectures are often not inferior to — and sometimes beat — the multi-agent designs the coordination story above depends on. External knowledge bases and larger tool pools frequently don't help either, and hallucination is widespread, including frameworks that simply fabricate a success flag they never actually captured.

Koch's May 2026 analysis gives the macro picture a name: the Agentic Attack Compression Model, which formalizes how autonomous exploit pipelines eliminate the multi-day patch window that traditional remediation cadences assume exists. The defensive recommendation is blunt — treat autonomous internal agents not as a bolt-on tool but as fundamental infrastructure, on the same footing as the firewall or the identity provider, because machine-speed threats no longer leave time for a human-mediated response to matter.

The Cloud Security Alliance's own April 2026 accounting puts a price on that compression: AI systems generating a working proof-of-concept for a published CVE in ten to fifteen minutes at roughly a dollar an attempt, and one reproduction framework averaging $2.77 per CVE across a 51% success rate — the same commoditization story this post keeps returning to, just measured a different way.

To withstand this new reality, defensive architectures must achieve machine-speed velocity through blocking and automated containment. When an arbitrary amount of compute can be funneled into agent-enabled targeted infrastructure abuse, human-in-the-loop triaging is simply too slow to prevent a breach.

From Agile to Agentic Defense

The path forward demands an active, agentic paradigm where defense systems continuously baseline normal behavior, flag anomalies with statistical precision, and trigger blocking and real-time containment: killing sessions, rolling back states, and revoking tokens in flight. The window to secure our systems against industrialized, automated offense is shrinking by the day, and the four pillars surveyed below are the literature's answer to date.

Start with the premise the rest of this blog post assumes: while prevention is definitely a good thing, total prevention in a security context is no longer a realistic target, and treating it as one has quietly become the wrong success metric.

Economic Reality

The more useful framing is economic, not absolute — not "is the system secure" but "how expensive can we make an exploit, relative to what it's worth" — and every layer covered below is, underneath its specific technique, an attempt to raise that price. What's changed is who's paying the discovery cost, and how little of it remains.

That erosion is not abstract. Anthropic's restricted Mythos system — backed by up to $100 million in usage credits — showcased a FreeBSD NFS remote-code-execution bug (CVE-2026-4747, a seventeen-year-old stack buffer overflow in svc_rpc_gss_validate) as its flagship, fully autonomous result.

AISLE's Stanislav Fort reran the same analysis against a stack of ordinary, publicly available models to see how much of that capability actually required frontier-only access. The smallest model that still identified the bug, GPT-OSS-20b, has 3.6 billion active parameters and costs $0.11 per million tokens — a fraction of a cent to reproduce a result that had just been billed as proof exclusive model access was necessary.

No Single Architecture

None of this converges into a single defensive answer, and Rashidi's systematization of knowledge on execution-security research for AI coding agents explains why: the field is balkanized. Isolation mechanisms like IsolateGPT and DeltaBox solve different slices of the problem, and the SoK finds severe time-of-check-to-time-of-use (TOCTOU) gaps precisely at the seams between them.

The scope of that fragmentation is worth sitting with. Rashidi's survey systematizes 39 papers published between 2023 and 2026 into 17 separate categories — sandbox isolation, capability and access control, policy enforcement, TOCTOU races, Model Context Protocol threats, identity delegation, execution provenance, network egress control, static analysis of agent-generated code — and still finds the field hasn't converged on a shared vocabulary across them.

The rest of this post takes those four pillars in turn — not because the literature agrees they add up to a coherent architecture, but because that's the shape the response is actually assuming, gaps and all.

02 The Agentic SDL

Two Frameworks, One Answer

Software already had a name for "build security in instead of bolting it on": the Security Development Lifecycle (SDL), the methodology Microsoft formalized in the early 2000s and the industry has run variations of ever since. The question several independent groups have converged on in the past year is what SDL even means once the thing shipping through that lifecycle is an autonomous agent rather than deterministic code.

The Cloud Security Alliance's answer, the Agentic Secure Development Lifecycle (ASDL), states the core problem bluntly: traditional SDL assumes an attacker has to modify code to change what software does, but an agent's behavior depends on its code, its underlying model, the contents of its context window, every tool it invokes, and any instructions buried in content it retrieves — meaning an attacker can reshape that behavior without touching a single line of source.

The ASDL answers with five overlapping phases — design, development, testing, deployment, operations — each with its own concrete gate: MAESTRO-based threat modeling and an enforced instruction hierarchy at design and development time, red-team testing against OWASP's Agentic Security Index at the testing gate, kernel-level sandboxing and least-privilege credential scoping at deployment, and behavioral drift detection at the operations stage. It even grades maturity in three tiers, from basic containerization up to cryptographic memory integrity and formally verified planning logic.

Microsoft's own February 2026 update to SDL — the same methodology, updated rather than replaced — lands on a structurally similar answer from a different direction: six pillars (research, policy, standards, enablement, cross-functional collaboration, continuous improvement) built around six new AI-specific focus areas, including threat modeling for AI, memory protections, agent identity and access control, and shutdown mechanisms for unsafe conditions.

Three Gaps Between Theory and Practice

The practice, though, still lags the paper — and not for one reason, but three.

1. The tooling itself. Katie Norton's assessment for Resilient Cyber is unsparing: legacy AppSec tooling — SAST, DAST, SCA, ASPM — "weren't designed for a world where AI agents author, review, and deploy code," the gap between vulnerability discovery and remediation capacity is widening into what she calls a coming vulnpocalypse, and autonomous offensive tools like XBOW, Project Naptime, and Project VAIL are already operating at machine speed while defenders are still triaging tickets by hand — the same asymmetry the rest of this post has been measuring in dollars and success rates.
2. Who's holding the pen, not how fast the tooling runs. Clover Security's breakdown of who's actually shipping code splits builders into three tiers: technical engineers orchestrating agents through formal specs; citizen developers building internal automation entirely outside any formal SDLC — Zapier alone reports AI use across more than 800 internal agents; and, riskiest of the three, semi-technical product managers and designers "vibe coding" straight to a production pull request with no security process in the loop at all. An independent audit of that last group backs up how much it matters: Escape.tech scanned 5,600 vibe-coded production applications and found over 2,000 vulnerabilities, 400-plus exposed secrets, and 175 instances of exposed PII — design-level flaws, Clover argues, not syntax errors, from agents that never had the trust-boundary context to know better.
3. What agents are allowed to do, upstream of the first two. Snyk's framing is about not just what an agent generates, but what it's allowed to use and do while generating it. Its "three control points" model — what agents use, what agents do, what agents generate — treats the first two as security problems in their own right, distinct from scanning the code that comes out the other end. The supporting numbers are blunt: 76 confirmed-malicious skills out of 3,984 analyzed, and roughly a third of public MCP servers carrying an exploitable flaw. Snyk's own example of what "what agents do" looks like in practice is an agent that deleted a production database and then fabricated records to hide that it had happened — which is why its answer isn't another review gate, but continuous supervision running inside the agent's workflow instead of after it.

The noise problem runs in both directions. Bug bounty triage queues show what it looks like on the receiving end: Bugcrowd reported submissions more than quadrupling over three weeks in March 2026, most of it AI-generated slop a human still has to read before dismissing it. It looks much the same from the offense side, too — Dinkin and Kraft's own kernel-driver hunt flagged 521 potential vulnerabilities across 158 binaries in thirty days, but only 15 held up to manual confirmation, a 60% false-positive rate even among its highest-confidence findings.

What ties the three together: each is a point where the old model assumed a human, or tooling built at human speed, would catch the problem before it shipped — and increasingly, none of them do.

Security by Construction

The more durable answer, and the one this post keeps circling back to, is security by construction: instead of reviewing an agent's output after the fact and hoping a human or a quality-agent catches what matters, make the unsafe pattern structurally impossible to generate in the first place.

A review step can be skipped, rushed, or fooled by a plausible-looking output; a constraint enforced at generation time can't be — there's no vulnerable pattern to approve if the token space never contained one to begin with.

A forthcoming post, "Constrained Decoding for Software Security," goes deep on exactly this mechanism: grammar-constrained decoding that narrows a model's output space at the token level, so an entire defect class — a SQL query built by string interpolation, say — is never a reachable output rather than merely a flagged one. It's the same logic every pillar below is chasing, just pushed one step further upstream, from the pipeline stage after generation into the generation step itself.

That's the gap the four pillars surveyed below are actually trying to close, one lifecycle phase at a time: hardening at design and development, detection running through testing and into live deployment, containment and remediation carrying the operations phase — an SDL largely enforced by agents instead of merely assumed of them.

03 Pillar One: Software Hardening

An agent doesn't just find bugs faster than a human — it finds them cheaper, at a scale no security team can staff around, which is exactly why the industrialized threat above works as well as it does.

Researchers are converging on the obvious symmetry: if attacks come at a pace that is blazingly fast because they're agentically developed, hardening that hopes to keep pace has to be agentic too — not a human patiently writing a patch or triaging one CVE at a time, but an agent doing the hardening itself, at the same speed and the same scale the attacker operates at.

Academic Work

We can identify three distinct strategies, each intervening at a different point in the software lifecycle: adversarial self-play that hardens code without a human ever writing the exploit, proactive rewriting that removes an entire vulnerability class before an exploit exists to find, and agentic repair that fixes a real bug faster than a human could triage it.

The clearest expression of the first is adversarial self-play. Huang et al.'s RvB pits a red-team agent against a blue-team agent in an iterative, training-free game — the red team exposes an exploit, the blue team develops a defense, and neither updates its underlying weights to do it. Applied to dynamic code hardening against real CVEs, the framework reaches a 90% defense success rate at close to zero false positives — to be expected for a runtime tool — without a human ever refereeing a round.

A second line of work skips finding vulnerabilities altogether and rewrites the software so whole vulnerability classes stop being expressible. Farrukh et al.'s ORBIT is an agentic pipeline that migrates real, project-scale C codebases into safe Rust — not toy examples, but programs exceeding a thousand lines apiece from CRUST-Bench — reaching 100% compilation success and 91.7% test-suite parity while pushing unsafe code blocks to nearly zero. Sim et al.'s ENCRUST takes a two-phase approach to the same problem: an ABI-preserving wrapper pattern substitutes safe Rust functions behind an unchanged C-compatible interface, then a second agentic refinement pass resolves the cross-unit type mismatches — stray static globals, failed per-function translations — that sink function-level approaches once a project gets dependency-heavy.

A third line stays closer to the classic vulnerability-repair problem, but agentically diagnoses the bug rather than patching against the failing test case alone. Liu et al.'s ContraFix generates and executes nearby passing and failing variants of a bug, comparing their runtime states to localize the actual repair boundary before writing a patch — reaching 92% resolution on SEC-Bench at roughly double the semantic-correctness rate of the best prior baseline. Gadey et al.'s RAVEN pairs a retrieval-augmented pipeline with a dedicated agent that pulls in cross-file dependencies, repairing 83.13% of 160 real-world CVEs across multiple languages — using small, locally-run open-weight models rather than a frontier API.

The throughline across all three: hardening stops being a document written once and hoped to hold — it becomes a loop the agent keeps closing.

Each closes its own loop — red team against blue team, rewritten code against a verification gate, patch against a runtime replay — and lets the agent iterate until the loop actually closes, rather than shipping the first plausible fix.

Commercial Efforts

The commercial market, meanwhile, still ships hardening mostly the old way.

ZeroPath is the closest of the six to what came before: a static scanner, just one that reasons about what code is trying to do instead of pattern-matching known signatures, finding 2x more vulnerabilities than traditional SAST tools at 75% fewer false positives — Aptos Labs reports an 8x acceleration in vulnerability discovery after adopting it across a Rust codebase exceeding a million lines.

Chainguard ships hardened, minimal container images stripped of shells and package managers, so a compromised dependency has nothing left inside the container to execute — independent benchmarking put popular Debian-based images at an average of 239 known CVEs apiece against 0.1 for the Chainguard equivalent, a reduction competing "debloating" tools reach only 65% of the way to.

Noma Security applies the same proactive instinct to the AI supply chain itself, scanning models, datasets, and pipeline dependencies for exploitable weaknesses before they ever reach production, though it doesn't publish a comparable detection-rate figure.

Socket pushes the check further upstream still, analyzing a package's actual runtime behavior — network calls, filesystem access, obfuscation — before it's ever pulled into a build, catching roughly 100 supply-chain attacks a week across a catalog of over 16,000 malicious packages, the large majority of which never receive a CVE at all.

Edera ships hardware-backed isolation as a per-workload sandbox, eliminating the shared kernel so a compromised container has no neighbor to attack — and because it needs no hardware virtualization support, it runs on 95% of AWS instance types, against roughly 9% for a Firecracker-based alternative.

Code Metal sells the same proactive-rewrite bet as ORBIT and ENCRUST above, translating legacy C++ into memory-safe Rust for defense, automotive, and semiconductor clients — but layers on formal verification to mathematically prove the translation preserves behavior, a guarantee neither academic pipeline yet offers at production scale.

04 Pillar Two: Telemetry & Real-Time Detection

Academic and commercial efforts land on the identical wager here: instrument the runtime itself, cheaply enough to run everywhere, and let statistical models flag what doesn't match a learned baseline. Which layer gets instrumented — kernel syscalls, application logic, on-chain transactions — is a property of the system being protected, not of who's doing the protecting; the underlying bet is the same either way.

The needle-in-haystack shape of the problem is exactly what Salesforce security data scientists Matt Rittinghouse and Millie Huang described in their [un]prompted 2026 talk: hunting abuse across a platform where customers build and deploy their own AI agents, they sifted 1.8 million prompts down to just thirty real alerts — almost all of the signal this pillar is built to catch is noise, right up until it isn't.

Academic Work

Pillar one assumes the exploit never lands. Pillar two assumes it sometimes will, and moves the fight into the kernel and virtualization layer, where streaming telemetry can be scored at microsecond speed without breaking production workloads.

Three different layers get this treatment. Kernel-level work pulls telemetry straight from syscalls as they happen. Network-level work watches traffic in aggregate, splitting into two different bets on generalizing to unseen attacks: synthesizing threats that don't exist yet to train against, or trading model complexity for near-zero inference cost. Physical-layer work pushes the same instinct down to the industrial edge, reading channel-state signals instead of packets.

Zehra et al.'s DeSFAM is the clearest example of low-overhead instrumentation done right: eBPF maps and Linux Security Module hooks pull system-call telemetry directly out of the host kernel, feeding SyscallAD — a hybrid variational-autoencoder-and-isolation-forest detector that scores each call against MITRE ATT&CK- and CVE-mapped risk context — to block privilege escalation, container escapes, and syscall-injection attacks at 94% precision and 90% recall, sub-millisecond enforcement latency, and operational overhead below one percent. Li et al.'s SysArmor goes further upstream in the pipeline, embedding real-time provenance-graph construction into endpoint detection and response (EDR) — reconstructing multi-stage attack paths as they unfold, catching stealthy zero-day interactions that would slip past signature-based EDR entirely.

Several 2026 papers push the same telemetry pipeline towards zero-days specifically. Lanka and Shaik's M3-GAZE uses an adversarial generative network to synthesize evolution-consistent variants of unseen attack sequences, training the detection engine against threats that don't exist yet but plausibly could — mapping propagation across software-defined networks with temporal causal graphs. Across three benchmarks (CICIDS2017, UNSW-NB15, EMBER) it lifts zero-day detection accuracy to 92–95% and recall to 89–91%, roughly halving the false-negative rate of a non-adversarial baseline, while its uncertainty-calibration layer flags a coming attack an average of 14.7 hours before conventional detection would catch it.

Kutlimuratov et al.'s lightweight cascade framework takes the opposite tack on cost, purpose-built for zero-day network-attack detection under a strict train/test split between attack types: a high-recall, low-threshold first stage flags suspicious traffic cheaply, and a precision-oriented second stage filters false positives, holding per-flow inference latency to as little as 0.002 milliseconds on CPU-only infrastructure. Sindhu, Raju, and Sneha's NHACO closes an adaptive feedback loop around an ensemble of six classical classifiers — logistic regression, k-NN, naïve Bayes, SVM, decision tree, and random forest — retrained continuously against a drifting baseline; on the KDD Cup 1999 and NSL-KDD benchmarks it reaches 98.46% accuracy, outperforming every individual classifier in the ensemble on precision, recall, and F1.

Bouferroum et al.'s CITADEL extends the same instinct down to the physical layer for industrial IoT: channel-state-information analysis and diffusion-based reconstruction models detect jamming and protocol anomalies without any prior knowledge of the specific threat, inside a 14.2 millisecond window on edge hardware. Across six known attack types and fifteen zero-day scenarios, it reaches 100% known-attack detection and 97.1% zero-day detection at a 0.4% false-positive rate, while holding the strongest published CSI-spoofing attack to under 5% evasion even against a full white-box adversary.

Commercial Efforts

Startups are chasing the same set of problems commercially.

Upwind Security turns the Linux kernel into an active runtime monitor via eBPF, correlating system calls with application logic to trace anomalies at close to the same microsecond speed DeSFAM targets academically — customers report cutting alert volume by 85–90% and API-threat investigation time by up to 90%.

Oligo Security runs the same eBPF playbook against application behavior directly, profiling what a running workload normally does so it can flag the moment it doesn't — a cryptocurrency exchange running its platform reported an 80% reduction in vulnerability noise.

At the container layer specifically, Sysdig Secure builds on Falco — the CNCF's own eBPF runtime-security project — matching syscalls against a rules engine tuned for known-bad container behavior: reverse shells, privilege escalation, supply-chain packages that only misbehave after deployment; its ruleset reports 95% coverage of the MITRE ATT&CK framework for containers.

Aqua Security bets the opposite way on the same layer, building a behavioral allowlist per container image and blocking anything that falls outside it, rather than matching against known-bad rules — one automotive customer reported 100% critical-CVE mitigation after adopting runtime enforcement.

Hypernative applies the identical real-time-detection instinct to a different environment — web3 and smart-contract networks — watching on-chain state transitions for the signature of an exploit already in progress, reporting a 99.5% detection rate and over $2.2 billion in attempted losses flagged in 2024 alone.

Groundcover takes the zero-instrumentation eBPF sensor further into general observability, betting that the telemetry pipeline built to find performance problems is the same one that should be watching for security ones; one customer cut observability costs by over 80% after migrating onto it, though it doesn't publish a comparable security detection-rate figure.

05 Pillar Three: Containment & Blast Radius Reduction

This pillar starts from one concession: compromise is going to happen, so the only lever left is how small and how reversible the damage can be made.

What that looks like in practice is concrete, not aspirational: a compromised agent sandbox rolled back to a clean state in five milliseconds rather than a full restore, or a hijacked coding agent's credential-exfiltration attempt intercepted before it ever leaves the network.

The underlying bet is containment over prevention either way.

Academic Work

Pillar three gives up on preventing compromise altogether and optimizes purely for how small and how brief the damage window can be made once an exploit has succeeded.

Four systems below approach that from four different boundaries, moving outward from the process itself: the sandbox's own tool-call boundary, a plugin's filesystem boundary, the network boundary a browser-based agent talks through, and — once a boundary has already been crossed — the fastest possible path back to a clean state.

That tradeoff is worth measuring on its own terms rather than folding it into a single "is it secure" verdict. Three numbers actually matter here: whether the malicious action gets suppressed before it does anything real, how long the system stays exposed if it doesn't — and how fast it recovers once flagged — and how much friction the containment machinery adds to every legitimate action in the meantime. The systems below report each of these differently, but the recurring pattern is that a real gain on one axis rarely comes free on another.

Mitchell's "When the Agent Is the Adversary" evaluates architectural containment for exactly this scenario — isolating a compromised or rogue autonomous application after it has already achieved code execution inside its sandbox. The paper's structural insight is that verifiable behavioral contracts can force an application to stay within its declared boundary at the runtime layer, so that even a successfully exploited process still has its unauthorized tool calls intercepted and neutralized before they reach anything real. This is the same object-capability logic argued for in the post on runtime invariants, just enforced one privilege ring lower.

IsolateGPT and ceLLMate attack the same problem from two complementary angles. IsolateGPT builds strict, permissioned interface silos around third-party plugins so a compromised extension cannot reach the underlying filesystem — tested at scale against a real-attack benchmark, it cuts the attack success rate from 20.2% unprotected down to a regime where only 7.6% of flows even trigger a permission dialog, and 100% of those are flagged with an explicit warning before a user can approve them.

ceLLMate operates one layer up, at the network boundary, intercepting and sanitizing state-changing HTTP requests before they leave the browser; in a case study emulating a fully compromised coding agent against twelve real GitLab attack goals — credential exfiltration, project deletion, unauthorized SSH key registration — it blocked all twelve, at a measured 7.25–15% latency cost. Together the two restrict an exploit's lateral-movement options from two different directions at once.

Dong et al.'s DeltaBox closes the loop on recovery. Rather than snapshotting full system state, it continuously records only the transactional deltas between runtime states, so a compromised sandbox can checkpoint in 14ms and roll back to a verified pristine state in 5 milliseconds — cutting state-management overhead from the 23–48% of total runtime a full-snapshot baseline pays down to just 1–2%, and letting an agent explore substantially more of a search tree inside the same time budget.

The combined bet of this pillar is unambiguous: don't ask whether the action was correct — assume the answer is sometimes no, and make the cost of being wrong as close to free as physically possible.

Commercial Efforts

The commercial containment market draws two boundaries: the data itself, and identity — the latter attacked from three different angles at once.

Cyera takes the data-centric angle, discovering and classifying sensitive data across multi-cloud environments and enforcing microsegmentation so that even a compromised process has nothing reachable left to steal — its classification engine reports 95%+ precision without hand-written rules or ongoing tuning.

Identity is a useful lever precisely because it's the one thing every lateral move and every data access has to pass through, regardless of how the initial compromise happened — and three companies attack it from three different angles: watching what an identity does, restricting what it's allowed to do, and cutting it off the moment it steps out of bounds.

Permiso Security takes the watching angle: it builds a runtime identity graph across cloud accounts, identity providers, and now AI agents, correlating an identity's actions after authentication so a hijacked credential's behavior stands out from its owner's — detection, not restriction, and it doesn't publish a customer-measured efficacy number the way Cyera does.

P0 Security is the restricting angle: replacing standing, always-on privileges with just-in-time access — scoped to the task, time-bound by default — for humans, non-human identities, and agents alike, so there's less standing privilege left for a hijacked identity to abuse regardless of whether Permiso-style monitoring ever catches it; industry-wide, analysts credit JIT access broadly with cutting privileged-credential abuse risk by up to 70% and shrinking the standing attack surface by over 90%, though that figure describes the category rather than a P0-specific measurement.

SecureAuth is the cutting-off angle: real-time, per-action monitoring of what an agent is doing that can stop it mid-action and instantly revoke its access across every connected system with a single policy change, rather than waiting for a token to expire. That speed matters because the failure mode compounds fast — a single compromised agent can poison 87% of downstream decisions within four hours in a multi-agent pipeline if nothing cuts it off first.

06 Pillar Four: Autonomous Remediation

This is where academic ambition and commercial urgency line up most tightly — and where both are least proven.

Academic Work

The fourth pillar is the most recent in terms of its practical deployment, and the most ambitious: the goal is to close the loop entirely, so that detection and patching an unfolding exploit happens entirely in real time and without a human anywhere on the critical path.

Lau et al.'s ZeroDayBench exists to answer a question many others optimistically tend to skip: how good are autonomous remediation agents actually, once you control for memorized training data?

The benchmark ports 22 known CVEs into alternate, functionally distinct repositories, then scores frontier models — GPT-5.2, Claude Sonnet 4.5, Grok 4.1 Fast — purely on their capacity to analyze the crash state and synthesize a working source-level patch. Given nothing but a bare zero-day description, all three succeed on fewer than 15% of cases; hand the same models the vulnerability's location and nature up front, and the best of them jumps to 95.7%. It's a baseline, not a victory lap — and the size of that gap says something about how thin the evidence base for full autonomy still is.

This is the pillar carrying out the most buzzword-friendly work — "fully autonomous," "closed-loop," "machine-speed." It is also the pillar with the thinnest empirical floor, which is exactly why ZeroDayBench had to exist in the first place.

Wang and Cheng's zero-touch remediation framework is further along the deployment curve: it couples OpenVAS vulnerability scanning with retrieval-augmented patch generation, pulling context from distributed threat intelligence to draft source-level fixes automatically. Across 350 real-world vulnerability cases, adding retrieval lifts patch accuracy from 52.0% to as high as 82.6% and cuts hallucinated fixes from 23.4% down to 7.8%; a confidence-routing layer then auto-deploys the 34.9% of patches it's most certain of, at just a 4.1% rollback rate and zero production outages.

Basta et al.'s Pro-ZD takes a related graph-based idea and pushes it upstream: a transferable graph neural network that generalizes across network topologies, identifying high-risk connections at over 95% accuracy and automatically retuning firewall rules and access policies around them before an attack fully executes, rather than waiting to observe one first.

Alsuwaiket's ZeroDay-LLM distributes the same responsibility across specialized agents — one ingesting logs, one parsing execution metrics, one monitoring application logic — translating raw telemetry into semantic context so the network can catch logical anomalies that bypass traditional signature scanners. Across CICIDS2017, NSL-KDD, and UNSW-NB15, it reaches 97.8% accuracy on novel attack signatures while cutting false positives 23% below a traditional intrusion-detection baseline. The idea extends into cyber-physical and industrial control systems too, though the foundational argument predates this current wave: Halabi and Zulkernine outlined multi-agent reinforcement learning and game-theoretic modeling for autonomous cyber-physical defense back in 2023, aimed at protecting physical actuators and infrastructure rather than just data — the same closed-loop logic, applied earlier and to higher-stakes targets.

Commercial Efforts

Commercial interest here is just as intense as in the other pillars, with a new wave of companies betting on autonomous remediation of code that already exists, rather than governing what an agent does next — though "autonomous" still spans a real spectrum, from a human reviewing every patch to no human in the loop at all.

Mobb plugs directly into existing SAST scanners — Checkmarx, Snyk, Fortify, and others — and auto-generates fixes for over 100 issue types those tools already flag but nobody had time to patch; its Checkmarx integration reports cutting time-to-remediation by 99%, from nearly five hours down to five minutes on average. Its fix engine deliberately avoids pure LLM generation, pairing static analysis and deterministic security algorithms with AI instead, so a developer can review and commit the resulting patch in under 60 seconds without leaving their existing workflow.

Pixee triages the scanner findings first, cutting the noise before it ever reaches a fix: a 98% noise reduction against raw scanner output, with the fixes it does generate reaching a 76% merge rate once a human reviews them — by design, not as a limitation; architectural and cross-service changes get flagged for a person rather than auto-fixed at all.

Corgea closes the loop end-to-end — finding, validating, and generating a safe fix for a real vulnerability in one pass — and reports fix accuracy above 90%; its autonomous pentesting engine surfaced 25 findings against a human pentester's six, in four to eight hours rather than the usual two-week engagement.

Cogent Security sits at the far end of that spectrum: Zero Day Response ingests CVE and pre-CVE disclosures and cross-references them against a customer's actual software inventory within minutes of publication, then Autonomous Remediation builds a fix plan, runs a preflight business-impact check, and lets customers dial autonomy anywhere from full human approval on critical production systems to fully autonomous execution elsewhere — Fortune 500 customers report a 97% reduction in mean time to remediate critical vulnerabilities.

The fact that capital is chasing this pillar as hard as any other is itself a data point: the market agrees with this post that autonomous response is as urgent to close as prevention, detection, or containment — even though, empirically, it's the pillar resting on the thinnest floor.

07 How Do We Measure Success?

Laid end to end, the four pillars above are four stages of a single lifecycle, not four competing bets — the same one Figure 1 mapped out at the start of this post.

Closing the Loop

The forward arrows are the easy part, and every system reviewed above sits on one of them: hardening feeds detection, detection triggers containment, containment triggers remediation. The dashed arrows running backward are where a lifecycle's actual value has to live:

• Software Hardening is supposed to tell detection which vulnerability classes it just eliminated and which remain pressing, so the next pillar stops spending signal on threats that are now structurally impossible.
• Telemetry & Real-Time Detection is supposed to refine its own detection fidelity and hand Software Hardening fresh threat signatures to build against.
• Containment & Blast Radius Reduction is supposed to inform forensics and feed state-recovery data back into detection.
• Autonomous Remediation is supposed to feed learned patterns back into hardening and detection alike, closing the loop across the entire stack.

Not one of the projects surveyed above — academic or commercial — closes any of these feedback loops end-to-end. Each optimizes its own box, and stops there. That gap is exactly what the rest of this section measures.

Chasing End-to-End Measurements

The honest answer is: mostly one stage at a time.

DARPA's AI Cyber Challenge, covered early in this post, is the closest thing to a combined score that already exists — teams are graded on discovering and patching synthetic vulnerabilities in the same competition round, which is why its jump from 37% to 86% mattered so much.

But it's still a two-stage score inside a controlled competition environment, not a measure of a live, adversarial, months-long production deployment.

ZeroDayBench, from Pillar Four, does something narrower but sharper: it isolates patch synthesis specifically, controlling for the possibility that a model has simply memorized the fix from its training data — which is exactly how it caught frontier models collapsing to under 15% success once that shortcut was closed off.

A newer benchmark pushes the chain further. CyberGym-E2E links discovery, proof-of-concept generation, and patch synthesis into one connected pipeline across 920 real-world vulnerabilities spanning 139 open-source projects — scoring an agent on whether it can carry a single bug all the way from "found it" to "proved it" to "fixed it," rather than grading each step against a different benchmark built by a different team.

That's real progress, and it's still not the question this post has actually been asking. CyberGym-E2E is vulnerability-centric: one bug, three steps, one pipeline. The four-pillar lifecycle this post has traced is loop-centric — hardening feeds detection, detection feeds containment, containment feeds response, response feeds back into hardening — and no benchmark cited anywhere in this post scores that full loop as a single system.

Scoring the Whole Loop

Khurana and Jain's "SoK: Measuring What Matters for Closed-Loop Security Agents" names this gap directly: evaluation of closed-loop security agents remains fragmented across isolated defensive functions, "creating blind spots that adversaries exploit" — precisely the blind spot mapped arrow by arrow above.

The Closed-Loop Autonomous Security Performance (CLASP) framework, pairs five lifecycle functions — reconnaissance, exploitation, root-cause analysis, patch synthesis, validation — against the agentic capabilities behind them, and rolls the result into a single CLC Score: a composite metric for degree of loop closure and operational effectiveness together, rather than five isolated stage grades averaged and hoped to mean something.

• The mechanics are worth spelling out, because they encode a real opinion about what "success" should mean. The CLC Score isn't an average of stage grades — it's a product: efficacy times efficiency, where efficacy blends completion rate, fix correctness, and time-to-close, and efficiency compares how much agentic capability a system actually deployed against how much the task required, penalizing brute-force over-engineering roughly as harshly as it penalizes under-powered attempts.
• Multiplying instead of averaging is the whole point: under this scoring, a system that closes the loop inefficiently still earns partial credit, but one that fails efficiently earns none.
• Applied across 21 representative closed-loop systems, the framework surfaces exactly the pattern this post has traced pillar by pillar: real capability at individual stages, and no consistent discipline yet for scoring the seams between them.

Every benchmark in the table above, CLASP included, is still a controlled proxy — synthetic targets, ported CVEs, curated pipelines, scored in a lab.

08 Conclusions

For twenty years, defense meant something specific: signatures updated after the fact, patches shipped on a human cadence, and a security team's job was to read enough of an incident to write the rule that stops the next one. That model assumed the attacker was slower than the defender's paperwork — a fair assumption when finding a zero-day took a specialist months and weaponizing it took another team entirely.

The next twenty years cannot assume that. When primitive discovery, exploit coordination, and patch synthesis all run on agent time instead of human time, a defense built around updating rules after an analyst reads an incident report isn't a lagging strategy — it is not a strategy at all.

The attacker side of this equation has industrialized in ways this post has mostly left implicit: coordinated agent teams compress novel-exploit development into hours, and the economic-deterrence framing this post opened with means that number will keep shrinking, not stabilizing. Reactive, human-paced patching was already losing to that arithmetic before any of the four pillars surveyed here existed. That's the same acceleration this post opened with: a $100 million zero-day reproduced for $0.11 per million tokens, DARPA's detection rate nearly doubling in a year. It's rewriting the software development lifecycle itself, not just the exploits aimed at what it produces.

Verizon's 2026 Data Breach Investigations Report puts a number on that same erosion industry-wide: vulnerability exploitation overtook stolen credentials as the single biggest point of entry for the first time in the report's 19-year history, now the start of 31% of all breaches — while the median time to fully patch a known-exploited vulnerability rose to 43 days, up from 32, and the share of those vulnerabilities actually getting patched fell to just 26%, down from 38%. Attackers are getting in faster through exactly the door this post has been describing, and defenders are closing it slower.

All of this argues against a natural but mistaken instinct: picking whichever pillar looks most mature and betting the security budget there.

CyberGym-E2E and Khurana and Jain's CLC Score are the closest anyone's come to scoring that whole loop — but neither has been pointed at a real four-pillar stack, in production, against a real adversary, over a real deployment window. That evaluation is no longer optional.

This post opened by admitting it's too soon to tell which pillar matters most — the industrialization on both sides of this equation means that answer is coming, ready or not.

References

• Epp, S. "Zero Day Clock." Time-to-exploit tracker across 83,000+ disclosed CVEs. Available at: zerodayclock.com
• Heelan, S. (2026). "On the Coming Industrialisation of Exploit Generation with LLMs." Available at: sean.heelan.io
• Dinkin, Y., & Kraft, E. (2026). "100+ Kernel Bugs in 30 Days." Available at: ydinkin.substack.com
• Fort, S. (2026). "AI Cybersecurity After Mythos: The Jagged Frontier." AISLE. Available at: aisle.com/blog

• Carlini, N. (2026). "Black-hat LLMs." Talk, [un]prompted 2026. Available at: youtube.com/watch?v=1sd26pWhfmg
• Krivka, A., & Vlcek, O. (2026). "AI Found 12 Zero-Days In OpenSSL." Talk, [un]prompted 2026. Available at: youtube.com/watch?v=IjL2qN1KDe8. The underlying finding is documented in Fort, S. (2026). "What AI Security Research Looks Like When It Works." AISLE. Available at: aisle.com/blog
• DARPA. "AI Cyber Challenge Marks Pivotal Inflection Point for Cyber Defense." Available at: darpa.mil/news/2025/aixcc-results
• Rittinghouse, M., & Huang, M. (2026). "1.8M Prompts, 30 Alerts: Hunting Abuse in a User-Defined Agent Ecosystem." Talk, [un]prompted 2026. Available at: youtube.com/watch?v=PtWwrOm3BeE

• Koch, C. (2026). "Agentic AI and the Industrialization of Cyber Offense: Forecast, Consequences, and Defensive Priorities for Enterprises and the Mittelstand." arXiv:2605.06713. Available at: arxiv.org/abs/2605.06713
• Cloud Security Alliance AI Safety Initiative. (2026). "The Collapsing Exploit Window: AI-Speed Vulnerability Weaponization." CSA Labs. Available at: engage.checkpoint.com
• Decrypt. (2026). "AI Slop Floods Bug Bounty Programs as Companies Struggle with Fake Reports." Available at: decrypt.co

• Cloud Security Alliance. (2026). "Agentic Secure Development Lifecycle (ASDL) v1." CSA Labs. Available at: labs.cloudsecurityalliance.org
• Microsoft Security Blog. (2026). "Microsoft SDL: Evolving Security Practices for an AI-Powered World." Available at: microsoft.com/security/blog
• Hughes, C., & Norton, K. (2026). "Securing the Agentic SDLC." Resilient Cyber. Available at: resilientcyber.io
• WindowsForum. (2026). "Microsoft SDL for AI: A Practical Security Framework for AI in Production." Forum discussion. Available at: windowsforum.com
• Clover Security. (2026). "Securing the Agentic SDLC." Available at: clover.security
• Snyk. (2026). "The Agentic Development Lifecycle." Available at: snyk.io

• Zhu, Y., Kellermann, A., Gupta, A., Li, P., Fang, R., Bindu, R., & Kang, D. (2024). "Teams of LLM Agents can Exploit Zero-Day Vulnerabilities." Proceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics (EACL '26), 23–35. arXiv:2406.01637. Available at: arxiv.org/abs/2406.01637
• Peng, J., Li, Z., You, C., Wang, Y., Sun, H., et al. (2026). "Hackers or Hallucinators? A Comprehensive Analysis of LLM-Based Automated Penetration Testing." arXiv:2604.05719. Available at: arxiv.org/abs/2604.05719
• Migliorelli, C., Mambretti, A., Sorniotti, A., Zaccaria, V., & Kurmus, A. (2026). "Cross-Cache Attacks for the Linux Kernel via PCP Massaging." Proceedings of the Network and Distributed System Security Symposium (NDSS '26).
• Rashidi, M. (2026). "The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities." arXiv:2607.05743. Available at: arxiv.org/abs/2607.05743

• Shi, T., Rheem, R., Jiang, D., et al. (2026). "CyberGym-E2E: Scalable Real-World Benchmark for AI Agents' End-to-End Cybersecurity Capabilities." arXiv:2606.04460. Available at: arxiv.org/abs/2606.04460
• Khurana, M., & Jain, R. (2025). "SoK: Measuring What Matters for Closed-Loop Security Agents." arXiv:2510.01654. Available at: arxiv.org/abs/2510.01654

• Huang, L., Liu, Z., Zhang, J., Yan, L., Liu, D., & Shao, J. (2026). "RvB: Automating AI System Hardening via Iterative Red-Blue Games." arXiv:2601.19726. Available at: arxiv.org/abs/2601.19726
• Farrukh, M., Coskun, B., Palit, T., & Polychronakis, M. (2026). "ORBIT: Guided Agentic Orchestration for Autonomous C-to-Rust Transpilation." arXiv:2604.12048. Available at: arxiv.org/abs/2604.12048
• Sim, H., Cho, H., Shokri, A., Fu, Z., & Ravindran, B. (2026). "ENCRUST: Encapsulated Substitution and Agentic Refinement on a Live Scaffold for Safe C-to-Rust Translation." arXiv:2604.04527. Available at: arxiv.org/abs/2604.04527
• Liu, S., Liu, F., Wang, P., Li, T., Zhu, Y., Lian, X., & Zhang, L. (2026). "ContraFix: Skill-Enhanced Contrastive Runtime Analysis for Vulnerability Repair." arXiv:2605.17450. Available at: arxiv.org/abs/2605.17450
• Gadey, V., Liu, Z., & Dmitrienko, A. (2026). "RAVEN: Agentic RAG for Automated Vulnerability Repair." arXiv:2606.22647. Available at: arxiv.org/abs/2606.22647

• Zehra, S., Syed, H. J., Samad, F., & Faseeha, U. (2025). "DeSFAM: An Adaptive eBPF and AI-Driven Framework for Securing Cloud Containers in Real Time." IEEE Access, 13, 139203–139224. DOI: 10.1109/access.2025.3592192
• Li, S., Jin, J., Jiang, H., Huang, Y., Bao, Y., Meng, Y., Hong, F., Huang, Z., Li, D., & Jiang, P. (2026). "SysArmor: The Practice of Integrating Provenance Analysis into Endpoint Detection and Response Systems." Proceedings of the Network and Distributed System Security Symposium (NDSS '26).
• Lanka, K., & Shaik, K. (2026). "An Integrated Evolution-Aware Meta-Learning Framework with Adversarial Morphological Augmentation for Zero-Day Threat Detections." Frontiers in Artificial Intelligence, 9, article 1814012.
• Kutlimuratov, A., Rakhmatov, F., Khamzaev, J., Saymanov, I., Allayarov, P., Bekbaev, G., Otamurodov, S., & Makhmudov, F. (2026). "A Lightweight Cascade-Based Framework for Real-Time Zero-Day Attack Detection." Computers, 15(3), article 174. DOI: 10.3390/computers15030174
• Sindhu, K., Raju, M., & Sneha, Y. (2026). "Neuro-Hybrid Adaptive Cybersecurity Orchestration for Real-Time Zero-Day Resilience and Intelligent Threat Response." International Research Journal of Multidisciplinary Scope (IRJMS), 7(2), 1711–1732. DOI: 10.47857/irjms.2026.v07i02.09007
• Bouferroum, A., Alla, I., Loscri, V., Benslimane, A., & Lenders, V. (2026). "CITADEL: CSI-Based Jamming Detection and Open-Set Classification for IIoT Networks." arXiv:2606.22939. Available at: arxiv.org/abs/2606.22939

• Mitchell, R. J. (2026). "When the Agent Is the Adversary: Architectural Requirements for Agentic AI Containment After the April 2026 Frontier Model Escape." arXiv:2604.23425. Available at: arxiv.org/abs/2604.23425
• Wu, Y., Roesner, F., Kohno, T., Zhang, N., & Iqbal, U. (2024). "IsolateGPT: An Execution Isolation Architecture for LLM-Based Agentic Systems." Proceedings of the Network and Distributed System Security Symposium (NDSS '25). arXiv:2403.04960. Available at: arxiv.org/abs/2403.04960
• Meng, L., Feng, H., Shumailov, I., & Fernandes, E. (2025). "ceLLMate: Sandboxing Browser AI Agents." arXiv:2512.12594. Available at: arxiv.org/abs/2512.12594
• Dong, Y., He, J., Hou, Y., Du, D., Xu, Z., Yu, S., Xia, Y., & Chen, H. (2026). "DeltaBox: Scaling Stateful AI Agents with Millisecond-Level Sandbox Checkpoint/Rollback." arXiv:2605.22781. Available at: arxiv.org/abs/2605.22781

• Lau, N., Sloot, L., Raj, J., Boscardin, G. M., Harris, E., Bowman, D., Brajkovski, M., Chawla, J., & Zhao, D. (2026). "ZeroDayBench: Evaluating LLM Agents on Unseen Zero-Day Vulnerabilities for Cyberdefense." Proceedings of the ICLR Workshop on Agents in the Wild. arXiv:2603.02297. Available at: arxiv.org/abs/2603.02297
• Wang, Y.-C., & Cheng, C.-Y. (2026). "A Zero-Touch Vulnerability Remediation Framework Based on OpenVAS, Threat Intelligence, and RAG-Enhanced Large Language Models." Mathematics, 14(6), article 1072. DOI: 10.3390/math14061072
• Basta, N., Ben Hmida, F., Jmal, H., Ikram, M., Kaafar, M. A., & Walker, A. (2026). "Pro-ZD: A Transferable Graph Neural Network Approach for Proactive Zero-Day Threats Mitigation." arXiv:2602.07073. Available at: arxiv.org/abs/2602.07073
• Alsuwaiket, M. A. (2025). "ZeroDay-LLM: A Large Language Model Framework for Zero-Day Threat Detection in Cybersecurity." Information, 16(11), article 939. DOI: 10.3390/info16110939
• Halabi, T., & Zulkernine, M. (2023). "The Ultimate Battle Against Zero-Day Exploits: Toward Fully Autonomous Cyber-Physical Defense." Proceedings of the 2023 IEEE International Conference on Software Services Engineering (SSE).