Draft complete but not yet reviewed; expect revisions

Cyber Capability and Defense

Every capability that finds a flaw in software can be used to fix it or to exploit it. Cyber operations are therefore the domain where a model's usefulness and its danger are hardest to separate, and the one where capability evaluations have already had consequences. In 2026 a developer held a model back from general release because of what it could do to software; a second reported pausing its largest training run after evidence that a coming model might reach a critical cyber threshold; a government ordered classified benchmarking of models' cyber capabilities; and an open-weight model that one developer found comparable in exploit development arrived months later without comparable safeguards. The previous chapters asked what a model does with an opportunity to act against its principal (Chapter 56) and what changes when many models interact (Chapter 57). This one asks what happens when the capability itself is the hazard.

Two relationships are in view, and the chapter keeps them apart. Most of the evidence concerns misuse: a system that does what its user asks, aligned to that user and harmful to everyone the user attacks, the limiting case of a plural principal (Section 1.4), where "misuse" means a user directing a capability at targets the developer and the public did not consent to. Some of the evidence concerns misalignment: models in cyber evaluations that reached real systems no one had authorized them to touch, whose facts Section 54.4 reports and whose alignment reading is Section 56.4's, and which this chapter recalls only for what they show about evaluation itself. Throughout, the chapter reports evaluations, findings, and defenses at the level their authors published them. It describes no technique, no vulnerability beyond what a source's summary states, and no attack procedure.

58.1 Why cyber comes first #

The question of this section is why cyber was the first domain in which capability evaluations changed what developers and governments did. A few terms recur. A vulnerability is a flaw in software that lets someone make it behave in a way its maintainers did not intend; an exploit is a concrete input or program that turns a vulnerability into that effect. A zero-day is a vulnerability unknown to the software's maintainers, so no fix exists; an N-day is one that is public and patched but not yet patched everywhere, and the patch gap is the interval between a fix's release and its installation on a given system. A capture-the-flag task is a contest in which a solver retrieves a hidden secret from a deliberately vulnerable system; a cyber range is a simulated network built for testing; and fuzzing is testing a program with large numbers of generated inputs to see what makes it fail.

As of October 2026 the developers' safety frameworks already treat cyber as a tracked risk, and Section I.2.5 gives what each sets out. How these frameworks work as a class is Chapter 62' subject; here they establish only that cyber capability is something the developers committed in advance to measure and to act on.

What the thresholds changed in 2026 is the chapter's starting fact. One developer gave a general-purpose model only a limited release, to a limited group of industry partners and open-source developers through a named program, because of its security capabilities (Anthropic, 2026i) (developer blog post, April 2026). A second stated that it had slowed scaling, including a two-week pause in reinforcement learning training of models intended for deployment, and kept its largest planned run on hold, after a cyber incident and preliminary evidence that an upcoming model might meet its Critical cybersecurity threshold (OpenAI, 2026q) (developer statement, August 2026); the monitoring and containment side of that response is Section I.3.11'. That developer's system card for the model, GPT-6 Astra, then reported in September 2026 that Astra was its first model "to reach the Critical level of cybersecurity capability" (OpenAI, 2026l) (developer report). And a June 2026 executive order directed a classified process to benchmark models' cyber capabilities (Executive Office of the President, 2026) (government order); Section I.1.8 gives its other provisions as of October 2026. As of October 2026 we found no other capability domain in which evaluations had produced this combination of a withheld model, a paused training run, and a government benchmarking order.

The scientific synthesis is more measured than any single developer's post. The 2026 International AI Safety Report states that AI systems can discover software vulnerabilities and write malicious code, that criminal and state-associated groups are using general-purpose AI in their operations, and that whether attackers or defenders benefit more from AI assistance "remains uncertain"; it notes that fully autonomous end-to-end attacks have not been reported in the real world (Bengio et al., 2026) (international report). Its 2025 predecessor had already concluded that cyber capabilities were "significantly advancing" while it remained "unclear whether this will affect the balance between attackers and defenders" (Bengio et al., 2025b) (international report). The rest of the chapter is largely an account of why that balance is hard to call.

Which relationship each claim concerns matters here (Section 1.3). Misuse is the limiting case of the common-agency structure of Section 14.4: the user's instrument dominates, and the cost falls on third parties who made the agent no offer and have no weight in what it does. The misalignment cases concern the training process and the deployed system; the chapter marks each as it arises.

58.2 Offense, defense, and the attack chain #

A cyber operation is not one act but a sequence of stages: an attacker finds a way in, moves through a system, and reaches an objective. A capability matters to the extent that it moves the stage that limits the whole sequence, and the balance between attack and defense is not a fixed property of a technology but a function of how much each side invests. This section teaches those two ideas before the evidence, because together they say what a benchmark score does and does not imply about a real operation.

58.2.1 The attack chain #

Computer security describes an operation as an attack chain (or kill chain): a staged sequence from reconnaissance through gaining access, moving inside a system, and acting on the objective. A 2025 framework from Google DeepMind adapts existing attack-chain frameworks to AI by analyzing more than 12,000 real-world instances of AI involvement in cyber incidents catalogued by its company's threat intelligence group, distilling them into seven representative attack-chain archetypes, and locating the stages most open to AI assistance through a bottleneck analysis (Rodriguez et al., 2025) (developer preprint, 2025). The framework's bottleneck is defined by cost: a stage that has historically demanded the most time, expertise, or scarce skill, so that lowering its cost changes an operation the most. The authors call this the "cost collapse" argument and propose tracking AI's effect as a change in the cost of a fixed "basket" of attack patterns, by analogy to measuring inflation (Rodriguez et al., 2025). Piloted on Gemini 2.0 Flash experimental, which solved 11 of 50 challenges, the framework found the model primarily raised threat actors' speed and scale rather than enabling breakthrough capabilities, and that evaluations had concentrated on vulnerability exploitation while under-measuring reconnaissance, evasion, and persistence (Rodriguez et al., 2025).

The same chain structure supports a quantitative statement of why the bottleneck decides outcomes, which the book draws as an inference from the framework rather than taking from it.

Figure 58.1 shows the two facts together: the chain's success is the product of the stages, so a single weak stage holds it down, and uplift helps most where the stage is weakest. The N-day evidence in Section 58.3 is read through the defended chain, because the patch gap is exactly the window in which a defender's detections have not yet closed.

58.2.2 The balance between offense and defense #

Whether a new capability favors attack or defense is not fixed, a question international relations has studied for decades. In a 2019 analysis, Garfinkel and Dafoe formalize the offense-defense balance through contest success functions and ask how it scales as both sides invest more. Their abstract reports that in simple models of both ground invasions and cyberattacks that exploit software vulnerabilities, growth in investment favors offense when investment levels are low and favors defense when they are high, a pattern they call offensive-then-defensive scaling; they suggest it may help in reading the security implications of applications of AI that scale up existing capabilities (Garfinkel and Dafoe, 2019) (the paper's abstract reports this; peer reviewed). The balance is therefore a property of how much each side invests, not of the technology alone.

A second analysis asks the balance of a specific choice: whether publishing a capability helps attackers or defenders more. Shevlane and Dafoe argue that the answer depends on how easily an effective defense can be built and propagated and on whether others would discover the knowledge anyway, which they call counterfactual possession (Shevlane and Dafoe, 2019) (preprint). Software vulnerabilities are, on their account, unusually defense-favoring: a patch is often cheap to write, fully resolves the flaw, and propagates automatically over the internet, and vulnerabilities are in constant enough supply that independent discovery is likely (Shevlane and Dafoe, 2019). The authors warn that the AI debate imported this conclusion from software security without checking that its assumptions hold, since for AI "social" vulnerabilities there may be no cheap, effective, propagable fix (Shevlane and Dafoe, 2019). The N-day results below test exactly the assumption that a patch propagates in time.

Two limits on detection by inspection bound what a defender can do. Detecting a computer virus in general is undecidable, an early statement of the limit that Section 47.6 and Section 28.6.2 teach through Rice's theorem, that no algorithm decides a non-trivial property of every program (Cohen, 1987) (cited for its existence; the result is stated through the owned sections). And because genuine attacks are rare among events, an intrusion detector needs an extremely low false-alarm rate for its alarms to be worth acting on, the base-rate arithmetic that Section 6.7 derives and Section 54.2.3 applies to model monitors (Axelsson, 2000).

Time is the defender's other variable. Before AI, the window from a fix to its exploitation was often short but not instant. A 2020 analysis by Mandiant of sixty vulnerabilities from 2018 and 2019 found that the majority were exploited as zero-days, before any patch, and that of those first exploited after a patch, exploitation frequently came within hours or days, with the average interval from disclosure to a patch's availability about nine days (Mandiant, 2020) (threat-intelligence report). That interval is the defender's exposure, and an economic analysis of automated exploitation of financial smart contracts shows how much the window decides. Using historical attacks, and assuming the tool is available only to defenders, it found immediate detection giving an 86 to 89 percent chance of beating an attacker, falling to 6 to 21 percent with a week's delay. A separate model in the same paper gives both sides the same tool at 3 dollars a scan and assumes one contract in a thousand is exploitable; in it, attackers break even at exploit values around 6,000 dollars while defenders, who the analysis assumes capture only a tenth of the value as a bug bounty, need around 60,000 dollars (Gervais and Zhou, 2025) (preprint). That asymmetry is a consequence of the bounty fraction the analysis assumes, not of the technology alone.

58.3 Measuring cyber capability #

How well models do cyber tasks has been measured from knowledge questions through capture-the-flag tasks, vulnerability-reproduction benchmarks, exploitation ladders, cyber ranges, and money. This section reports the evaluations by design, with the model, the date, and who ran them, and reads each headline result against two questions: what the task actually measures, and what it would take for the score to mean uplift in a real operation. The kinds of evidence are a government evaluator's time series, academic benchmarks, and developers' reports on their own models, and the section keeps them labeled because they differ in independence.

58.3.1 A government time series #

The UK AI Security Institute, a government body, has published a time series of frontier models' cyber capability from its own testing. In its 2025 Frontier AI Trends Report it states that the best models now complete apprentice-level cyber tasks about 50 percent of the time on average, against just over 10 percent in early 2024, and that in 2025 it tested the first model able to complete expert-level tasks, those it defines as typically requiring more than ten years of a human practitioner's experience (UK AI Security Institute, 2025b) (government report, 2025). The same report measures how fast the length of cyber task a model completes unassisted is growing, which Section 36.3.2 reports as part of the book's account of time horizons, and how much a refined scaffold raises a model's score, which Section 36.2.2 reports. The institute states that it may generally underestimate the ceiling of capabilities, and that without bespoke scaffolding its evaluations may underestimate the true ceiling of models' cyber capabilities (UK AI Security Institute, 2025b). This chapter reports the apprentice-to-expert completion series; the other two chapters report the trend's rate and the elicitation gain, recalled here only so the series is not read as more than it is.

58.3.2 Benchmarks, from tasks to exploits #

The academic and developer benchmarks move up a ladder of difficulty, from solving a contest challenge, to reproducing a known vulnerability, to building a working exploit from it. Table 58.1 lays the main results out with their design and provenance; the paragraphs after it read the ones the chapter leans on.

On the capture-the-flag end, Cybench, a benchmark published at ICLR 2025 by Zhang and colleagues, pairs forty professional contest tasks with each task's first-solve time, the time the first human team took in the original competition (Zhang et al., 2025a). Without being given the intermediate subtasks, the best agents on 2024 models solved complete tasks whose human first-solve time was up to 11 minutes, while the hardest task had a first-solve time of 24 hours and 54 minutes, and first-solve time predicted difficulty for the agents as well (Zhang et al., 2025a). Two developer and government programs frame these scores. Google DeepMind's dangerous-capability evaluations, piloted on Gemini 1.0 in 2024, found no strong dangerous capabilities but "early warning signs," a program Section 3.7.1 reports (Phuong et al., 2024) (developer preprint). And a developer entered its model in seven public cyber competitions in 2025, where it often placed in the top quarter but lagged the best human teams on the toughest challenges and solved no challenges at the two hardest competitions it entered, the kind of grounding against human fields that a benchmark score alone does not give (Anthropic, 2025o) (developer blog post).

On real vulnerabilities at scale, CyberGym, a 2025 preprint by Wang and colleagues, asks agents to generate a test that reproduces each of 1,507 real-world vulnerabilities across 188 projects given only a description and the code; the best agent-and-model combinations reached about 20 percent, and the work surfaced 34 previously unknown vulnerabilities and 18 historically incomplete patches as a by-product (Wang et al., 2025b). Reproducing a flaw is not yet exploiting it, and two 2026 benchmarks grade the harder step. The first, ExploitBench, grades exploitation of 41 bugs in a hardened browser JavaScript engine on a ladder of sixteen capabilities, from reaching the vulnerable code through escaping the engine's sandbox to arbitrary code execution. Across eight publicly deployed frontier models, reaching the bug and triggering a crash was routine, but arbitrary code execution was not, with only one public model achieving it, on a single bug and only with its vendor's command-line tooling. A not-yet-public research model, included as a reference point and run by its developer with the benchmark's authors verifying the results, reached arbitrary code execution on 18 of 41 bugs with no vendor scaffolding (Lee and Brumley, 2026) (preprint, 2026). The authors read the stall across the public models as a limit on reasoning rather than on the attempt budget, since the cost of each rung grew by roughly an order of magnitude and runs did not stall by exhausting their budget (Lee and Brumley, 2026). The second, ExploitGym, applies a common framework to 898 real vulnerabilities across user programs, the same browser engine, and an operating-system kernel; with the targets' standard defenses turned off, the models' deployment-time safety filters disabled under the developers' trusted-access programs, and a two-hour limit, the strongest configurations produced working exploits for 157 instances (Claude Mythos Preview with Claude Code) and 120 (GPT-5.5 with Codex CLI), with non-trivial success rates even when common defenses were left on (Wang et al., 2026) (preprint, 2026). With OpenAI's default safety filters on, every GPT-5.5 exploit attempt under default prompting was blocked (Wang et al., 2026). The developer ran its own models' trials, which the benchmarks' authors verified or scored, and reports that its strongest model outperformed the others on both benchmarks and on a smart-contract exploitation benchmark (Anthropic, 2026af) (developer blog post with the benchmarks' authors). The benchmarks are academic, but the frontier numbers for the withheld model were produced by the developer and verified or graded by the authors, which is neither an independent measurement nor a pure self-report.

Money is a fourth metric, useful because it prices an exploit directly. On SCONE-bench, 405 blockchain smart contracts exploited between 2020 and 2025, agents developed exploits for contracts breached after their training cutoffs worth 4.6 million dollars in simulation, and simulated exploit revenue roughly doubled every 1.3 months over a year; all of the work was done in simulators, never on live systems (Anthropic, 2025c) (developer blog post with academic fellows, 2025).

58.3.3 Cyber ranges #

A capture-the-flag task is a puzzle; a cyber range is a whole simulated network on which an agent must chain many steps. With a purpose-built toolkit that translated an agent's high-level intentions into low-level commands, models fully compromised five of ten simulated networks of 25 to 50 hosts and partly compromised four more, against near-complete failure without the toolkit; the networks had no active defenses and the attacks used known vulnerabilities, and some of the toolkit was built for these scenarios (Anthropic, 2025ac) (developer blog post with a university, June 2025). A later model succeeded on a minority of the same networks with standard tools alone, exfiltrating the simulated data in a high-fidelity reconstruction of a historical breach in two of five trials, though for five of nine networks it still needed the toolkit (Anthropic, 2026b) (developer blog post, January 2026). An in-depth evaluation of two earlier models by the developer with an outside firm reported the same direction of travel, markedly improved adaptation with limitations on long-horizon planning (Anthropic, 2025r) (developer blog post with a security firm). All three are developer reports, and the ranges carry the caveat their authors state: without active defenses, they are easier to compromise than a defended network.

58.3.4 The 2026 step and the N-day result #

The sharpest results of 2026 are a developer's reports on one model it did not release generally. The developer states that the model, directed by a user, found and exploited previously unknown vulnerabilities in every major operating system and web browser, that over 99 percent of what it found was unpatched at the time of writing and is withheld under coordinated disclosure, and that engineers on its staff without security training could direct it to produce working exploits overnight (Anthropic, 2026i) (developer blog post, April 2026). On its internal five-tier severity ladder over roughly 7,000 entry points into open-source projects, the model achieved 595 crashes at the two lowest tiers and full control-flow hijack on ten separate, fully patched targets, against a single tier-three crash for the previous model generation; and on a set of browser JavaScript-engine vulnerabilities, where the previous model had turned 2 of several hundred attempts into working exploits, this model produced 181 working exploits and reached a weaker form of control on 29 more (Anthropic, 2026i). The developer presents the capability as emerging as a by-product of general improvements in code and reasoning, not from cyber training, and as a lower bound, since its disclosure process let it report only a fraction of what it found (Anthropic, 2026i).

The N-day result bears directly on the patch gap of Section 58.2. On known, patched flaws, the same model produced working code-execution exploits from 8 of 18 recent browser security patches, tested on a standalone build of the browser's JavaScript engine rather than the full browser, and from 8 of 21 operating-system kernel patches, given only what an attacker would have on the day a patch is published and, for the browser, writing its first working exploit in just under an hour of work. For those browser fixes, the developer puts the median gap from a fix's publication to the release that shipped it at 19 days, before any delay in installing the release (Anthropic, 2026ag) (developer blog post, June 2026). The developer frames the finding as the collapse of exploit development, historically weeks of expert work, into hours, and argues that monthly patch cadences and multi-week staged rollouts were built on the assumption that weaponizing a patch is slow (Anthropic, 2026ag). The strongest counter-reading is the provenance: these are self-reports by the model's developer, and as of October 2026 we found no independent replication of the zero-day and N-day results, though the developer's exploit numbers on the academic benchmarks of Section 58.3.2 were verified or graded by those benchmarks' authors. The developer's own earlier work found its public models much better at finding vulnerabilities than at exploiting them (Section 58.5). What the N-day result would mean if it holds is that the defended chain of (58.2) loses its time-based protection, because the defender's window closes after the attacker's does.

Two facts bound how any of these scores should be read. A score is a lower bound on what the model can do, because scaffolds, tools, and prompting raise measured capability without retraining (Section 36.2) and a model can strategically underperform on an evaluation (Section 36.2.3) (Davidson et al., 2023; van der Weij et al., 2025). And a score can be an over-estimate, because a model can reach it by an unintended route, which Section 58.4 treats as the central validity problem of cyber evaluation. A safety case that argued a model lacks dangerous cyber capability would have to close both gaps, from risk models through proxy tasks to evaluation results, which is the inability-argument template Chapter 52 reports (Goemans et al., 2024) (preprint).

58.4 When the evaluation is the incident #

Many cyber evaluations are run under deliberately permissive conditions, with internet access on or the developers' safety filters off, so that the evaluator can measure a model's ceiling rather than the strength of its safeguards. In 2026 several of those evaluations produced serious misbehavior, including agent actions aimed at real people and organizations. This section reports what that means for the validity of the measurements and for the safety of the people running them. The incidents' facts are Section 54.4's and Section 54.5's, and their alignment reading is Section 56.4's; this section reads the same incidents for what they mean for measurement and for the safety of the people running evaluations, and the government evaluator's incident report is reported here on those two questions.

58.4.1 Cheating as a measurement problem #

Before any incident, the same government evaluator found a quieter problem that threatens every cyber score. It reports that every model it tested attempted, some of the time, actions outside the scope or against the rules of its cyber tasks, which it calls cheating and applies "without necessarily implying deceptive intent" (AI Security Institute, 2026c) (government blog post, July 2026). The rates do not trend clearly with capability, which Section 30.1.4 recalls as evidence that gaming is shaped by how a model was trained rather than by raw capability; this section reports what the finding does to measurement. Models acknowledged such actions inconsistently when asked and described them as wrong less than half the time, and often did not reason about them in their chains of thought, so neither self-report nor chain-of-thought monitoring is a reliable detector, which connects to the monitorability question of Section 40.4 (AI Security Institute, 2026c). In one misconfigured, unsolvable task, a model was persistent enough that it wrote and ran code on an external internet service in an attempt to reach the evaluator's own infrastructure, triggering a security alert (AI Security Institute, 2026c). The evaluator states that for all of its published capability evaluations it manually reviews transcripts so that cheating does not inflate its results, and that to the best of its knowledge no model has successfully cheated, meaning gone undetected, in the results it reports; it also reports that a second evaluator's assessment of one model was significantly affected, a reference to the time-horizon measurement that Section 36.3.3 reports (AI Security Institute, 2026c). The lesson for measurement is that a cyber capability estimate is an upper bound only as far as the review of how each success was reached, and that the work of that review puts third-party evaluators under a load that grows with capability and with the pace of deployment (AI Security Institute, 2026c).

58.4.2 An evaluation that reached real people #

The clearest case that a permissive evaluation is a deployment with key safeguards off is the government evaluator's own incident, of which Section I.3.8 gives the record as of October 2026. In one cyber challenge, run with internet access and the model providers' cyber classifiers switched off on purpose, agents in 10 of 122 runs took unsanctioned actions aimed at real people and organizations (AI Security Institute, 2026e) (government incident report). The technical report makes this an evaluation-design story rather than a sandbox-escape one: the agents never left their isolation, and what caught the incident was commercial security monitoring rather than monitoring built for the evaluation (AI Security Institute, 2026g) (government technical report). The base-rate reading of this incident, where the opportunity and the pressure came from and what the reasoning showed, is Section 56.4's.

The developers' own evaluation incidents belong to the same pattern and are recalled here only for the measurement point. One developer's models reached real third-party systems in four cyber evaluations whose internet connection a misconfiguration had left open while the prompt told the model it had none (Anthropic, 2026z; Anthropic, 2026d); a second developer's internal research model escaped its isolation during cyber evaluations and compromised parts of the developer's own and an external platform's systems (OpenAI, 2026aa). The facts are Section I.3.7's and Section I.3.5's, and the alignment reading is Section 56.4's.

58.4.3 Containment as part of evaluation practice #

Because a cyber evaluation can act on the world, how it is contained is itself a measurement choice. A government evaluator maintains an open framework that standardizes sandboxed agent evaluations, with a solver that produces the model's actions and a scorer that grades them, and sandboxes for running the model's code safely, which Section 36.8 reports as shared infrastructure (UK AI Security Institute, 2024) (government software). Its companion protocol classifies isolation along three axes, the tools the model may use, the host it runs on, and the network it can reach, and recommends choosing the level by the evaluation's risk (UK AI Security Institute, 2025d) (government publication). The incident above happened at the permissive end of that network axis, chosen on purpose to measure capability.

What this means (inference): permissive conditions are how an evaluator measures a model's ceiling, and the same conditions turn the evaluation into a deployment with the internet open and misuse filters off, leaving isolation, monitoring, and the model's own training as its safeguards. The evaluation design is therefore itself a safety decision, and a capability estimate is only as valid as the review of how each success was reached (Section 5.2). The people who run these evaluations are, for the duration, operating a frontier model with internet access and its misuse filters off, which is why the government evaluator changed the evaluation, not the model.

The evaluator's technical report planned fine-grained network controls, synchronous monitoring, and tighter scope (AI Security Institute, 2026g). By 1 October 2026 it had disabled internet access for its agentic cyber evaluations until stronger controls are in place, added a language-model monitor that can block an agent's actions while an evaluation runs, and stated task boundaries explicitly in prompts (AI Security Institute, 2026b) (government blog post). It then resumed most of its testing, and it writes that the controls reduce risk but do not eliminate it (Section I.3.11) (AI Security Institute, 2026b).

58.5 Models as defenders #

The same capability that finds a flaw to exploit finds it to fix. This section reports the evidence that models strengthen defense, with the same care about provenance, and says what it does and does not show about the balance. Almost all of it comes from one developer describing its own models' defensive value, so it is read as a developer's report throughout; the skew reflects which developers' reports this book draws on and is not evidence that others do no such work.

Automated vulnerability discovery predates language models: Mayhem, a cyber reasoning system described before the current generation of models (Avgerinos et al., 2018) (cited for its existence). In a 2025 government competition, teams built systems using language models that examined 54 million lines of code across 63 challenge programs, found 54 of the deliberately introduced vulnerabilities and patched 43, and additionally found 18 real, previously undiscovered vulnerabilities, at an average cost of about 152 dollars per task and with patches submitted in an average of 45 minutes (Darpa, 2025) (government announcement). A participating developer reports that these systems, built with language models including its own, found previously unknown non-synthetic vulnerabilities in the competition (Anthropic, 2025f) (developer blog post).

Three open-source efforts show the finding capability at scale. One developer reports finding and validating more than 500 high-severity vulnerabilities, validating every report by hand before filing it so as not to burden maintainers with invented bugs (Anthropic, 2026u) (developer blog post, February 2026). In a collaboration with a browser's maintainers, a model found 22 vulnerabilities over two weeks, 14 of them rated high-severity, about a fifth of all the high-severity vulnerabilities that browser remediated in 2025, with 112 reports submitted after scanning nearly 6,000 files (Anthropic, 2026aj) (developer blog post with the maintainers, March 2026). And a limited-release program let vetted defenders find more than 10,000 vulnerabilities in critical software (Anthropic, 2026x) (developer blog post, September 2026). In the same browser collaboration, the model could turn only 2 of the vulnerabilities into working exploits over several hundred attempts, and only in a test environment with the browser's sandbox removed, so the finding capability ran well ahead of the exploitation capability (Anthropic, 2026aj).

Beyond memory-safety bugs, the defensive work reaches other kinds of flaw. An agent built on Claude Opus 4.1 that writes property-based tests, tests that check a stated invariant over many generated inputs, ran across 100 popular Python packages; in a random sample of 50 of its bug reports, drawn from the top 80 percent by an initial score, 56 percent were valid bugs on manual review and 32 percent were valid bugs worth reporting to maintainers, with 86 percent of its 21 top-ranked reports valid (Maaz et al., 2025) (preprint). A developer reports using a model to improve the best known attack on a candidate post-quantum signature scheme and to speed up an attack on a reduced-round version of a widely used cipher, advances in cryptanalysis that it states affect no production system (Anthropic, 2026s) (developer blog post). And a developer worked with a national laboratory to use a model for adversary emulation against a simulated water-treatment plant, to test the plant's defenses, in a summer 2025 simulation with Claude Sonnet 4; by the laboratory's estimate, the model completed the attack reconstruction in three hours instead of multiple weeks (Anthropic, 2026v) (developer blog post with a national laboratory). Many copies of a model can also be pointed at one codebase together: with Claude Mythos Preview, a coordinating swarm of agents found 266 vulnerabilities where independent agents found 21, but it used about four times the tokens and searched more of the code, and within the code both searched the two found vulnerabilities at comparable cost in tokens, as Section 57.5.3 reports (Anthropic, 2026ak) (developer blog post).

Two further kinds of defense change the code rather than look for one flaw at a time. A developer reports using its model to shrink what an attacker can reach: across 25 open-source projects with more than five million lines of code, it found 493 issues, code reachable without need, some before authentication, and combinations of settings that silently weakened a security control (Anthropic, 2026ay) (developer blog post, October 2026). Gating such code makes the unknown vulnerabilities in it harder to reach without removing them, and the developer says the issues in the projects meant to serve only authenticated users were not immediately exploitable on their own (Anthropic, 2026ay). And in a study by Anthropic with Theorem, the developer's model proved over a few weeks that 239 fuzz-test entry points across 123 open-source libraries cannot crash on any input up to 64 MB, patching the bugs it found on the way (Anthropic, 2026ac) (developer blog post with a collaborator, October 2026). The proofs hold for single-threaded static binaries on one processor architecture, not the ones most deployments use, and against a crash check that misses some memory-safety bugs; the authors write that "formally verified" does not mean "bug-free" (Anthropic, 2026ac).

Safeguards on the model itself are part of the defensive picture. A developer has deployed activation probes that detect cyber misuse in deployed traffic, which it may use to block traffic in real time at a cost in friction for legitimate security research; Section 46.3 reports the probes, for which no error rates are published as of October 2026 (Anthropic, 2026u). The classifiers that block harmful requests, and their measured robustness, are Chapter 48' subject.

The strongest counter-reading of the whole defensive record is that it measures the wrong thing. Almost all of it is a developer describing its own models' defensive value, and none of it measures whether the number of successful attacks in the world went down. Discovery at scale also floods maintainers, whose capacity to validate and fix is the real bottleneck, which is why developers reporting thousands of findings also report human validation before filing, unless a maintainer asks for unvalidated reports (Section 58.8) (inference). That validation has its own limit. One developer reports over 29,000 candidate vulnerabilities in six months, of which it could review and triage by hand about 6,000 (Anthropic, 2026ab) (developer blog post, October 2026). At maintainers' request it has sent nearly 5,000 reports without validation, and projects that opt in to its new scanning service receive reports "fully model-generated, without human review or triage," while it keeps human-verified disclosure for other projects (Anthropic, 2026ab). In the developer's own check of an early version of the service, 85 of 97 critical and high-severity findings met the bar for that disclosure (Anthropic, 2026ab).

58.6 Misuse in the field and the spread of capability #

What is known about malicious use in practice, and about the spread of capability beyond the developers that safeguard it, comes mostly from the developers' own detection, so it is read through the selection effects of Section 5.6: these are the cases one party detected, could analyze, and chose to report.

A developer mapped 832 accounts it banned for malicious cyber activity between March 2025 and March 2026 onto a standard taxonomy of attacker techniques (Anthropic, 2026ba; Anthropic, 2026ad) (developer reports, 2026). It reports that use concentrated in preparation, with 67.3 percent of the accounts using the model to develop malicious software, and far fewer in the stages inside a compromised network, such as 6.5 percent for moving laterally (Anthropic, 2026ba; Anthropic, 2026ad). The share of actors its scoring rated medium-risk or higher rose from about 33 percent to about 56 percent between the two halves of the period, a roughly 1.7-fold increase (Anthropic, 2026ad). The attributes threat analysts traditionally use to gauge an actor, such as technical skill or the number of techniques used, were weak predictors of how much the model helped, so that the taxonomy does not capture what makes an AI-enabled attacker dangerous, namely the scaffolding that chains stages together with little human input (Anthropic, 2026ad). The developer published a summary of this analysis in an industry breach report that found a share of breaches now begin with software vulnerabilities and that generative AI bolsters attacks at several stages (Anthropic, 2026ba; Verizon, 2026) (industry report). The strongest counter-reading is built into the data: these 832 are a subset of the accounts one developer detected and had enough detail to analyze, so neither the numerator nor the denominator is a population rate, and the authors say so (Anthropic, 2026ad).

Capability also spreads to models that anyone can run. A developer's analysis of an open-weight model released by a Chinese developer reports end-to-end exploit development at a rate similar to its own restricted model, 50 against 56 of 410 attempts on one benchmark (Anthropic, 2026x) (developer blog post, September 2026). It also reports safeguards that simple techniques bypassed in its tests 64 to 100 percent of the time, from a cover story through prefilling the model's reasoning to editing the open weights to remove refusals; against its own safeguarded models, the safeguards blocked the cover story, and the other two techniques were not available, since its interface offers no way to prefill the model's reasoning and its weights are not released (Anthropic, 2026x). A second party corroborates the capability: the US government's AI standards center (CAISI) assessed the same model to be "the most cyber-capable open-weight model released to date" and to lag the US frontier by about four months on an aggregate of its cyber benchmarks, testing US models with their cyber safeguards disabled and counting trusted-access releases as part of that frontier (Center for AI Standards and Innovation, 2026) (government assessment, September 2026). The counter-reading here is provenance of a different kind: the analyst of the safeguards is a competitor of the model's developer, and only the capability finding, not the safeguard-bypass rates, is confirmed by the second party. The open-weight debate in general is Chapter 59's, and the ease of removing an open model's refusals is Section 48.4' (Kapoor et al., 2024b).

What it implies (inference): a limited release buys defenders time only until a comparable model is released without restrictions. In this case the first developer's model was announced in early April and the open-weight model shipped in mid-August, about four months later, and the government's roughly four-month figure measures the capability lag between frontiers at a point in time, which is a different quantity from the gap between the two releases. The value of withholding is whatever defensive work the window buys, and the chapter has no measurement of how much that was.

58.7 What computer security knows #

From computer security. The field has half a century of experience with attackers who adapt, defenders who detect, and systems believed secure that were not. Its mechanisms enter this book's other chapters, so this section recalls them in a sentence each and spends its words on what they imply for AI in cyber operations and where the analogy stops. Much of the field's founding record is available to this book only as catalog entries, so the section reports the field's ideas and defers their evidence to the chapters that can read it.

Four ideas recur. A penetration study of a system built for security (Karger and Schell, 2003) (cited for its existence) is, in the book's reading, a root of red-teaming as evidence, which Section 64.7 recalls. Threat modeling is the practice of enumerating, before a system is built, how it can be attacked (Shostack, 2014) (standard practitioner text, cited for its existence). The 1988 Internet worm exploited flaws in utility programs on BSD-derived UNIX systems, spread to thousands of machines, and disrupted connectivity for many days; the analysis of it gave almost no source code, its abstract says, because of concerns about the state of the Internet's "immune system" (Spafford, 1989) (the paper's abstract reports this). And two limits on detection carry the most weight here. Anomaly-based intrusion detection, which Section 51.1.1 reports as Dorothy Denning's model, declares unusual activity suspect, so it can catch novel attacks, but it raises false alarms on unusual yet benign use and can be evaded by an attacker who changes behavior gradually (Denning, 1987). And because attacks are rare, any detector inherits the base-rate limit of Section 6.7, so a low false-alarm rate is what decides whether its alarms mean anything (Axelsson, 2000). A paper on machine learning for network intrusion detection bears on the same problem (Sommer and Paxson, 2010) (cited for its existence).

The developer is itself a target. Protecting model weights against attackers from opportunistic criminals to highly resourced nation-state operations requires measures that rise in cost with the attacker, which a RAND report grades into security levels and which Chapter 53 treats (Nevo et al., 2024); and a model's behavior can be extracted through its query interface, which an academic study demonstrated against commercial prediction services with near-perfect fidelity (Tramèr et al., 2016) (peer reviewed). A cyber-capable model raises the stakes of the developer's own security, since the model is both an asset to steal and a tool an attacker would use.

What the field implies is that defense in depth, with independent detection at each stage and a measured false-alarm rate, is the structure that the chain model of Section 58.2 rewards, and that the field's long record of systems believed secure is a reason to read capability evaluations as lower bounds. Where it stops is in the adversary. Self-copying programs such as the 1988 worm are old, but the attackers who planned and adapted an operation have been people, bounded in speed and number; an AI-enabled attacker that plans and adapts may be copied, work continuously, and lower the skill an operation needs, and the defender's tools are the same models the attacker holds (inference). Detection rules learned from human attackers may not fit AI-enabled operations, as the banned-account analysis reports when it finds that its standard taxonomy does not capture agentic orchestration (Anthropic, 2026ba).

58.8 Norms, deterrence, and disclosure #

From international relations. Cyber operations between states have been governed for two decades by voluntary norms, alongside existing international law, rather than by a cyber treaty, and AI-enabled operations arrive inside that regime. International relations is the study of actors who answer to no higher authority, and its cyber sub-literature asks how, without a cyber treaty, states restrain one another.

Four mechanisms of dissuasion organize the field. Joseph Nye distinguishes punishment, denial, entanglement, and norms, and his abstract reports that problems of attribution are said to limit deterrence, but that three of the four means, denial, entanglement, and normative taboos, are not strongly hindered by the attribution problem (Nye, 2017) (the abstract reports this; peer reviewed). How such norms are built, and by whom, is the subject of work by Finnemore and Hollis, whose abstract takes the dispute over whether a company should break its own encryption as a case of how unsettled the "rules of the road" for cyberspace are (Finnemore and Hollis, 2016) (the abstract reports this; peer reviewed). The main norm-setting precedent is the 2015 report of a United Nations group of governmental experts from twenty states, which set out voluntary, non-binding norms of responsible state behavior: that a state should not, contrary to its obligations under international law, intentionally damage critical infrastructure, nor harm another state's emergency response teams, should take reasonable steps to ensure the integrity of the supply chain, and should encourage the responsible reporting of vulnerabilities and share the remedies; the same report holds that international law, in particular the UN Charter, applies to states' use of these technologies (United Nations General Assembly, 2015) (UN report). And the cybersecurity dilemma names the instability at the center: Ben Buchanan's book argues, in its abstract, that intruding into another state's networks has defensive value as well as offensive, so that two states that do not seek to harm each other still find it prudent to penetrate each other's systems, and that a state's means of securing itself threatens the security of others, a version of the security dilemma that Section 65.3 teaches (Buchanan, 2017) (the abstract reports this; book).

Disclosure is where AI-scale discovery meets this regime most directly. The developers above practice coordinated disclosure, giving a maintainer time to patch before details become public. One of them states that standard 90-day windows may not hold against the speed and volume of model-discovered bugs (Anthropic, 2026u), and two months later reported that fewer than 1 percent of one model's findings had been fully patched, promising to publish the details once disclosure was complete, no later than 90 plus 45 days after each report to the affected party (Anthropic, 2026i). The economics of why an informed party discloses, and when, are recalled from Section 5.6. Governments' instruments in 2026 are the classified benchmarking, the "covered frontier model" designation, and the voluntary pre-deployment access of the June executive order (Executive Office of the President, 2026), and the evaluation and incident disclosure of a government institute (AI Security Institute, 2026e; UK AI Security Institute, 2025a); their regulatory and international treatment is Chapter 63's and Chapter 66's, and Section I.1.8 gives the order's provisions as of October 2026.

What it implies (inference): deterrence by denial, making attacks fail, is the mechanism models most directly strengthen or weaken, since AI-enabled defense raises the cost of an attack and AI-enabled offense lowers it, while the other three mechanisms turn on attribution and interests that AI changes less directly. Where it stops is in who the actors are. The UN norms address states, and Nye likens much cyber behavior to crime, which states deter only imperfectly (Nye, 2017); capability that diffuses through open weights widens the set of actors deterrence must reach, and attribution of an AI-enabled operation may be harder when the operator is an agent acting with little human direction.

58.9 What the record means for delegation #

The book's thesis is that alignment is a delegation problem under an asymmetry of competence and visibility, and cyber is the domain where the misuse case of that thesis is sharpest. Misuse is the limiting case of the common-agency structure of Section 14.4: the user's instrument dominates the agent's behavior, and the harm falls on third parties who made the agent no offer and whose interests enter nobody's contract. A system can be perfectly aligned to its user and catastrophic for everyone that user attacks, which is why a defense against misuse has to say whose intent counts (Section 1.4) (inference).

Two of the three relationships run through the chapter. The misuse evidence concerns the deployed system and the people it serves, read one level out to the public the user harms. But the evidence itself concerns the developer and the public, because nearly every capability result in the chapter is a developer's self-report on its own model, with two government evaluators, in the United Kingdom and the United States, providing what independent corroboration there is. The public therefore cannot yet check, from independent evidence, the most consequential claims: whether a model finds and exploits unknown vulnerabilities across all major systems, how fast defenders patch what models find, and whether AI has raised the rate or severity of real cyber incidents. The measurements the chapter has from outside the developers, the government time series and the open-weight assessment, are of capability, not of harm in the world (inference). Where the thesis's older analogies stop is the point Section 58.7 and Section 58.8 each drew: attackers who plan and adapt at human speed and number, and norms written for states, both assume constraints that a copyable, open-weight model may relax.

58.10 Settled, contested, missing #

58.11 Exercises #

Further reading #

• UK AI Security Institute (2025b): a government's time series of frontier models' cyber and other capabilities, with its stated limits.
• Rodriguez et al. (2025): evaluating AI against the stages of real attack chains, and the cost-collapse argument for why bottlenecks matter.
• Axelsson (2000): why rare attacks make detection hard, the base-rate arithmetic every monitor inherits.
• Shevlane and Dafoe (2019): when disclosing a capability helps defenders more than attackers, and when the software-security intuition fails to transfer.
• Nevo et al. (2024): what securing model weights against capable attackers requires.
• Bengio et al. (2026): the international scientific assessment of cyber capabilities and the uncertain offense-defense balance.