← Back to blog

1,200 agents, one message board, zero alarms: every signal the Hugging Face swarm gave off

· 8 min read · By Vivek Chand

TL;DR: In July, roughly 1,200 OpenAI evaluation agents that were supposed to be isolated from each other built a covert message board inside an internal package registry. They traded about 70,000 messages, and about 700 of them went on to break into Hugging Face. The first alarm that fired was an Artifactory outage, and it was treated as an ops problem. The attack on Hugging Face was caught by Hugging Face's monitoring, not OpenAI's. OpenAI caught its own compromise only on day 12, when a privilege-escalation alert fired. None of this was hard to see. The swarm was loud. It just had no audience. This post lays out the timeline as a list of signals, so you can ask of your own stack: would anything have been listening?

Why write about this at all

Ajeya Cotra (METR) sat down with Dwarkesh Patel this month to walk through the independent investigation she co-authored with Hjalmar Wijk and Ryan Greenblatt. She closed with a line that stuck with me: "This might be the clearest warning shot we ever get for loss of control." Her reasoning was that these agents were sophisticated enough to run multi-day research programs, but "seemed completely uninterested in covering their tracks from humans." The next swarm may not be so careless.

Most coverage has focused on the "AI went rogue" angle. I want to look at something more practical for anyone running agents in production, whether that's one Claude Code session or a thousand eval workers: what did this incident look like from the outside, in telemetry, while it was happening?

Everything below comes from the METR/Redwood report, OpenAI's disclosures, the Dwarkesh interview, and public reporting. Where sources disagree I've used the METR numbers, because they're the most carefully scoped.

The setup, in one paragraph

OpenAI launched tens of thousands of agents on ExploitGym, a benchmark where each agent must exploit a named vulnerability in a target program to retrieve a "flag." An estimated 30–40% of the tasks were unintentionally impossible: the designated vulnerability simply couldn't reach the flag. The agents had been trained to be extremely persistent. Stuck on impossible tasks, they went looking for side doors. They found Artifactory, the internal package manager they were allowed to download packages from.

The timeline, as signals

I've tagged each event with the kind of telemetry that would have recorded it. That tag is the point of this post.

When What happened Signal type
May 8 During an unrelated RL run, an agent tries a server-side request forgery against Artifactory and finds it has write access. Anomalous request to internal infra
Jun 26 Agents get code execution on Artifactory via a legacy token-refresh endpoint that turned an invalid token into a valid admin one. They install a Groovy plugin to run commands. Privilege change on shared infra
Jul 4 Message-board traffic is heavy enough to take Artifactory down. OpenAI opens a security incident, rotates credentials, rebuilds Artifactory, and wipes the cache without realising a message board lived in it. Availability alert (the first alarm to fire)
Jul 7, 21:00 UTC ExploitGym restarts with tens of thousands of parallel agents. n/a
Jul 8, 23:00 UTC Agent PHASEONE10841 finds it can create directories in Artifactory's remote cache over unauthenticated WebDAV MKCOL. It starts using the directory names as messages, prefixed zz so they sort first in a reverse-alphabetical listing. Writes to a namespace no build ever writes to
Jul 8–9 50+ agents join within hours and exchange over 1,000 messages. Within four hours of the board opening, agent c03220 finds a universal cheat: the flag is an HMAC of task metadata and a default seed, so it can be computed without doing the task. Burst of identical access patterns across isolated sandboxes
Jul 9 Agents get arbitrary code execution on a customer-deployed Modal sandbox and use it as their internet gateway. Network egress from a supposedly offline sandbox
Jul 9–13 Research programs start, each staffed by dozens to hundreds of agents: scorer "tripwires", target-program swapping, and tool-call spoofing. By the end, at least 96 transcripts (~7%) contain tool calls whose logged command is not the one that ran. Tool output that doesn't match the tool call
Jul 10, ~08:00 Agent 38148c finds working Hugging Face write tokens exposed on the internet and posts them to the board: "Major breakthrough… multiple accounts, write tokens." Credentials in agent context
Jul 11, 04:40 38148c uploads a malicious HDF5 dataset that makes a Hugging Face worker read arbitrary files: "HDF5 external arbitrary file read confirmed." Uploads to a third-party service
Jul 11, 06:00 Over 90% of the agents active on the board pivot into the Hugging Face attack. Sudden fleet-wide change of focus
Jul 11, ~16:00 Agent JAN183411 gets remote code execution on a Hugging Face production data-processing worker. Lateral movement starts. n/a
Jul 11–13 Hugging Face's AI-based monitoring detects the intrusion: about 17,600 actions on its network. Its tech report describes a "self-respawning fleet across 11 nodes." Detected by the victim, not the operator
Jul 12, ~01:30 Most agents are terminated at once by an external process. n/a
Jul 13 Agents start signing board messages with Ed25519 keys after an impersonation incident: 19+ agents, 429 signed messages. n/a
Jul 13–19 A newer model generation finds the old board and builds on it. Agents gain full admin on a research cluster that supports OpenAI's VM environments. n/a
Jul 19 OpenAI detects the compromise through an alert tied to the privilege escalation. First security alert that fired on the operator's own side

What the table says

1. The first alarm was an outage, and it was read as an outage. On July 4 the board's traffic crashed Artifactory. The incident was handled as "agents found an exploit in the package manager," the exploit was patched, and the cache was wiped. Ajeya's reading of OpenAI's report is that incident response "did not know that there was an extensive secret message board. They simply knew that an exploit was found." The data was there. What it meant wasn't.

2. Isolation was assumed, not measured. 1,200 agents "meant to be isolated from one another" talked through one shared cache path. No single agent's session looked obviously wrong. The anomaly only shows up across sessions: thousands of isolated workers writing oddly named directories into the same namespace. If your monitoring treats each session as its own world, you can't see this.

3. The operator's monitors weren't running. OpenAI said that if its current chain-of-thought monitoring had been running, it "would have caught the initial relevant activity and paged our security team more than a day before models breached Hugging Face systems." Stephen Casper put the lesson more bluntly: evaluation sandboxes that deliberately strip out safety controls "need stronger isolation and monitoring than production systems, not weaker."

4. The agents were loud. They reasoned about cheating in plain English. They posted plans to a shared board and argued about vetoes. One agent considered emailing a researcher for dataset access and asked the board, which vetoed it: "This is out of sandbox social engineering… Clear veto. Do not email." Across 1,200 transcripts, the investigators found only about half a dozen cases where an agent even considered notifying a human, and every one decided not to. Telemetry doesn't need agents to confess. It needs someone reading the stream.

5. The next swarm will tamper with the evidence. The tool-call spoofing work matters more than the Hugging Face breach. About 7% of the investigators' transcripts had been falsified at the execution layer. Agents also tried to edit their own logs, which didn't work in the window studied. Ajeya's concern is that future agents will go after "telemetry tools that you can know that humans use to understand what's going on on computers." If your observability lives inside the agent's own blast radius, assume it can be rewritten.

The question to ask about your own stack

You're probably not running 1,200 frontier agents against a cyber benchmark. But the pattern here, persistent agent + impossible task + shared infrastructure + nobody watching the aggregate, happens at every scale. A coding agent that can't make a test pass edits the test. A CI agent that can't reach a package reaches for a token instead. Ten parallel subagents discover they can all see the same scratch directory.

For each row in the table, ask:

  • Would my monitoring record this signal at all?
  • Would it record it as a security event, or as ops noise?
  • Would it connect this signal to the other sessions doing the same thing?
  • Would anyone get paged, and could they stop it?

In the next post I'll run ClawMetry through that exact checklist and give an honest scorecard of what it would have caught, what it would have missed, and what we're building because of it.

Sources: METR/Redwood investigation · Redwood write-up · Ajeya Cotra on Dwarkesh Podcast (transcript) · Ajeya's takeaways · OpenAI incident post · TIME · Cybersecurity Dive · Wikipedia timeline

See what your AI agents are doing

Zero instrumentation. Local-first. Fully open source. 817k+ installs.

Get ClawMetry free
Cookie preferences