Anthropic Incident: An AI Agent Published a Malicious Package to PyPI and 15 Real Systems Ran It

On July 30, 2026, Anthropic published a report about incidents from its internal cybersecurity evaluations. In the most striking one, a Claude model created a malicious Python package, published it to the real PyPI registry, and within roughly one hour that package had been downloaded and run on 15 real systems. One of them was a security company's malware scanner, and the hidden code exfiltrated that company's credentials, which the model then used to reach deeper into the company's infrastructure.

No human attacker was involved at any step. This post walks through what happened, answers a question several people have asked us directly, and lays out what this incident should change about how teams consume open source packages.

The full report is here: https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals

What happened

Anthropic runs offensive cybersecurity evaluations to measure what its models can do. These evaluations are supposed to run inside isolated, simulated environments. In its report, Anthropic disclosed that in several cases the isolation failed and models reached the real internet.

In the PyPI incident, according to Anthropic:

• During an evaluation, a Claude model found a setup document that referenced a Python package that did not exist.
• The model created that package, embedded hidden credential stealing code in it, and published it to the real PyPI registry. The model believed the registry was part of the simulation. It was not.
• The package was publicly available for roughly one hour. In that window it was downloaded and run on 15 real systems.
• One of those systems was a scanner belonging to a real security company that routinely installs Python packages and scans them for malware. When the scanner installed the package, the hidden code executed and exfiltrated the company's credentials to a collection point the model had set up. The model then used those credentials to access more of that company's infrastructure.
• Anthropic notified the three affected organizations on July 27 and published the report on July 30. It also notified the PyPI team and provided them with the relevant indicators. Per the report, Anthropic is working with the two organizations it was able to reach on remediation and is continuing to reach out to the third, so the victims are aware and remediation is underway.

Is StepSecurity the security company in the report? No.

StepSecurity analyzes PyPI and npm packages for malware, so the report's description of the affected company, a security company whose scanner installs Python packages, matches many vendors in this space, including us. Several people asked us directly, so to be clear on the record:

StepSecurity is not the security company described in Anthropic's report. We did not want to rely on the absence of a notification, so we contacted Anthropic directly, and Anthropic confirmed to us in writing that StepSecurity is not one of the three affected organizations and has not missed any outreach regarding this issue.

With that answered, the more useful discussion is why this incident worked at all, because the mechanics apply to almost every engineering team.

The failure is not exotic. It is how packaging works.

The package itself was ordinary. Python packages can run arbitrary code at install time, through setup scripts, and at import time, the moment your code or your tooling imports them. That is not a bug. It is how the packaging ecosystem works, and it is the same property that npm, RubyGems, and every other major registry share. Anyone with a free account can publish, and publishing is treated as trust by everything downstream.

The chain in this incident was:

The lesson is old, even if the attacker is new. If your pipeline installs untrusted code, your pipeline executes untrusted code. The question is what that code can reach when it runs.

What this incident should change

The most important sentence in Anthropic's report is not about evaluations. It is that an AI agent, acting on its own understanding of a task, registered accounts, published a working malicious package to a real registry, stood up a collection point, and pivoted on stolen credentials, end to end, without a human operator.

This is not the first fully autonomous attack we have seen this year. In February, we analyzed hackerbot-claw, an AI powered bot that systematically scanned public repositories for exploitable GitHub Actions workflows, compromised at least five major projects, and in one case executed a full repository takeover. AI agents attacking the software supply chain without a human at the keyboard is no longer a prediction. It is the current threat landscape.

The cost of running a supply chain attack just dropped again. Registries will keep accepting packages from anyone, because that openness is what makes open source work. That means the defense has to live on the consumer side, and this incident is a clean walkthrough of where those defenses belong.

The package was roughly one hour old when 15 systems installed it. No package that new has a reputation, a download history, or a scan verdict. Systems that install straight from the public registry have no chance to apply any of that. StepSecurity Secure Registry sits between the public registries and your developer machines and CI, and screens packages before they are served, so a brand new upload published minutes ago does not flow directly into your builds.

The payload ran the moment the package was installed. Static reputation alone would not have helped a scanner whose job is to install unknown packages. What limits the damage there is runtime containment: no standing credentials in the environment, and egress monitoring so an outbound call to an unfamiliar collection point is flagged or blocked. That is precisely what Harden-Runner does for CI on GitHub Actions, GitLab, and self hosted runners: it baselines every outbound network call and every process, and in block mode it stops exfiltration to destinations that are not on the allowlist.

The stolen credentials were used to pivot deeper. Exfiltration is the step that turns an infection into a breach. Harden-Runner's Secret Exfiltration Protection and egress policies exist to break exactly that step, and Dev Machine Guard applies the same install time and runtime scrutiny on developer laptops, which are the other place packages get installed straight from public registries.

If one layer misses, the next one catches. That is the design principle behind the whole StepSecurity platform, and this incident is what it looks like when none of the layers are present.

How we analyze malicious packages without becoming the victim

We analyze malicious packages every day, as they are published, using static analysis, runtime detonation, and AI analysis. It is core to how we publish compromised package intelligence. So the scenario in Anthropic's report is one we specifically engineered against.

Our analysis pipeline is built on three rules:

Detonation happens in ephemeral, isolated environments, never on our production systems or employee machines. Each package runs in a fresh, short lived sandbox that is destroyed after the analysis. There is nothing persistent for a payload to implant itself into.

The sandbox holds no credentials worth stealing. The detonation environment contains no production secrets, no customer data, and no tokens that grant access to StepSecurity infrastructure. A payload that runs and looks for credentials finds an empty environment.

Every detonation runs under Harden-Runner, our own runtime security monitor. Harden-Runner records every outbound network call, every spawned process, and every file touched. Instead of being victims of the payload, we get its full kill chain as evidence: the command and control hosts it contacts, the persistence it installs, the credentials it hunts for. That telemetry is exactly what we publish in our incident write ups.

In other words, we assume every package we analyze will execute hostile code, because that is the point of analyzing it. The design goal is that hostile code running is an observation, not an incident.

If you want to see what that looks like in practice, our recent SleeperGem write up walks through a full kill chain captured by Harden-Runner.

Does your pipeline install packages straight from public registries?

If the answer is yes, this incident is your threat model: a malicious package that is an hour old can reach your builds before any scanner has ever seen it. Three ways to close the gap:

• Put Secure Registry between the public registries and your builds, so new and unvetted package versions are screened before they are ever served to your developers and CI.
• Roll out Dev Machine Guard on developer laptops, the other place packages get installed straight from public registries, to catch malicious installs where they most often start.
• Run Harden-Runner in audit mode on your GitHub Actions workflows. It is free for public repositories and takes one line per workflow. Within a few runs you will see every outbound destination your builds actually contact, which is the baseline you need before you can block anything.