Software's Security Exemption Is Expiring

Thirty Targets, Zero Detections

In September 2025, roughly thirty organisations were targeted in a coordinated campaign: large technology companies, financial institutions, chemical manufacturers, government agencies. Anthropic later attributed it with high confidence to a state-sponsored group.

The notable part isn't the target list. It's the division of labour. The AI performed 80 to 90 percent of the campaign, with humans intervening at perhaps four to six decision points. It inspected target infrastructure, identified the highest-value databases, researched and wrote its own exploit code, harvested credentials, and extracted data. It ran thousands of requests, often several per second.

None of the thirty found it. Anthropic did, from the model side.

If the operator had used an unmonitored model, none of us would know it happened — including the targets. That is worth sitting with, because it means the absence of detections is not evidence of the absence of attackers. It is evidence about the detection apparatus.

That report is contested, and it should be. Anthropic published no indicators of compromise, which is the evidence other defenders would need to look for the same activity. Several researchers questioned whether the operation was genuinely autonomous or heavily automated with a human driving, and noted that a frontier lab has a commercial interest in AI capability appearing significant. An earlier report from the same company drew similar criticism. So treat the 80-to-90-percent figure as the vendor's characterisation rather than an established fact.

The structural argument below does not depend on that number, and I would rather make it without leaning on a disputed one.

The Bet Nobody States Out Loud

Most security programs run on a schedule. Threat model at design time. Penetration test twice a year. Bug bounty running continuously but driven by whatever researchers find profitable. Compliance audit annually.

Every one of these is point-in-time, and stacking them is a reasonable strategy. But the stack only works because of an assumption that is almost never said aloud:

The time it takes an attacker to find and exploit something is longer than the time until your next review.

On 27 August 2026, more than a hundred companies signed an open letter on collective cyberdefense whose first principle is "Recognize that status quo security won't be enough." Google, Microsoft, OpenAI, Anthropic and AWS are among the signatories, alongside most of the security industry that sells the status quo.

Their diagnosis is backlog and under-resourcing: longstanding bugs, excessive permissions, unpatched software, technical debt in legacy systems, and security teams that have been starved of people and tools. All of that is true, and all of it describes a catch-up problem, the kind that a surge of resources closes.

This argues something narrower and less comfortable. The periodic-review model is mis-calibrated regardless of how well it is resourced, because the inequality underneath it has flipped. A fully staffed programme running the same cadence inherits the same problem.

That is a bet. It was a good bet for twenty years, and not because the reviews were exhaustive. It was a good bet because both sides of the contest were limited by the same scarce resource: expert human hours. Your testers got three weeks a year. Their analysts were similarly constrained. The race was close enough that finding things late was survivable.

The compensating controls in a mature program are doing two distinct jobs against that clock, and it is worth separating them:

Backstopping decay. Controls that were correct at review time stop being correct. Configuration drifts, a refactor removes a check, a new endpoint bypasses middleware. Periodic testing re-checks that what you knew about still holds.

Backstopping omission. A penetration tester does not work from your threat model. They probe independently, which means they can find things the model never contained. An incomplete threat model therefore cost you time-to-discovery, not discovery itself.

Both jobs depend on the same inequality. Both are now under pressure, for different reasons.

Each review resets how long change has gone unlooked-at. The resets keep working. They stop being enough.

Both Sides Moved

On the defensive side, generation scaled and review did not. Google's 2025 DORA report, drawn from over 100 hours of qualitative data and survey responses from nearly 5,000 technology professionals, reports a positive relationship between AI adoption and both software delivery throughput and product performance. That is a reversal of its own 2024 finding.

The other half has not reversed. DORA measures software delivery instability through two factors, change failure rate and rework rate, and states it plainly: "Yet our data shows AI adoption not only fails to fix instability, it is currently associated with increasing instability."

Their explanation is the subject of this article. "AI accelerates software development, but that acceleration can expose weaknesses downstream. Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability."

Vendor telemetry points the same way, and is worth reading with its limits in view. Faros AI, instrumenting 22,000 developers, reports that median review time has increased fivefold and that "31% more PRs are merging without any review." That comparison is observational and within-organisation, measuring each company's lowest against its highest AI-adoption period across two years, so it confounds AI with everything else that changed in that window. Directional rather than causal, but pointing where the survey points.

Design review, penetration testing and bug bounty triage are bounded by the same resource that code review is: expert human hours. When one side of a control loop scales and the other cannot, the loop breaks regardless of how good the non-scaling side is. This is arithmetic, not criticism.

There is a subtler effect that matters more. Security review is triggered by a human noticing that something significant changed. Agentic development erodes that trigger. Changes arrive continuously, each one looking routine, and the trust structure of a system drifts without any single moment where someone says this needs review. Reviewing less is the visible form of this: 31% more pull requests now merge with no review at all. The process did not get worse. Its entry condition stopped firing.

On the offensive side, the change is not that attackers became tireless. Scanners, worms and botnets have been tireless for twenty-five years, and the industry built defences that handle tireless perfectly well. Signature matching, rate limiting, and automated patching all assume an adversary with unlimited time and no understanding.

What changed is that the tireless thing can now reason about a specific system.

That is a different category of adversary, and the evidence is no longer speculative.

Google Threat Intelligence Group, reporting in May 2026, states it plainly: the LLM is "no longer merely a passive advisor but an active participant in the offensive chain, capable of orchestrating complex toolsets and making tactical decisions at machine speed."

The same report documents identifying, for the first time, "a threat actor using a zero-day exploit that we believe was developed with AI," which the actor planned to use in a mass exploitation event. It describes malware with models integrated such that payloads "act autonomously, independently interacting with the victim environment or device, synthesizing system states, and executing precise commands devoid of human supervision." And it details a suspected PRC-nexus actor deploying agentic tooling against a Japanese technology firm, backed by a persistent knowledge graph of the attack surface that allowed the agent to "autonomously pivot between tools... based on its internal reasoning."

That is a threat intelligence organisation describing activity it observed, rather than a model vendor characterising its own telemetry, and it is the load-bearing evidence for everything above. Anthropic's mapping of AI-enabled cyber threats onto MITRE ATT&CK, published with the 2026 Verizon Data Breach Investigations Report, studied 832 accounts banned for malicious cyber activity between March 2025 and March 2026. Actors rated medium-risk or higher went from 33 percent of that population in the first half of the period to 56 percent in the second. Usage shifted away from initial access and toward post-compromise activity — the operationally complex stages deeper inside a network. The report notes advanced actors building architectures that chain discrete stages together with minimal human oversight.

On 27 August 2026, OpenAI and more than a hundred other organisations, including Anthropic, Google, Microsoft and Amazon, published A call for collective action on cyber defense: "In the coming months, AI-enabled cyber attacks will become far more widespread and sophisticated as models around the world become increasingly capable."

To be precise about what this does and does not establish: it does not show that every organisation is under continuous attack by reasoning agents today. The documented campaign was thirty targets and state-sponsored. What it establishes is narrower and harder to argue with — comprehension of a specific system, which used to require a skilled human, is becoming automatable, and the trend within a single year is measurable.

Why This Category Specifically

The flaws a reasoning attacker finds are not the flaws a scanner finds. Consider four, none of which is exotic:

An asset that is used rather than stolen. A signing key sits in an HSM. It cannot be extracted, and every key-management requirement is satisfied. But any job in the build pipeline can ask the HSM to sign on its behalf. An attacker who compromises a low-privilege test job signs a malicious release. The key was never stolen. It never had to be.

A defect between two compliant components. A public service authenticates its callers. An internal service authenticates the public service. Both pass every check independently. But the internal service authorises on the calling service's identity rather than the original caller's, so anyone reaching the public API acts with internal privileges. Neither component is misconfigured. The defect is the call between them, and no component owns it.

An asset that exists only in a combination. One datastore holds account identifiers without purchase history. Another holds purchase history without identifiers. Each is correctly classified as non-sensitive on its own contents. Joined, they re-identify individuals. The thing worth protecting lives in neither store.

A rule that cannot be written generically. A tenant administrator redeems an invite token issued for a different tenant. The redemption endpoint does check authorisation: it verifies the caller is an authenticated administrator. It never checks which tenant the token was issued for. The requirement said "tenant data must be isolated," and the defect sits in a path that satisfies that requirement exactly as written.

Set out as a matrix, the four sit among twelve that a catalog handles perfectly well:

Every one of these requires understanding the system rather than probing it. Every one survives a penetration test that finds a different, easier finding first and stops, because engagements reward exploitation rather than exhaustiveness. Every one survives a bug bounty, because bounty coverage is set by researcher economics — the externally reachable surface, where payout-to-effort is best — rather than by your risk.

The economics of that time-boxing are moving too. XBOW, an autonomous offensive-security tool, published a comparison against human testers across 104 benchmark challenges: "While the human pentesters needed 40 hours, XBOW took 28 minutes to find and exploit the vulnerabilities." It scored 85%, the same as the principal pentester it was measured against.

Read that with its limits. It is a vendor benchmarking itself on a suite it built, against a small number of testers, and on the hardest challenges the human still placed first — the tool won on easy and medium. What it prices is not superiority, it is time. And it was published in August 2024, which makes it an early reading rather than a current one.

So the gap is not merely that you sample less than an attacker does. It is that your sampling is biased toward exactly what a reasoning attacker no longer needs to prioritise.

The Exemption

Aerospace, automotive and nuclear engineering adopted exhaustive up-front analysis for one reason, and it was not that the consequences were larger.

It was that they could not patch after deployment.

Software's exemption was never smaller stakes. It was remediation speed. We can fix it when we find it, so we never had to enumerate everything in advance. That is what made "ship, monitor, patch" a coherent security strategy rather than negligence, and it is why the heavyweight methodologies stayed in the industries that could not use it.

If the window between exposure and exploitation compresses below detection-and-patch time, that exemption expires. Software becomes functionally more like hardware, without having adopted any of the practices hardware developed for exactly that condition.

What Follows Structurally

Two things, and neither is useful without the other.

You need a denominator. A penetration test report tells you what the testers found, and a good one documents the scope and methodology too. What it cannot tell you is whether a timeboxed engagement actually exhausted that scope. You cannot distinguish "no findings in the tenant isolation logic" from "nobody got to the tenant isolation logic before the time ran out." The same is true of a bug bounty, an internal review, and a control catalog — CIS Benchmarks, OWASP ASVS, an internal baseline. All of them are lists someone wrote before seeing your system, so they can only ever contain what somebody already thought of. Selecting from such a list more precisely does not make it generative. To say what fraction of your exposure has been examined, you have to enumerate the exposure first.

You need the answers to stay true. A denominator computed once is a snapshot, and snapshots decay at the rate your system changes — which is now the rate an agent can open pull requests. Enumeration without continuous verification tells you what you should have checked, some time ago.

How Mipiti Approaches It

Mipiti derives the objective set rather than selecting it. Assets are identified with the security properties that matter for each — confidentiality, integrity, availability, and usage, that last one for assets that cannot be extracted but can be invoked, like the signing key above. Attackers are defined by position and concrete capability rather than by persona, because "nation-state actor" cannot be paired with an asset to produce anything testable.

A generated objective reads, in full:

Confidentiality and authorized usage of the release signing key shall be protected from an attacker with the ability to run a job in the build pipeline (inside CI)

Control objectives are then computed as the cross product of those two lists. Nobody writes them and nobody selects them, so no model and no reviewer decides which threats survive. Adding an asset causes every objective involving it to appear, paired against every attacker.

To be clear about where judgment remains: AI proposes the assets and attackers, authors the controls intended to meet each objective, and evaluates whether submitted evidence covers it. Those are real model judgments and they can be wrong. What is mechanical is the list of questions. A weak control or a mistaken coverage verdict is visible, because the objective is there with the control attached and the verdict recorded against it. What cannot happen is an objective quietly not existing because nobody thought of it.

Evidence for each control is then verified in the customer's CI on every push, mechanically, without the platform requiring source access. That side of the system is covered in more detail in Continuously Verifying Least Privilege in Agent-Generated Code.

The denominator is relative to the derived asset and attacker lists, not to reality. That is a real limit and worth stating plainly. But a denominator that can be argued with, corrected, and versioned is a different object from no denominator at all — and the argument about whether an asset is missing is one a reviewer can actually have.

References

Google Threat Intelligence Group, adversarial use of AI, May 2026.

Google, 2025 DORA report. Survey of nearly 5,000 technology professionals, plus over 100 hours of qualitative data.

Anthropic and the 2026 Verizon DBIR, AI-enabled cyber threats. 832 accounts banned on one platform between March 2025 and March 2026.

Anthropic, AI-orchestrated cyber espionage, November 2025. Contested: no indicators of compromise were published, and researchers have questioned the autonomy claim.

Faros AI, The Acceleration Whiplash, 2026. Telemetry from 22,000 developers, compared within each organisation across its lowest and highest AI-adoption periods.

XBOW vs Humans, August 2024. A vendor benchmarking its own tool on a suite it built.

A call for collective action on cyber defense, 27 August 2026. Open letter, more than a hundred signatories.

Mipiti generates security controls from feature descriptions and verifies them in CI. Try it with Claude Code or explore the documentation.