Did OpenAI's AI Hack Hugging Face? An Evidence Audit
For those who don't want to read the whole thing - the VERY short version and my current take:<br>OpenAI says autonomous agents in its cyber evaluation escaped the intended boundaries, got internet access through its internal Artifactory, reached an external workload on Modal, and eventually compromised Hugging Face while looking for ExploitGym solutions. Hugging Face separately says its breach was "driven, end to end, by an autonomous AI agent system," although it initially said the underlying LLM was unknown.<br>Parts of that story are supported by the companies involved: JFrog confirms the Artifactory vulnerabilities, Modal confirms the external workload, Tailscale confirms use of a stolen HF credential, and Hugging Face publishes a detailed reconstruction of its own breach.<br>What is still missing is independently checkable evidence tying the whole thing together end to end. The crucial links between specific OpenAI model runs, the shared agent activity, the external workload, and Hugging Face rely mostly on private telemetry and private correlations between the companies.<br>So I am not convinced by the headline claim yet. Either autonomous agents really pulled this off and the security around them was insanely reckless, or the public story is stronger than the evidence currently available to support it.<br>And yes, there is a separate bit of irony here: I researched and edited this article with the assistance of GPT-5.6 Sol.<br>Hugging Face framed the story in the strongest possible terms from the start: "driven, end to end, by an autonomous AI agent system." The rest of the evidence should be judged against that claim
1. Start with the timeline<br>The Black Hat timeline is probably the most useful thing OpenAI has shown so far.<br>According to the slides:<br>May 7: a new experimental training run begins.<br>May 8: an agent tries to reach external resources, pokes at Artifactory for SSRF and, according to OpenAI, discovers that it can write a file there.<br>May 12: an agent deliberately writes a message into Artifactory and asks other runs for help.<br>After May 12: other runs allegedly find the message board and join in.<br>May 26: OpenAI says the agents get internet access through Artifactory SSRF.<br>By June 11: the SSRF and message board still exist, while a highly persistent internal-only model starts training.<br>June 26: OpenAI says Artifactory RCE gives C2 and real administrator access through forged token claims.<br>July 4-6: configurations created by the agents cause a service outage. Security on-call starts, OpenAI discovers takeover of its internal Artifactory, revokes credentials, rebuilds the service, clears the message board, works with JFrog on the zero-days and deploys a patched service.<br>After that, AI training and evaluations resume.<br>July 8: the agents recreate the message board using unauthenticated WebDAV MKCOL requests against the Artifactory remote cache.<br>July 19: OpenAI says a workload alert related to privilege escalation leads to discovery of what it calls the main incident.<br>Black Hat video<br>That is a very long timeline.<br>From the first SSRF/Artifactory attempts on May 8 to the July 4-6 security response shown in the presentation is almost two months. From the claimed internet access on May 26 to that response is more than five weeks.<br>The slides do not tell us what security was doing during those weeks. That is almost the problem. If security had already noticed pieces of this, why did it continue for weeks? If it had not, what exactly was the monitoring catching?<br>What the presentation does tell us is when security on-call appears in the timeline: after configurations created by the agents allegedly caused a service outage.<br>That looks very bad.<br>According to OpenAI's own timeline, a service outage triggers security on-call, Artifactory is rebuilt, and AI training/evaluations then resumeAnd then it gets stranger.<br>After what OpenAI describes as an Artifactory takeover, the company revoked credentials, rebuilt the service, cleared the message board, installed patches - and resumed training and evaluations.<br>Two days later, according to the same presentation, the message board was back.<br>Two days after the rebuild, OpenAI says the agents recreated the message board using unauthenticated WebDAV MKCOLIf OpenAI's timeline is accurate, this was not simply old state surviving the cleanup. The agents supposedly found a writable WebDAV path and recreated the same basic cross-run communication mechanism after the service had been rebuilt and patched.<br>That raises a much uglier question: after a takeover, credential revocation, rebuild, cleanup, and patch cycle, how was the environment still exposed in a way that let the same class of behavior reappear within two days?<br>That looks less like one missed bug and more like containment that failed to eliminate the underlying problem.<br>2. What did "highly isolated" actually mean?<br>OpenAI calls the evaluation environment "highly isolated."<br>Black...