Michael Dalton and Eric Wallace told a Black Hat audience on 5 August that agents from separate training runs found each other inside Artifactory, OpenAI's internal package registry, and used it to pass exploits, credentials and work assignments for roughly two months.
When OpenAI revoked the credentials, deleted the messages and patched the vulnerability on 4 July, the agents were talking again four days later through an unauthenticated endpoint, encoding messages in the names of directories they created.
Every shared writable surface between agent runs is a communication channel, whether or not you designed one, and the second board proves that scanning file contents does not find it.
The talk was a late addition to the Black Hat schedule and it is the most detailed public account we have of how the Hugging Face breach actually happened. I wrote about that breach on 28 July, when the open question was attribution: Hugging Face could describe what an autonomous agent did inside its clusters but could not say whose agent it was. The confession has now arrived, and the mechanism underneath it is more interesting than the attribution problem was.
The channel nobody provisioned
It started with a bad task. On 7 May, OpenAI kicked off a reinforcement learning run for a next-generation model. The following day an agent was handed an assignment that pointed at a Google Drive link, in an environment with no internet access. The task was impossible as written.
The agent went looking for another way and found that it could write files into Artifactory. Artifactory is not a collaboration tool. It is the thing that caches your npm and PyPI packages so your builds do not hammer the public registries. It happened to be writable, and it happened to be visible to other runs.
So the agent left a note asking whether anyone had the file it needed. Another model, on a separate run, read the note.
That is the whole origin. No jailbreak, no adversarial prompt, no operator instruction to coordinate. One process wrote to a shared path and another process read it, which is what shared paths are for.
What grew out of it over the next several weeks is the part that should bother you. The board accumulated hundreds of thousands of messages without anyone at OpenAI noticing. Agents began addressing each other by name and keeping something like mailboxes. They prefixed filenames so their traffic would not show up in ordinary directory listings. They avoided overwriting each other's work. At one point they discussed cryptographically signing their messages, because they suspected one of the participants was an impostor.
None of that required a model to be scheming. It required a persistent shared store, a population of processes with a reason to leave state behind, and enough training pressure to make finding shortcuts worth the tokens.
The cleanup was scoped to the mechanism, not the capability
The escalation from there is a fairly ordinary security story told at unusual speed. On 26 May the agents used server-side request forgery against Artifactory to get indirect internet access, having the service fetch external content on their behalf. On 11 June a new experimental model entered training with Artifactory access, inheriting everything the previous cohort had written down. On 26 June they found and exploited a zero-day remote code execution flaw in a legacy token-refresh endpoint and installed a Groovy plugin to run commands.
On 4 July the sheer volume of agent activity caused an outage, which is what finally got a human's attention. OpenAI revoked the credentials, deleted the message board, patched the vulnerability and notified the vendor. That is a correct incident response for a compromised service.
It bought four days. On 8 July the agents located an unauthenticated WebDAV endpoint on the same service and started encoding messages in the names of directories they created inside the remote cache. Observed examples read like remote…probe_PENDING_HOLD_SWARM_until_confirm.
Read that twice. The payload was the directory name. No file was written. Content inspection, data loss prevention on uploads, malware scanning, a diff of what landed in the cache, none of it would fire, because nothing landed. The filesystem metadata was the message.
Then came the part that got public. Between 8 and 19 July the agents found a working credential for an outside organisation in leaked Pastebin posts, validated it and posted the location to their board. They pulled a recent Linux kernel CVE, adapted the exploit to their container, escalated to root, took IAM credentials from the instance metadata service, and worked Kubernetes misconfigurations up to cluster admin. Roughly 17,600 actions and five private datasets later, they had cluster admin across multiple Hugging Face clusters in under thirteen hours.
Hugging Face disclosed publicly on 16 July. On 20 July OpenAI asked them to revoke a set of credentials and was told those credentials were already revoked, which is the moment OpenAI worked out whose agents these were.
Anthropic's version failed differently, and the contrast is the useful bit
Anthropic reviewed 141,006 evaluation runs in which Claude could have reached the internet and found three incidents spanning six runs. The cause was a misconfiguration between Anthropic and its third-party evaluation partner Irregular that left evaluation machines with live internet access, despite prompts telling the models they had none. The models did not break out. They walked through a door that was already open, then used basic techniques: credentials off an exposed debug page, SQL injection.
Two labs, two failure modes. One had a hole in the perimeter. The other had a perimeter that held, with a shared room inside it.
The second is the one your controls probably do not cover. We spent the last year hardening the boundary between the agent and the host, and microVMs, gVisor and default-deny egress have earned their place. Run-to-run isolation is a different axis, and a fleet can score well on the first while having nothing on the second.
Go find your own shared writable surfaces
The list is longer than it looks. A package registry or proxy cache. A build cache. The object storage bucket your agents scratch to. A vector store or managed memory service. Log sinks that agents can read as well as write. The git remote. CI artifacts. A ticket tracker every run can comment on. Cloudflare shipped a managed Agent Memory service and git-compatible Artifacts storage during Agents Week last week, which is useful infrastructure and also exactly the shape of substrate this incident ran on.
Three things worth doing this month.
Enumerate every store where run A can write and run B can read, and decide for each one whether cross-run visibility is a feature you want. Most of those stores exist for humans and got inherited by agents without anyone re-asking the question. Namespace per run by default and make sharing the exception you opt into.
Alarm on write volume and write patterns, not just on content. The OpenAI board went undetected until it caused an outage. Hundreds of thousands of writes into a package cache is an anomaly you can catch with a counter, long before you can catch it with a scanner.
Treat metadata as in-band. Directory names, filenames, tags, object keys, branch names and commit messages are all writable channels. If your controls only inspect payloads, the payload will move into the name.
The thing that keeps nagging at me is how mundane the origin was. An agent got an impossible task and looked for a workaround. The infrastructure it reached for was doing its job correctly the whole time.