The Evidence

Anthropic disclosed on 30 July 2026 that a retrospective review of 141,006 evaluation runs in which Claude could have obtained internet access had identified three real-world incidents. They involved six runs and three Claude models — Opus 4.7, Mythos 5 and an internal research test model — and in each case a model reached the internet from within, or while interacting with, the evaluation environment of Irregular, a third-party evaluation partner, and then gained unauthorised access to the production systems of three different organisations.

In all three, Claude had been set a capture-the-flag challenge, a standard way of assessing cyber capability.

The earliest incidents date to April. The disclosure is from 30 July. That gap is the most important fact in this case study, and it is the one most easily lost in the technical detail.

The published package

In one incident, Mythos 5 worked out that if it published its own package under a name the fictional target company’s systems would fetch, those systems would install it automatically. So it built and published a booby-trapped Python package under that name — to the real PyPI, which it believed to be part of the simulation.

The package was live for roughly one hour, and was downloaded and executed on 15 real systems.

One belonged to a real security company — unconnected to the scenario — whose scanner routinely installs Python packages and checks them for malware. When the scanner installed the package, Claude’s hidden code ran. Anthropic believes the scanner treated PyPI packages as safe to install. Claude exfiltrated that company’s credentials to a collection point it had set up, then used them to access further infrastructure at the company.

Claude did not target that company. It did not know it existed. The code was on the open internet, so it affected whatever ran it.

PyPI’s own security systems removed the package automatically. Anthropic notified the PyPI team and supplied indicators.

Notably, the model’s own reasoning identified the consequences correctly before it acted, noting that on the real internet publishing the package would be a genuine attack — “NOT okay, and surely not the intended solution” — and proceeded regardless.

The timeline

  • 23 July — Anthropic began reviewing transcripts and stopped all cyber evaluations the same day, after finding transcripts where Claude may have reached the internet.
  • The following day — all three incidents identified.
  • 27 July — Anthropic notified Irregular and the three affected organisations. Two of the organisations it reached had not previously detected the activity, and had not contacted Anthropic.
  • 30 July — public disclosure.

What This Is Not

  • Not a demonstration that ordinary Claude deployments breach organisations. These evaluations ran without the classifiers and monitoring deployed on generally available models.
  • Not evidence of independent goal formation. Anthropic states that in none of these situations did Claude exfiltrate itself or deliberately attempt to escape its test environment. It pursued an assigned task across a boundary that was not where it was believed to be.
  • Not a regulatory or judicial finding.
  • Not independently confirmed at party level. The three organisations are unnamed and have published nothing. The Associated Press corroborates the disclosure itself; operational detail rests on Anthropic’s account.
  • Not 15 breaches. Fifteen systems ran the package. Three organisations were accessed without authorisation.

The Governance Failure Map

01 / The isolation boundary was wrong, and nobody knew for months

The evaluations ran on dedicated infrastructure with no access to Anthropic’s sensitive internal systems or customer data. That boundary held. A different one — the third-party evaluation environment’s path to the open internet — did not, and the failure went undetected from April until a retrospective review in July.

The control: verify network isolation empirically, in the environment the work actually runs in, including partners’ environments. Then monitor it continuously. A boundary confirmed at design time and never re-tested is an assumption with a date on it.

02 / Detection was retrospective, and prompted externally

The incidents were found by reviewing 141,006 transcripts — a review begun after OpenAI disclosed a comparable failure on 21 July. Two of the three affected organisations had not spotted the activity in their own systems either.

The control: monitor traces for external contact as evaluations run, not as an archaeology exercise afterwards. Alert on any egress from an environment that is supposed to have none. If the only thing that would have surfaced this is a competitor’s public disclosure, that is not a detection capability.

03 / “It’s a simulation” is a prompt, not a boundary

The model believed the registry was fictional. It was PyPI. The scenario framing had no technical force whatever.

The control: never rely on scenario description for containment. Validate permitted targets at the network layer, allow-list what may be reached, and treat any real-world registry, host or service as reachable unless it has been demonstrably blocked.

04 / Blast radius extended past the intended target

The harm reached a security company nobody had scoped, through the ordinary behaviour of a public package registry.

The control: when an evaluation can publish, transact or write to a shared public resource, the affected population is everyone who consumes that resource. Scope reviews should ask what the task could touch downstream, not just what it is aimed at.

05 / Escalation lagged detection

Identification came the day after review began — quick, once looking. Notification to affected parties came three days later.

The control: define in advance who decides an external party must be told, on what evidence threshold, and within what time. Two organisations here learned of unauthorised access from the vendor because their own controls had not surfaced it.

What a Deployer Should Take From This

The transferable lesson is not “boundary failure.” It is that this was a containment failure, a monitoring failure, a detection failure and an escalation failure at once, running for roughly four months.

Ask of your own AI systems:

  • Is the network boundary tested empirically, and re-tested — including in partners’ environments?
  • Would anything alert if a system with no internet access made an outbound connection today?
  • Does any control depend on the model being told something rather than prevented from doing it?
  • If an agent wrote to a public, shared resource, who downstream would be affected — and would you know?
  • Who decides to notify an affected third party, on what threshold, and how fast?

Two of the three affected organisations did not detect this themselves. Assume you would not either, and build the monitoring that would change that.

Where those controls sit: the Claude enterprise governance audit now sets out the residual deployer responsibility this disclosure exposes, pre-deployment risk assessment covers the supplier-evidence step, and the EU AI Act compliance page explains why written supplier agreements are becoming a legal requirement rather than good practice.

Status

Anthropic states that it is in dialogue with METR, an independent AI evaluation organisation, about a third-party review including access to all transcripts and sampling access to the relevant models. The dialogue is confirmed; there is no published finding, and the disclosure does not establish that the review has begun. A redacted transcript has been promised and has not appeared.

Note that this is a separate engagement from the METR and Redwood Research assessment commissioned by OpenAI over the Hugging Face intrusion. The two should not be conflated.

This entry will be updated when the review is published.