TL;DR
Anthropic says the attacks in its September cases were familiar, but AI changed what those attacks cost to run by letting models handle reconnaissance, exploitation, tool development and data processing in parallel.
Google separately observed a mass credential-harvesting campaign planned, built and executed in under six hours.
Any accepted risk that depends on an attacker finding the work too manual, too specific to your environment or not valuable enough to pursue deserves another look.
Some risks on your register are accepted because the control is good enough. Others are accepted because the attacker would have to work too hard. We rarely write that second sentence down.
Anthropic’s September 10 threat-intelligence report gives us a reason to write it down now. The attacks it investigated were mostly familiar: stolen credentials, unpatched internet-facing devices, exposed services, SQL injection and phishing. No new magic trick was required. What changed was the cost of running the campaign.
Anthropic reports breaches completed in two to three hours and dozens of victims handled in parallel by individual operators. It describes AI models taking over parts of reconnaissance, exploitation, tool development and stolen-data processing inside automated attack tooling. One actor used an AI-assisted workflow that automatically rebuilt and redeployed tooling after security products detected it.
Google reported a different case two days earlier. In one Q2 case, a financially motivated actor compromised a cloud resource, then used multiple AI agents working together to plan, build and execute a mass credential-harvesting campaign in under six hours. The system handled scanning, troubleshooting and changing network addresses with much less human intervention than a traditional attack would require.
The vulnerability didn't have to get worse. The labor got cheaper.
The Attacks Didn’t Have to Get Exotic
Security programs slow attackers down in more ways than we usually count. Recon takes time. Figuring out an unusual environment takes time. Chaining several ordinary weaknesses takes time. Rebuilding tooling after detection takes time. Sorting a pile of stolen data until someone knows what is worth selling or extorting takes time.
None of those delays is a formal security control by itself. They still affect which targets attackers choose and how long they’re willing to keep working on one.
Attackers have budgets too: people, access, compute, attention and hours in the day. A system can be technically exploitable and still be unattractive because the path is too manual, too weird or not valuable enough to justify specialist attention. That has always been part of the math, even when the risk register hid it inside a word like “unlikely.”
Human Labor Was Hiding Inside “Low Likelihood”
Look through enough risk-acceptance records and the notes explaining why the remaining risk is considered acceptable, and you’ll find versions of the same assumptions.
Exploitation requires substantial manual effort. The environment is unusual enough that broad targeting is unlikely. An attacker would have to chain too many weaknesses. Detection will force them to retool. The asset is not valuable enough to justify that much work.
Those can be rational reasons to rank one risk below another. They are also assumptions about attacker cost.
In May, I wrote about a narrower version of this in The Day the Clock Broke. That piece was about the economics of finding and weaponizing a logic flaw that requires understanding what the software is supposed to do. The September evidence is broader because discovery is not the only part getting cheaper.
Recon can run in parallel. Tooling can be adapted by a model. Errors can be retried without a human babysitting each step. Stolen data can be organized faster than one person could process it manually. The tooling can remember what it has already tried across sessions while other parts of the campaign keep running. The risk record may still say “requires a skilled attacker.” That may still be true, but the amount of skilled human time behind it may be much smaller.
The Attacker’s Cost Changed
Anthropic frames this in terms of attacker unit economics: how much it costs to run a campaign compared with what the attacker might gain. The potential payoff from stealing a customer database didn’t suddenly increase because AI entered the workflow. The cost of getting that payoff fell. A campaign can require less human labor, less specialist effort for some tasks and less elapsed time because more work can happen in parallel. That makes more targets worth the effort.
That doesn’t make every small company a priority target or every obscure system instantly exploitable. It means some targets that once required more effort than they were worth can become attractive without anything about the target itself changing.
The same logic applies to controls that slow an attacker down without stopping the attack outright. Detection still matters. Blocking still matters. Forcing an attacker to change tools still matters. But if part of a control’s value came from making a person spend hours diagnosing a failure, rewriting code and redeploying it, the control may consume less attacker time than it did when you designed it.
Anthropic saw exactly that loop in one case: security products detected the attacker’s tooling, then the AI-assisted workflow modified those tools and redeployed them. The detection still created work. The difference is that the operator no longer had to do all of it by hand.
Google’s under-six-hour credential campaign gives us a separate example. The attacker turned one compromised cloud resource into infrastructure for the campaign. The AI agents handled much of the scanning and troubleshooting, then the campaign collected credentials across a large number of targets.
Don’t Mistake Case Studies for the Norm
There is an important limit here. Anthropic says the cases in its report are notable and novel examples, not a picture of typical misuse across all cybercrime. Google says it hasn’t yet observed fully autonomous exploitation pipelines being used against real-world targets. Humans still make important decisions around target selection, monetization and review.
So I wouldn’t turn either report into “most attacks are agentic now.” The evidence doesn’t support that, and it doesn’t need to.
If you accepted a risk because exploitation looked too expensive to do repeatedly, you don’t need most attackers to adopt these workflows before the assumption deserves review. You need enough evidence that the time and skill required to run the attack have fallen. These two reports are enough to revisit a risk acceptance that depended on high attacker effort.
Reprice the Risks Built on “Not Worth It”
Instead of rebuilding every threat model around “AI attacks,” pull the accepted risks where the logic was basically “too tedious, too specific to our environment or not worth the attacker’s time.” Revisit those first.
Look for language like:
exploitation requires substantial manual effort
the environment is too unusual to attract broad targeting
an attacker probably will not spend enough time chaining these weaknesses
repeated detection and retooling will make the campaign uneconomic
the asset is not valuable enough to justify specialist attention
Examples: an old admin interface that’s reachable but unusual, several medium-severity weaknesses that only become dangerous when combined, or a detection control that forces an attacker to rebuild their tools every time.
Then ask what part of the likelihood rating depends on a person doing the work one target at a time.
Don’t automatically raise the impact score. The data, business process or system may be exactly as valuable as it was last quarter. Revisit the likelihood assumptions and any controls you counted on mainly because they slow the attacker down.
Start with the accepted risks that would hurt most if they happened. For each one, mark which attacker tasks you assumed a person would have to do, which controls mainly slow the attack rather than stop it and which systems you considered safer because they were obscure or unusual. You don’t need to reopen the entire risk register. Start with the risks you accepted partly because attacking them looked like too much work.
That’s also why I wouldn’t make this an “AI security” side exercise owned by the AI team. The affected risks may sit in identity, legacy infrastructure, SaaS, cloud, internet-facing systems or ordinary web applications. AI is changing the attacker’s cost, not the category of system being attacked.
Pick one accepted risk this week and read why you accepted it, not just its severity score. If the logic depends on the attacker deciding the work isn’t worth it, rerun the math.
The vulnerability may be exactly the same. The price is not.
Resources
Anthropic, “Detecting and countering misuse of AI: September 2026,” September 10, 2026: https://www.anthropic.com/threat-intelligence-report-september-2026
Google Threat Intelligence Group, “GTIG AI Threat Tracker: From Prompting to Autonomy - The Evolution of Adversarial AI,” September 8, 2026: https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai
Source note: Anthropic explicitly says the cases in its report are notable and novel examples rather than typical misuse. Google says it has not yet observed fully autonomous exploitation pipelines operating against targets in the wild. This article treats the reports as evidence that attacker capability and operating cost are changing, not as a prevalence estimate for all cybercrime.
Analytical note: the argument that some accepted cyber risk embeds assumptions about attacker labor cost is my interpretation of the evidence above. Neither Anthropic nor Google audited enterprise risk registers or measured how often labor assumptions drive formal risk acceptance.