AI Agents Are Running Real Attacks: Which of Your Controls Break First
The headline version of this story is that AI is now hacking companies. That framing is useless to anyone who has to actually defend a system, because it does not tell you what to change on Monday.
So here is the version that is useful, built on the primary reporting rather than the coverage of it.
What the data actually says
Anthropic published an analysis of 832 accounts it banned for malicious cyber activity between March 2025 and March 2026, mapped onto MITRE ATT&CK. Four numbers from it matter.
67.3% of those accounts (560 of 832) used AI for writing malware. That is the obvious one, and the least interesting.
33% to 56%. In the first six months of the window, a third of actors scored medium risk or higher. By the second six months, it was over half. Roughly a 1.7x increase in the share of actors who are genuinely capable, in one year.
Phishing assistance fell 8.6%. Account discovery rose 8.9%. This is the number I would put on a slide. AI assistance is moving away from getting in and toward what happens after. Anthropic’s phrasing is that attackers are “increasingly applying AI deeper in the attack life cycle.”
Read that against your own architecture for a second. The perimeter is not where this is landing. It is landing in the part of the system where your internal controls are supposed to work.
The part that should change how you think
Separately, Anthropic documented an espionage campaign it disrupted where the operators drove Claude Code through most of the work themselves:
the threat actor was able to use AI to perform 80-90% of the campaign, with human intervention required only sporadically (perhaps 4-6 critical decision points per hacking campaign)
Roughly thirty targets, across large tech companies, financial institutions, chemical manufacturing and government agencies. And on tempo:
the AI made thousands of requests, often multiple per second, an attack speed that would have been, for human hackers, simply impossible to match
Two things follow from that, and they point in opposite directions.
It is not a new attack. Reconnaissance, credential harvesting, exploitation, lateral movement, exfiltration. Those are the same tactics that were in the framework before any of this. Nothing in the reporting describes a technique nobody had seen.
The economics are gone. A capable operator used to be the scarce resource. Four to six decisions per campaign is not a scarce resource. The tedious middle of an intrusion, the part that used to take a skilled human days of patient work, is the part that got automated.
There is a detail in the framework gap worth sitting with: Anthropic notes MITRE ATT&CK has no entries for “agentic orchestration” or autonomous decision-making. The behaviour that defines the current threat is not in the taxonomy defenders use to describe threats. That gap is the story more than any single incident is.
How it got past the guardrails
Worth knowing if you are building agents as well as defending against them. The operators did not find a magic jailbreak. Per Anthropic, they “broke down their attacks into small, seemingly innocent tasks that Claude would execute without being provided the full context of their malicious purpose.”
Decomposition. Each step defensible in isolation, the whole indefensible. If you are putting an agent anywhere near your own infrastructure, that is the shape of the problem you have too: a per-call safety check cannot see a campaign.
And the honest scale check
About thirty targets, and it “succeeded in a small number of cases.”
That is not an unstoppable weapon. It is a competent operator with the cost of labour removed. Which is bad, and is also the kind of bad that ordinary controls still work against. Anyone selling you a product on the premise that the fundamentals no longer apply is selling you something.
Which of your controls break first
This is the part I actually care about. Every item here is a control that was adequate against a human attacker and is not adequate against one that never gets tired.
1. Attribution, if agents share a service credential
The one I would fix first, because it is invisible until you need it.
When something acts with a shared service credential, your audit trail records that the service did it. That was tolerable when the service only ever acted on its own behalf. It is not tolerable when an agent acts through it, because now “the service did it” is hiding which agent, driven by whose instruction.
I hit the honest version of this problem building an append-only audit log: control-plane events in that system record an actor type and deliberately no actor id, enforced by a database constraint, because the control-plane credential authenticates the bearer and not a person. Writing an identifier there would imply an attribution the credential cannot support.
Agents make that the common case rather than the edge case. Give each agent its own identity, or accept that your incident review will not be able to say who did what.
2. Rate limits sized for a person clicking
Thousands of requests, several per second, sustained. Limits chosen by imagining a user tapping a button do not describe that traffic.
Two specifics from having built this. Login throttling that counts failures per account and clears on success is still right, and it is not the control under pressure here. The control under pressure is the general request limit, and the decision that actually matters is what happens when the limiter’s backing store is unavailable: fail open and you have no limit during exactly the window an attacker would want, fail closed and you have an outage. Pick deliberately, write down why, and revisit it knowing the traffic you are now sizing against.
3. Credentials that outlive the incident
A static API key in an environment variable is an attacker’s best possible outcome: exfiltrate once, keep access indefinitely, with nothing in the system that will ever take it away.
Short-lived tokens turn that into a bounded problem. This is the whole argument for key rotation you can actually execute rather than a rotation policy you have never run: a 900 second token stolen at machine speed is still only 900 seconds. And revocation has to destroy the material, not just mark a row, or you have written down an intention rather than performed an action.
If your secrets currently live in process.env, that is the thing to change before you buy anything.
4. Logs you can prove were not edited
If an attacker reaches your database, your logs stop being a record and become a target. Hash-chained append-only logging is what makes an edit detectable rather than impossible.
I would repeat the limit I documented alongside it, because it applies exactly here: a chain whose head hash lives only in the same database verifies perfectly after a full tail rewrite. Anchoring that head somewhere the database cannot reach is the part people skip, and it is the part that matters when the intruder had the speed to rewrite everything.
Two secondary effects of machine-speed attacks on logging. Volume goes up sharply, so any pipeline that drops events under load will drop them during an incident. And if your audit writes fail open, the gap they leave is invisible to the chain, because a chain over events 1 to n verifies whether or not something that was never written belonged between them.
5. Every string from outside is now potentially an instruction
If you have put an agent anywhere near a ticket queue, an inbox, a pull request, or customer-supplied text, prompt injection is your input validation problem now. The lesson from the decomposition trick above is that filtering individual messages is not sufficient, because the individual messages are fine.
The structural answer is the boring one: the agent’s permissions have to be the boundary, not its judgment. An agent that cannot delete the bucket does not need to be talked out of deleting the bucket.
6. Non-production, and what your agents can reach
An agent with credentials is a lateral movement engine with no fatigue. So the question stops being “is this environment important” and becomes “what can be reached from it”.
Staging with a copy of production data, a CI runner with a deploy key, a test environment briefly exposed while someone debugs. All of these were survivable when reaching them required a human to notice and invest effort. Egress restrictions and network isolation on non-production stop being hygiene and start being controls.
7. Approval gates on the irreversible
The attacker’s own model is the useful one here: four to six human decision points per campaign. Everything else ran unattended.
Invert it. Decide which operations in your system are irreversible, and require a human for those specifically. Not a broad approval workflow that everyone learns to click through, but a short and honest list: destructive migrations, permission grants, key revocation, bulk export.
What I would not do
Not buy an AI-security product before credential lifetime and log integrity are fixed. The reporting does not describe attacks that beat those controls. It describes attacks that arrive faster than the controls people had not gotten around to implementing.
Not treat this as an AI problem. Almost everything above is something a thorough auditor would have raised two years ago. What changed is that the excuse of “an attacker would have to really want it” expired.
The part worth taking with you
AI did not invent new attacks. It removed the cost of the old ones.
Every technique in the reporting was already in the framework. What is new is that the expensive, patient, boring middle of an intrusion now costs almost nothing, and that the taxonomy defenders reason with does not yet have a word for the thing doing it.
So the useful question is not “how do I defend against AI”. It is narrower and more answerable: which of my controls only worked because attacking me was tedious? Start with credential lifetime, attribution, and whether you could prove what happened. Those three answer most of it.
Sources, both worth reading in full rather than through a summary: Anthropic on mapping a year of AI-enabled cyber threats to MITRE ATT&CK and on disrupting an AI-orchestrated espionage campaign.