For decades, software security has relied on two quiet assumptions. Finding and weaponizing a vulnerability took rare skill, and defenders had time to triage and patch what turned up.
A new McKinsey & Company report argues that frontier AI has broken both.
In "How frontier AI is rewriting software security rules," published this month by McKinsey's Risk & Resilience Practice and Tech & AI group, the authors make a blunt case: the bottleneck in software security has moved. AI has made discovery cheap and fast. Remediation is still slow, expensive, and human-bound. And attackers are exploiting that gap faster than most enterprises can patch.
The report opens with numbers that show how quickly the ground has shifted.
After Anthropic launched Project Glasswing in April 2026, it reported in May that partners had found more than 10,000 high- or critical-severity vulnerabilities using Claude Mythos Preview. Several partners said their bug-finding rate rose more than tenfold. Among the finds were a 20-year-old Firefox bug disclosed by Mozilla and a 27-year-old OpenBSD flaw.
The effect is spilling into the wider ecosystem:
Linux kernel: According to figures shared by a kernel maintainer, CVEs fixed per release jumped from roughly 500 across versions 6.9–6.19 to more than 1,000 starting with version 7.0.
Bug bounties: HackerOne reported in April that vulnerability submissions rose 76% year over year, and the share of valid findings held steady. The extra volume isn't just noise.
Adversaries: CrowdStrike's 2026 Global Threat Report found an 89% year-over-year increase in attacks by AI-enabled adversaries in 2025.
October's PHP2Shell and Node2Shell disclosures show what this looks like in practice: widely deployed platforms, remote code execution, and exploitation attempts observed in the wild. McKinsey's authors point to the PHP flaw as evidence that the hard part is no longer finding vulnerabilities; it's fixing them and making sure the same class of flaw doesn't come back.
The speed asymmetry is stark. McKinsey cites research showing that the average window between disclosure of a critical vulnerability and active exploitation has shrunk to a matter of hours, down from a few weeks just a year earlier. Rapid7 data indicate about two-thirds of exploited vulnerabilities are now hit on or before disclosure day.
Meanwhile, defenders are getting slower. Verizon's 2026 Data Breach Investigations Report found that the median time to fully remediate CISA-listed known exploited vulnerabilities rose from 32 days to 43 days, and only 26% were fully remediated.
The report captures the practical form of this gap well: a weekend advisory for a widely-deployed edge or remote-access product, with incomplete vendor guidance. In the hours that matter, the most realistic move is often to switch the exposed service off and live with the operational consequences.
The cost picture is just as lopsided. For an attacker, pointing a model at a codebase is cheap. For a defender, thorough multimodel scanning costs more. Remediation costs more still.
Early-adopting enterprises told McKinsey that the first scan of their crown-jewel systems wrapped up in days to weeks. The remediation behind it may take months.
Money is only part of the bill. Every engineering squad assigned to clear vulnerabilities is a squad not shipping product. Left unmanaged, the authors warn, the backlog saturates security teams, engineering teams, and the open-source maintainers that enterprises quietly depend on.
The policy response is already underway, particularly in financial services.
In April 2026, U.S. Treasury Secretary Scott Bessent and then-Federal Reserve Chair Jerome Powell convened major bank leaders to discuss the cyber implications of Anthropic's Mythos model.
On July 7, the European Central Bank's Banking Supervision arm asked significant institutions to submit action plans by October 31 covering faster patch management, AI-enabled defenses, and stronger supplier and exposed-asset safeguards. The letter places responsibility squarely on management bodies and signals that ICT investment and risk tolerance frameworks may need revisiting.
The Bank of England, FCA, HM Treasury, and CERT-EU have also issued guidance on frontier-AI-enabled cyber risk.
The report's central argument is that speed alone won't close the gap. Neither will hiring a large permanent team to chase every finding, which simply drags product development into the backlog. Instead, McKinsey calls for an integrated program across four levers, each dependent on the others.
1. Cyber practices: Make discovery AI-native and smarter
The goal is to spend scarce human effort only on flaws that are real and relevant. Different models and traditional scanners find largely different sets of bugs, so high performers run several in parallel, saving the most capable models for the most critical code. They consolidate findings from code, cloud configuration, third-party components, and leaked secrets into one record, because moderate issues in separate queues can combine into a critical one. They enrich findings with context: is the flaw reachable, internet-facing, near critical data? And they don't pull in an engineer without reproducible proof, unless there are signs of active exploitation. Over time, one-off scans give way to AI-assisted testing embedded in the delivery pipeline.
2. Operating model: Build security into the engineering system
Fixing a flaw once isn't enough. The aim is to change the shared engineering platform so the same failure can't recur elsewhere. That means secure defaults enforced by frameworks, approved dependency registries, and memory-safe languages for new system-level code. Notably, the report treats coding agents as privileged users: short-lived credentials scoped to a task branch, no ability to alter the approved dependency list, and no access to production systems, data, or secrets. Because agents read untrusted text that may carry injected instructions, the authors stress that access limits must be enforced outside the model itself. They also caution against relying on a second AI model as the reviewer, recommending one from a different provider and testing it against human judgment.
3. Risk and control framework: From paperwork to a North Star
Qualitative risk appetite statements can't settle arguments about what to fix first. McKinsey recommends converting them into exposure tolerances by asset tier: days for an internet-facing tier-one system, a quarter for an internal tool with no path to critical data. Severity labels alone won't scale once volumes rise tenfold, so ratings should combine proof of exploitability, reachability, in-the-wild activity, and asset tier. Risk acceptances need a compensating control, a named owner, and an expiry date. The board should see three numbers each quarter: exposure window, critical-system backlog, and supplier patch speed. AI agents get their own class in the control framework, with distinct identities, accountable owners, and outcomes verified by deterministic tests rather than another model.
4. Technology: Assume breach and contain the blast radius
When vulnerabilities are continuous rather than occasional, the realistic goal is limiting how far an unpatched flaw can reach. That starts with rigorously enforced trust boundaries around crown jewels, build environments, identity infrastructure, and critical third parties, followed by finer segmentation where needed. The basics matter more as patch windows shrink: MFA, least privilege, immutable backups, tested recovery. The authors also make a point security leaders should take to their CFOs: retiring systems is often the cheapest remediation available. Less code means less to scan and fix.
Recognizing that programs like this often stall, McKinsey lays out a phased launch built around a deliberately narrow scope: a defined set of critical systems and a single delivery path.
Days 1–30 focus on foundations: assigning owners, running the first multimodel scan, publishing a ranked view of proven and reachable findings, setting exposure tolerances and emergency authority, and verifying that high-severity alerts reach someone who can act within minutes.
Days 31–60 shift to execution: putting the engineering pilot into use, routing routine fixes through normal delivery, and confronting the constraints that surface, such as missing regression tests, unclear ownership, and slow suppliers.
Days 61–90 are about evidence: demonstrating containment and remediation times, recurring defect rates, and engineering capacity consumed, then deciding what to expand.
A 12-month board checklist closes the loop, asking whether exposure is within tolerance, whether ownership is working in practice, and which legacy systems and suppliers remain unresolved.
What stands out in McKinsey's framing is how little of it is about AI tooling and how much is about organizational design. The discovery problem is largely solved, sometimes uncomfortably so. What remains is a capacity problem, a prioritization problem, and an accountability problem.
That framing should resonate with CISOs who have spent years arguing that vulnerability management isn't a scanning exercise. The new wrinkle is volume. Policies like "fix every critical within 30 days" were built for a world with far fewer findings. In a world with 10 times as many, those policies don't just fall short; they become impossible to meet, which means they stop guiding decisions at all.
The organizations that come out ahead, the report suggests, will be the ones that decide in advance what exposure they can tolerate, who can shut a service down, and which systems aren't worth saving. That isn't a technology decision but a leadership one.