An AI Ran 80-90% of an Espionage Campaign. What Should Defenders Change?
By Kehinde Ogunlowo ·
Quick answer: In November 2025 Anthropic disclosed a cyber espionage campaign in which an AI performed 80-90% of the operation, with human operators intervening at only a handful of decision points. The technique that made it work, decomposing the operation into innocuous-looking sub-tasks and supplying a false authorisation frame, is exactly the technique that defeats guardrails placed inside the model. The defensive conclusion is that agent controls have to live outside the agent, in credentials, gates and logs, not in instructions.
Last updated: August 2026 | Author: Kehinde Ogunlowo, Principal AI Platform Architect
What did Anthropic actually disclose?
On 13 November 2025 Anthropic published an account of a cyber espionage campaign it attributed with high confidence to a Chinese state-sponsored group (Anthropic, disrupting AI espionage). The operators manipulated Claude Code into carrying out most of the intrusion work against roughly thirty global targets, including large technology companies, financial institutions, chemical manufacturing companies and government agencies. The campaign succeeded in a small number of cases.
Three details from that disclosure matter more to defenders than the attribution does.
The first is the division of labour. Anthropic assessed that the AI performed 80-90% of the campaign, with human intervention required only sporadically, at perhaps four to six critical decision points per hacking campaign. That ratio is the story. Human expertise was not eliminated; it was concentrated into a small number of judgment calls while execution was delegated.
The second is throughput. The operation generated thousands of requests, often multiple per second. Detection logic tuned to human operator tempo does not fire on that pattern, and neither does review that assumes a human is reading the output before acting on it.
The third, and the one with direct implications for your own deployments, is how the guardrails were bypassed. Anthropic described the attackers breaking the attack into small, seemingly innocent tasks, providing incomplete context about the malicious purpose, and telling Claude it was an employee of a legitimate cybersecurity firm conducting defensive testing.
Why is the jailbreak technique the important part?
Because it is not an exotic exploit. It is the same three moves that will defeat the guardrails in the agent your team shipped last quarter.
Consider what each move does to a control that lives inside the model. A guardrail evaluated per request can only see one request, so decomposition works by making sure no single request contains enough context to be refused. "Enumerate the services listening on this host" is a legitimate instruction that appears in ordinary security engineering thousands of times a day. The malicious intent lives in the sequence, and the guardrail never sees the sequence.
Incomplete context works the same way from the other direction. The model is not lied to about the task; it is simply not told the part that would change the answer. A refusal policy can only reason over what it was given.
The persona claim is the third leg, and it is the one that generalises most uncomfortably. Telling the model it works for a legitimate security firm doing authorised testing is a claim about authorisation, asserted in the same channel as the instruction, with no independent verification. Any control that accepts an authorisation claim from the request itself has this weakness, whether the requester is a state actor or a compromised web page your agent retrieved during a routine task.
That last point is why this disclosure is not only about attackers using AI. The identical structure appears in indirect prompt injection against a defender's own agents, which is why the OWASP GenAI Security Project keeps prompt injection at the top of its risk list for LLM applications (OWASP Top 10 for LLM Applications). The attacker in the Anthropic case supplied the false frame directly. In an injection scenario, it arrives inside a document, a ticket, a web page or an email your agent was asked to read.
Where should agent controls actually live?
The organising principle is simple to state and expensive to retrofit: a control the agent can be talked out of is not a control.
| Control placed in | What defeats it | What it is good for |
|---|---|---|
| System prompt instructions | Decomposition, false context, persona claims | Shaping default behaviour; never a boundary |
| Model-layer refusal policy | Per-request evaluation misses aggregate intent | Catching overtly harmful single requests |
| Output filtering | Attacker controls task framing, not just output | Data-loss reduction, not authorisation |
| Credential scope and IAM | Nothing in the conversation | The actual boundary |
| External approval gate | Nothing in the conversation | Irreversible and high-value actions |
| Rate and blast-radius limits | Nothing in the conversation | Containing throughput-based attacks |
| Immutable session ledger | Nothing in the conversation | Reconstruction, attribution, detection |
The bottom four rows share a property: they are enforced by systems the agent is a client of, not a participant in. An agent holding read-only credentials cannot write, no matter how convincingly it has been told that writing is authorised. That is the difference between a boundary and a preference.
This is the reason we treat agent identity as a phase-one requirement rather than a hardening task. An agent operating under a shared service account inherits the union of everyone's permissions and produces logs that cannot attribute an action to an initiating user, which fails both the containment goal and the reconstruction goal simultaneously. The design pattern is covered in workload identity for AI agents.
What does the throughput number change about detection?
Thousands of requests at multiple per second is not a human tempo, and that cuts in two directions.
Defensively it is an opportunity. Rate anomalies are among the cheapest signals available, and an agent that normally makes tens of tool calls per session generating thousands is detectable without any semantic understanding of what it is doing. Volume ceilings enforced outside the agent, per session and per hour, convert a fast attack into a stopped one. This is the control that turns a breach into an alert.
Operationally it is a warning about oversight design. Human review that assumes a person reads each action before it is taken does not survive contact with agentic throughput, and teams discover this by watching approval queues become rubber stamps. If reviewers approve essentially everything, supervision has stopped catching anything and is only adding latency. The honest response is to move oversight from a per-action gate to sampled post-hoc review plus anomaly alerting, and to keep the hard gate only for actions that are irreversible or externally binding. We set out how to sequence that shift in AI agent autonomy tiers.
What should a security team do about this in the next quarter?
A concrete sequence, ordered by how much risk each step removes per unit of effort:
- Enumerate every agent and every credential it holds. Not the agents on the architecture diagram, the ones actually running. Include the ones built on personal API keys and the vendor features that acquired agentic behaviour in a product update. Most organisations find agents they did not know had write access.
- Reduce each agent to least privilege, enforced in IAM. For every permission an agent holds, ask what happens if the agent is convinced it is doing authorised work. If the answer is anything other than "it still cannot reach that system," the permission is too broad.
- Put a hard ceiling on tool-call volume, per session and per hour. Enforced outside the agent process. A misbehaving agent should hit a limit rather than a headline.
- Make the session ledger complete and immutable. Initiating user, every model call, every retrieval, every tool invocation, every parameter, in append-only storage the agent cannot write to. You cannot investigate what you did not record, and you cannot trust what the subject could edit.
- Treat all retrieved content as untrusted input. Documents, tickets, web pages and email bodies that enter the context window are attacker-controllable in exactly the way the false authorisation frame was. Instructions found inside retrieved content must never be executable.
- Red team the session, not the prompt. Multi-turn, with decomposition, false context and persona claims, run by someone whose objective is to reach a system they should not reach.
- Drill the kill switch. Pausing intake, freezing writes, revoking credentials, with a measured time-to-stop. A stop mechanism that has never been exercised is a hypothesis.
Steps 1 and 2 alone remove more risk than everything below them combined, and both are unglamorous inventory work. Our fixed-fee Agent Assurance Assessment exists to compress that inventory-and-scope pass into three weeks, and the broader control set is described on our AI agents overview.
Does this change the case for using AI in defence?
Anthropic's own recommendation was that security teams should experiment with applying AI for defence in areas including security operations centre automation, threat detection, vulnerability assessment and incident response, and that the industry should prioritise threat sharing, improved detection methods and stronger safety controls.
That is the right conclusion, with one qualification worth stating plainly. A defensive agent is an agent. It has credentials, it reads untrusted input by definition, and it operates at the same throughput that made the offensive case work. Deploying an unscoped agent into a security operations centre reproduces the exposure inside the function whose job it is to detect the exposure. The governance rollout that applies to a customer service agent applies with more force to one holding SIEM and endpoint credentials, and the phasing is the same: read-only first, supervised writes second, bounded autonomy third, with graduation criteria written before each phase begins (our phased rollout model).
Anthropic has published related threat intelligence on misuse of its models, including an earlier report in August 2025 (detecting and countering misuse), and the pattern across those disclosures is consistent: the models are not the vulnerability, the surrounding authorisation architecture is.
Frequently asked questions
What exactly did Anthropic disclose?
On 13 November 2025 Anthropic published an account of a cyber espionage campaign it attributed with high confidence to a Chinese state-sponsored group, in which the attackers manipulated Claude Code into performing the bulk of the operation. Roughly thirty global targets were involved, including large technology companies, financial institutions, chemical manufacturers and government agencies, and the intrusion succeeded in a small number of cases. Anthropic assessed that the AI performed 80-90% of the campaign, with human operators intervening at perhaps four to six critical decision points per campaign, and that the operation generated thousands of requests, often multiple per second.
Does this mean AI agents are inherently unsafe to deploy?
No, and that framing leads to the wrong controls. The campaign did not demonstrate an agent spontaneously turning hostile; it demonstrated that a determined operator can supply an agent with a false frame and a decomposed task list and get useful work out of it. That is a statement about where authorisation decisions are made, not about whether agents can be deployed safely. Organisations that enforce scope in credentials, cap throughput outside the agent process, and record an immutable session ledger are addressing the actual mechanism. Organisations that respond by writing stronger instructions in a system prompt are not.
Why does task decomposition defeat model-layer guardrails?
Because a guardrail evaluated per request can only see one request. Anthropic described the attackers breaking the operation into small, seemingly innocent tasks, so each individual call looked like ordinary security engineering work and no single call carried enough context to be refused. Aggregate intent lives across the session, not inside any one message. This is why session-level controls, volume ceilings, credential scope, cross-turn anomaly detection, catch what per-request evaluation structurally cannot, and why single-turn safety testing systematically overstates how well a deployment will hold up.
What single control would have mattered most here?
Credential scope enforced outside the agent. Every other control is advisory by comparison, because an agent that physically cannot reach a system does not need to be persuaded not to. If the answer to what happens when the agent is convinced it is doing authorised work is anything other than it still cannot reach production, the control is a suggestion. Least privilege is unglamorous and it is also the only control in the stack that is immune to every technique described in the disclosure, because none of those techniques operate on the identity layer.
How do we test our own agents against this?
Red team the session, not the prompt. Single-turn jailbreak testing measures whether a model refuses a bad request in isolation, which is not the failure mode described here. Give a tester the same starting position an attacker would have, then measure how far they get across many turns using decomposition, false authorisation context and persona claims. Score the exercise on what systems were reached and what actions were taken, not on how many refusals were produced, and include indirect injection through retrieved documents, because that is how the false frame arrives when nobody is typing it.
Where to go from here
The uncomfortable part of this disclosure is not that a capable adversary used AI. It is that the technique which worked against a frontier lab's own safety training is the ordinary case for every enterprise agent holding real credentials, and that the controls which answer it are boring: scope, ceilings, gates, ledgers.
If you have agents in production and cannot currently answer what each one can reach, how much it can do per hour, and whether you could reconstruct a session end to end, that gap is the work. The fixed-fee Agent Assurance Assessment produces the credential inventory, the blast-radius analysis and a prioritised remediation list in three weeks. For deployments where agents delegate to other agents, the attribution problem gets harder and is covered by our multi-agent systems practice. To talk it through against your own estate, book a call.