The breachpocalypse is here

Seven incidents in seven days

Last week I sent our leadership team a list. In seven days, Sophos' internal SecOps team responded to seven incidents: abuse of one of our products via a trial account, the ConnectWise Cloud Backup compromise, PHP2Shell, the eMudhra weak SubCAs, the second supply-chain compromise of LiteLLM this year, critical Node.js vulnerabilities and a GitLab RCE. A year ago, that would have been a quarter's worth.

We avoided major impact, but only through a concerted effort and some very long hours. Admittedly this is a sample size of one, but from my position protecting a leading cybersecurity vendor, the trend seems pretty clear.

"So where is the impact?"

The counter-argument is that the damage isn't showing up. PHP2Shell has not, so far, become the mass-exploitation event many of us braced for. There has been no "Challenger disaster", Simon Willison's phrase for the headline event that ends our normalisation of deviance. Tal Be'ery found that material-incident filings to the SEC rose only mildly in Q2 and Q3 2026, while high and critical CVEs rose several-fold.

I take that seriously. But we have always been bad at measuring a rising tide until well after it has risen. In 2012, the late Ross Anderson and colleagues counted over 100 sources of cybercrime data, all "insufficient and fragmented." Microsoft researchers showed that one survey respondent claiming $50,000 in losses could produce a $10 billion national estimate. Only in 2019 could Anderson's team confirm what they had guessed in 2012: cybercrime was about half of all crime. Dan Geer noted that 70–80% of breaches are found by third parties, so many victims may never know.

Public health offers a close parallel. Between 1999 and 2017, the US drug overdose death rate more than tripled, reaching 70,237 deaths a year. The toll built up from thousands of individual deaths, each logged by a local coroner, with no single disaster to mark it. The US did not declare a public health emergency until October 2017, and even then the count was off: opioid deaths were undercounted by 20–35% because death certificates often omitted the drug. A plane crash is counted by nightfall. A rising tide of small incidents is counted years later, and badly. Cyber's recent damage has come the same way: a growing stream of smaller incidents, with no mega-incident to count.

There's also some hard-earned mitigation to account for. Vendors, maintainers and security teams have patched at a pace I have never seen; Mozilla alone fixed 271 Firefox bugs from one AI-assisted effort and Sophos' own engineering team have been flat-out on the bugs emerging from our own Glasswing and Daybreak participation. But that doesn't hold below the security poverty line: the organisations lacking the money, expertise, and capability to protect themselves. They don't file 8-Ks or hold IR retainers. The most exposed cohort is also the one we measure worst.

The signals we do have

Operational signals arrive well before formal measurement. On 19 October, former NSA cybersecurity director Rob Joyce wrote that "IR firms are saturated & turning away work." That matches what we see: our own IR function has never been busier and is forecasting an industry-wide capacity crunch.

Similarly, Google Threat Intelligence reported 141 vulnerabilities exploited from January to August 2026, against 127 in all of 2025, and Anthropic research shows that the autonomous attack pattern it documented in 2025 "has now proliferated across every class of actors we investigated."

There is also a reporting asymmetry. Finding vulnerabilities is loud: researchers and AI labs publish counts, such as Project Glasswing's 10,000+ high or critical findings in a month. Incidents are quiet. In Bitdefender's 2026 survey, 55% of professionals who had suffered a breach were told to keep it confidential when they believed it should be reported. People brag about finding bugs. Nobody brags about being breached.

The frontier is jagged for attackers too

AI capability is a jagged frontier: strong at some tasks, surprisingly weak at neighbouring ones. Defenders haven't fully scaled their use of it, and neither have adversaries. RUSI's Will Lyne and Jamie MacColl argue that AI "is not (yet) fundamentally reinventing cybercrime", because criminals change business models only when profits force them to. Be'ery makes a similar case: monetisation and laundering, not vulnerabilities, are the bottleneck.

Both are plausible. A less comfortable view is that the binding constraint is the number of capable criminals, and AI is precisely a way to scale people.

Sophos X-Ops research shows we are at the early-adopter stage. When monitoring underground forums we found a clear knowledge gap: criminals buying brokered API keys and asking each other for basic setup help. A year of our MDR casework found that where attackers used AI, it was "as an assistant with a human in control." Observed adoption trails available capability. That gap describes the start of a curve, and the capability will already be in place when someone finds the business model.

What to do about it

Start with the board. The most useful thing a security leader can win now is agreement to accept some risk elsewhere: legal, regulatory, contractual or financial. That means tolerating some disruption, such as a service switched off or a patch pushed before full testing, to avoid a much larger incident. Mainstream coverage of AI threats is often alarmist and sometimes inaccurate, but it has made boards and CEOs more receptive than usual. Use that attention to secure a mandate; without one, the steps below stall.

1. Shrink the surface. Remove nice-to-have internet-facing services. Put the rest behind a VPN, ZTNA, or an authenticating proxy, so an unauthenticated exploit can't reach them. Treat identity as attack surface too; phishing-resistant authentication is the equivalent for accounts (see our passkey playbook).
2. Take humans out of the patching loop. Our AI Security 2026 report found the window from disclosure to exploitation shrinking to hours: Ivanti Sentry (CVE-2026-10520) was exploited within 24 hours of a public proof of concept, and LiteLLM (CVE-2026-42208) within 36. CISA has cut mandatory patching for the highest-risk flaws to three days for federal agencies. Even in the most uptime-sensitive environments, a bad vendor patch is usually the smaller risk. It rolls back in hours; recovery from an incident takes weeks. Turn on automatic updates wherever vendors offer them, and use agents to test and stage the rest.
3. Eyes on alerts. Autonomous attacks are, so far, noisy and slow against reasonably hardened targets. Microsoft saw one AI-driven campaign peak at 2,900 failed sign-ins a minute. Reuters reported that one hacker using AI agents against more than 1,200 websites typically needed about 23 hours per successful intrusion. This is an opportunity for organisations that have a real response capability. For those that don't, MDR is the quickest way to get there.
4. Use AI yourself. This matters most. A security team without frontier AI and a decent budget for tokens is fighting with one hand tied behind its back.

   1. If you do manage to secure some funding, remember you can scale your existing staff with a clear mandate and generous token allowance far faster than you can hire.

   2. Give your agents a chance. We've all seen new-starters spend their first few weeks or even months bogged down in access requests, trying to get the tools necessary to do their job. Agents are no different. This is the hard part culturally, and it is a real risk trade-off. But ask whether largely theoretical risks are outweighing a clear and present danger. The rogue-AI stories in the media matter, yet they mostly come from labs testing long-horizon autonomy at a scale and budget few organisations will match. Joshua Saxe found documented prompt-injection losses to be tiny next to overall cyber losses. Contain agents with sensible boundaries but don't starve them of access.

   3. Give the sceptics an opportunity. Many security professionals are not natural early adopters and thus formed their opinions based on their experience of an entry-level enterprise assistant or a consumer chatbot. Give them the right tools, space to play, and a mandate to accept some risk, then reassess.

Where to start

Sometimes the hardest part is getting started. Here are a few ideas we've had success with:

• Endpoint gaps. Give an agent your asset inventory sources, org chart and endpoint management console. Ask it to find unprotected or misconfigured devices, including stale exceptions, ranked by risk.
• Perimeter exposure. Merge the same asset data with your vulnerability scan results and give it its own fresh AWS account with a remit to find risky perimeter services, spinning up EC2 instances as needed to probe, validate and prioritise findings.
• Stalled fixes. Point an agent at your source control, ticketing, documentation, existing product security tooling, org chart, inbox and chat. Ask it to surface unaddressed issues by team, with a timeline of previous communications.
• Risk register drift. Have an agent review your inbox, chats and recent meeting recordings, and highlight any risks discussed that don't clearly map to your board-level risk register.

Writing about OpenClaw in February, I said: "As with all technology adoption, pragmatic risk management is key. And, luckily, we've all been doing that for a long time." That holds here too. There is no free lunch: every step above trades one risk for another, whether a broken patch, an unhappy customer or an agent with more access than feels comfortable. Risk management is easy when the data is clear. Good leadership requires acting on judgement while the evidence is still incomplete. By the time the breachpocalypse is easy to measure, it will be too late to prepare for it.