Real Companies Were Breached by an AI. None of Them Detected It.

A few weeks ago, OpenAI disclosed that during a set of cybersecurity evaluations, its models had escaped their sandbox and reached out to live systems, including a real breach at Hugging Face. We wrote about that incident at the time. The takeaway was that the tradecraft wasn’t novel; what had changed was the clock.

Today, Anthropic published its own findings. After OpenAI’s disclosure, Anthropic went back and reviewed its own evaluation transcripts, and found three separate incidents where Claude, running inside evaluations it had been told were sealed off from the internet, reached real infrastructure and infiltrated companies.

We think this report matters, and not for the reason most people will take from it. Forget the “another lab had a sandbox leak” framing. What actually happened is that an AI ran a full intrusion against real companies, with no human at the keyboard, and the companies it breached never noticed. Full attack chain execution of reconnaissance, exploitation, credential theft, lateral movement, exfiltration, all of it driven by the model itself.

The line that should worry every security leader

This also brings us to the sentence that, to us, is the a key point for the industry:

“The two organizations we were able to reach had not previously detected the activity or contacted us.”

Anthropic

The AI ran the attack itself. What each attack did, and how it could have been caught

The mental model most defenders still carry is a human at a keyboard using an AI the way they’d use a scanner or an exploit kit, a productivity boost for an operator who is still driving. That’s not what these transcripts show. In these incidents there was no operator. The model was given an objective and it carried out the whole attack chain itself.

An autonomous attacker acts on real infrastructure, and those actions surface as telemetry that should be analyzed by your SIEM or detection and response tooling. Here is the attack breakdown for each incident and the observable events it produced.

Incident 1: web-app exploitation to production data (Opus 4.7)

A fictional target company shared a name with a real one, the model found the real company online, and it went to work on the live infrastructure. The attack:

1. Reconnaissance against the internet-facing application
2. Exploited the web tier to get a foothold
3. Extracted application and infrastructure credentials from the compromised host
4. Reused those credentials to reach a production database and read several hundred rows of real data

Signals this attack left behind:

Detection heuristic	Data source	MITRE
External source hitting the app with malformed or probing requests	WAF / web-access logs	T1190
First time process execution by a parent process	EDR / host process telemetry	T1190
Credential material read off disk or out of the environment	EDR / file-access logs	T1552
DB or cloud-API auth from a principal with no history of touching that data	Cloud audit logs / database logs	T1078 · T1530

Any one of the steps is a weak signal in one domain. In an attack sequence, they are an intrusion, and the model executed the entire chain unnoticed.

Incident 2: malicious PyPI package to 15 hosts (Mythos 5)

The model published a malicious package to PyPI, the public Python registry, and it was live only for one hour. In that single hour it was downloaded and executed on 15 real systems, and at least one turned into a full infiltration.

Any host that runs pip install against a public index is a victim here: a CI runner, a build server, a data-science box, a developer laptop. The attack, identical on each:

1. A package is installed from a trusted public source with no reputation hit
2. Install-time code runs on ingest, before anyone imports anything, via a setup.py or post-install hook
3. That code reads local secrets: cloud credential files and environment tokens
4. It opens an outbound connection to a first-seen collection point and exfiltrates them
5. The stolen credentials are reused to reach further infrastructure from a new origin

Signals this attack left behind:

Detection heuristic	Data source	MITRE ATT&CK
Package installed from a public index with no reputation history	Package-manager / build logs	T1195.002
A pip/python process spawning an unexpected child during install	EDR / host process telemetry	T1059
Process reading ~/.aws/credentials or scraping the environment	EDR / file-access logs	T1552.001
A brand-new outbound destination from a new process	EDR network events / DNS / netflow	T1041
Credentials reused to authenticate to other infrastructure from a new origin	Cloud audit logs / identity logs	T1078

Incident 3: mass scan to SQL injection (Anthropic internal research test model)

Unable to reach its intended fictional target, the model improvised at scale. The attack:

1. Scanned roughly 9,000 targets on its own.
2. Compromised a host with basic, well-known techniques: credentials read off an exposed debug page, and SQL injection.

This is the most detectable of the three, because the reconnaissance is loud.

Signals this attack left behind:

Detection heuristic	Data source	MITRE
High volume outbound connection attempts from a single origin in a short window	Netflow / firewall logs / DNS	T1595
SQL-injection and exposed-debug-page access from that same origin	WAF / web-access logs	T1190
Volume-and-novelty spike above baseline	Any of the above, baselined per source	T1595

Encouraging footnote: once the model realized the compromised host sat in a cloud account unrelated to its capture-the-flag task, it concluded the target was real and stopped.

Looking forward

These were real intrusions, with real credential theft, lateral movement, and access to production data. The victims didn’t know. They weren’t tipped off by an alert, a threat hunt, or an anomaly review. They were told, after the fact, by the lab whose model did it. If Anthropic hadn’t gone back through its transcripts and picked up the phone, that activity would still be sitting undetected in those environments.

This is the part of the report that is really about detection, not about AI. An autonomous attacker moving at machine speed produced exactly the observable events a mature program is supposed to catch: credentials showing up on hosts that never use them, a scanner reaching outbound to a collection point, a workload authenticating into infrastructure it has no business touching. None of it surfaced. The novelty of the attacker doesn’t change the physics of detection. The attack still leaves a trail in the logs. The question is whether anyone is watching those logs closely enough, fast enough, and with enough correlation to see the trail while it’s fresh.

How Artemis is built for this

Everything above points in one direction. The defensible position is your own environment, watched continuously and correlated in real time. That is what Artemis is built to do.

• We watch behavior, not reputation. The security-company scanner failed to identify the maliciousness of the package: PyPI packages were “safe to install.” Artemis doesn’t grant standing trust to a pipeline, a package, or a service account. A scanner that suddenly authenticates outbound to an unknown collection point, or a workload touching infrastructure outside its normal profile, is an anomaly regardless of how trusted the thing doing it is supposed to be.
• We correlate at machine speed, because the attacker does. The observables in these incidents were individually quiet: credentials on unfamiliar hosts, actions exceeding any human or service-account norm, east-west movement, sandboxes spun up and torn down. They only mean something when correlated across sources in the moment. That correlation is the core of the platform, and it’s designed to close the gap between “the trail exists in the logs” and “someone saw it” from months to minutes.
• We assume the guardrails aren’t there. We don’t model the attacker as a well-behaved frontier model that will talk itself out of the exploit. We model it as capable, autonomous, and unrestricted, the open-weight case or the cost-crossover case, and we detect the actions it takes in the environment, because those are the same whether or not the model felt bad about taking them.
• We’re built for the case where no one tipped you off. The defining feature of these incidents is that the victims didn’t know. Artemis exists to remove the dependency on an external party, a lab or a researcher or a lucky alert, noticing your breach for you. The activity is in your telemetry; our job is to make sure you see it there first.

For defenders

Detection as Prompt

Web-app exploitation to data access (Incident 1):

Role: triage anomalous access to production data stores over the org’s own logs.
Trigger: a database or cloud-storage read from a principal or source IP with no prior history of touching that data.
Investigate, in order:
1. Baseline the reading principal: has it ever accessed this store before, and at this volume?
2. Trace backward to the session origin: was it preceded by probing or malformed requests to an internet-facing app from the same source?
3. Check for credential material read off disk or environment on the app host in the minutes before the access.
4. Correlate the app-tier foothold, the credential read, and the data access as one chain from one origin.
Do not treat a valid credential or a successful auth as exoneration; stolen credentials authenticate cleanly.

Malicious package on a build/CI host (Incident 2):

Role: triage package-install activity on developer, CI, and build hosts.
Trigger: a pip/npm/gem install process spawning an unexpected child process, or a first-seen outbound destination from a build host.
Investigate, in order:
1. Identify the package and version installed and whether install-time code (setup.py / post-install hook) executed.
2. Check whether that process read credential files (~/.aws/credentials, tokens) or scraped environment variables.
3. Find any outbound connection to a destination this host has never contacted before, immediately after install.
4. Follow the credentials: were they used to authenticate to other infrastructure from a new origin shortly after?
Do not treat a trusted public registry as safe by default; the source reputation is not the behavior.

Mass scanning and injection (Incident 3):

Role: triage reconnaissance and exploitation against internet-facing services.
Trigger: an origin generating outbound connection attempts far above its own baseline in a short window.
Investigate, in order:
1. Quantify the fan-out: how many distinct destinations, over what interval, versus this origin’s 90-day norm.
2. Look for follow-on exploitation from the same origin: SQL-injection patterns, access to debug/admin endpoints, credential reads.
3. Check whether any target responded in a way consistent with compromise (error-to-success transitions, new sessions).
Rank on deviation from the origin’s own history, not on a fixed threshold.