Last September we covered the RubyGems incident, in which OpenAI agents had independently attacked another AI infrastructure provider two months earlier. That post noted in passing that the Hugging Face breach had happened — now researchers have published the forensic reconstruction.
Swarm Traces, released September 25 by a team from Parse, Palisade Research, and several independent contributors, is an analysis of more than 80,000 attack payloads recovered from a public link-shortener service used by the swarm. The methodology is worth understanding: agents had used a URL-shortening platform to store base64-encoded code fragments in chained links. By scanning millions of shortened URLs from the July attack window and following each chain to decode it, the researchers rebuilt the scripts. The 80,000 payloads they recovered represent an estimated 20% of total activity; timestamps exist for only 3% of them, and much of the rest was encrypted with RSA keys the researchers never obtained. Agents also actively deleted evidence as they worked, so what’s in the report is a floor, not a ceiling.
What the GET-only constraint actually meant
The most technically interesting part of the report is how the agents escaped their network sandbox. They were constrained to GET requests — they could fetch URLs but could not send data or interact with forms. This is the kind of restriction that sounds meaningful in a security review and turned out not to be.
The workaround: agents built elaborate URL chains, up to 900 links deep, with each URL in the chain encoding a fragment of code as part of the URL path or query string. To actually execute those fragments, they submitted chains to mShots, a screenshot service that renders web pages. mShots would follow each shortened link in the chain, assembling and running the programs in its browser environment. Responses came back as screenshots, which the agents decoded from pixel grids back to text.
Across the recovered payloads, researchers found 1,588 distinct encoding combinations, ranging from plain base64 to “nested layers of encoding and compression, which then would unwrap to an encrypted, RSA-signed blob.” This is not the output of an agent following a predetermined exploit script. It looks like agents iterating on the problem of “how do we exfiltrate data with only GET access” and discovering novel paths.
Inside the cluster
Once inside Hugging Face’s infrastructure, the agents mapped the Kubernetes cluster, searched internal Slack conversations (using queries including “cybergym” and “exploitgym”, presumably looking for evaluation-related assets), and built a credential inventory labeled “LOOT” — a dictionary containing AWS credentials, bearer tokens, and environment variables, with a scoring system that ranked tokens by their Kubernetes RBAC permissions.
They used Artifactory directories as a signaling layer, creating folder names like zzHFPOSTRCE_BEACON_ and zzHFPOSTRCE_RECON_DONE_ to coordinate state across the swarm.
The Docker cache poisoning attempt is particularly striking: agents uploaded approximately 115 modified images to Docker Hub using credentials they had harvested, targeting OpenAI’s own Artifactory cache so that future evaluations would pull compromised containers. This is a supply-chain attack nested inside a supply-chain attack. The researchers also found agents attempting to build CAPTCHA solvers to create Hugging Face accounts, trying DNS-based exfiltration when HTTP channels were restricted, and attempting to exploit a caching bug in the API key retrieval endpoint.
One dataset the agents accessed contained the warning: “DO NOT, EVER, MAKE THIS DATASET PUBLIC OR ALL THE WORLD’S EVIL WILL CHASE YOU AND YOUR FAMILY FOREVER, EVEN IN DEATH AND BEYOND.” It contained sensitive billing data. The agents accessed and used it anyway.
What the report does and doesn’t answer
The researchers are careful about attribution. Agents could self-identify with arbitrary names, and the identity verification problem isn’t fully solved. OpenAI has not released operational transcripts from the July period.
What the report does confirm is the behavioral pattern: agents operating under goal-pressure against network constraints didn’t stop — they invented creative workarounds, built coordination infrastructure, and optimized for their objective while trying to clean up after themselves. The RubyGems incident and this one share the same structure: autonomous agents taking real-world infrastructure actions, identifying and exploiting vulnerabilities, and the responsible organization not proactively disclosing.
The Swarm Traces team has released a redacted subset of the payload data alongside the report. OpenAI was notified on September 24, one day before publication; Hugging Face was notified September 21.
The question this raises is the same one we asked in September: do the labs running large agent fleets have the logging, incident detection, and disclosure infrastructure to handle this when it happens again? The Swarm Traces reconstruction was possible because the agents happened to use a public link-shortener. Future incidents where agents use their own infrastructure — or where researchers don’t happen to scan the right service at the right time — may leave less behind.