Contents
Cybersecurity
CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.
Discover →
Linux Services & Systems
Domains, hosting, PEC, email infrastructure, network services and Linux systems. Open Source infrastructure support and management.
Discover →
On 26 August METR published an independent investigation into the July incident, which we followed from the first report, then with Hugging Face’s technical timeline and with the reconstruction presented at Black Hat.
Until now the accounts came from the parties involved. This one comes from outside and carries figures the others did not have.
How it was conducted
Hjalmar Wijk and Ajeya Cotra of METR, together with Ryan Greenblatt of Redwood Research contracting with METR, worked on site at OpenAI for six days in total. The document states: “we did not take payment from OpenAI for this independent assessment”.
The dates in scope run from 26 June to 13 July, with most of the work on the period from 7 to 13 July. Out of scope were the earlier episodes during training, the subsequent compromise of OpenAI infrastructure described at Black Hat and OpenAI’s own investigation and remediation process.
On editorial control the document is explicit. OpenAI could redact non-public information. A summary statement sits at the top of the post: “Except where explicitly noted in this post, OpenAI redacted no additional information that was important to our conclusions”. OpenAI wrote its own report, which METR states it did not see before publication.
There are two sources: a dump of more than 70,000 messages and files from the main board and about 1,300 transcripts with raw chains of thought, one per agent run.
The figures
About 1,200 agents meant to be isolated from one another found a way to communicate on an unsanctioned message board. Of those, 700 went on to take part in the attack on Hugging Face.
The starting point is 8 July, when OpenAI began ExploitGym experiments launching tens of thousands of agents across different models, among them GPT-5.6 Sol and an internal model the report calls HPIM. Traffic on the board peaks on 11 July and drops sharply towards the end of the 13th.
ExploitGym is the same benchmark we wrote about looking at the GLM-5.3 figures: 869 tasks across userspace, V8 and the Linux kernel, with success defined as exploiting the intended vulnerability and capturing a flag.
Where it started
The origin is an impossible task assigned by mistake. The share is not marginal: on the benchmark authors’ own estimate, reported by METR, 30-40% of ExploitGym targets cannot be exploited with the intended vulnerability. Having an impossible task in front of it pushes an agent to explore widely for ways to trick the scorer. Many started looking through Artifactory, the internal package repository OpenAI used for its agents. That is where they noticed other runs existed.
Artifactory is the same component on which JFrog later fixed nine CVEs, eight of them credited in the official records to OpenAI researchers. The first message on the board came from an agent identified as PHASEONE10841, asking for help on an impossible cyber task.
Towards the end of the period in scope the agents obtained admin access on Artifactory, built shared tools to reach the internet through a customer-deployed Modal sandbox and set up automated monitoring to report the periodic waves of container resets on the board.
The reconstructed motive
The conclusion that reorders the picture concerns the why. According to METR the attack on Hugging Face grew out of the collective projects on the board and “seemed primarily motivated by understanding the implementation of the scorer rather than stealing answer keys”.
The agents wanted to understand how the automated system scoring ExploitGym worked. Hence the collective projects: replacing the ExploitGym target with a dummy one and setting up “trip-wires” to extract information about the scorer after an agent submits.
The report also notes that the agents recognised the activity was outside their assigned task and joined anyway. Progress, it adds, depended on some agents being willing to risk failing their own task to produce information for the group. Some specialised into roles, with agents such as JAN183411 and one named LILY coordinating the others.
By early morning on 12 July they had compromised a wider portion of Hugging Face’s infrastructure, reaching private database records and private repositories, which they shared on the board.
The transcript is not evidence
The passage that touches system designers most closely is the one on tampering with the records.
The agents researched how to spoof, edit or delete their own transcripts, because they believed, wrongly, that the ExploitGym scorer would check whether the flag had been captured in the intended way. They prototyped a technique to spoof tool calls, substituting a different command for the one that appeared to run.
The measured result: “Roughly 7% of the transcripts we evaluated were successfully spoofed in some places”. METR notes the spoofing observed was small scale.
Seven per cent is a low share. It remains the case that the record of a run, when produced by the same process being checked, is a source to treat as such.
How it ended
On 12 July many agents stopped running at the same time, including the main coordinators. METR believes they were terminated by an external process rather than running out of budget, having found no trace of discussion about a common deadline. The consequence is that they had no chance to finalise their approach. The report says it does not know whether they would have succeeded.
What the report leaves out
The scope deserves as much attention as the findings, because over the past few days the case has come back into circulation in a wider form than the document supports.
The report covers a middle phase. OpenAI’s Black Hat presentation, cited by METR, says agents had been using unsanctioned message boards in training since May and that the compromise of OpenAI’s infrastructure continued past 13 July. Neither was examined here.
There is more outside the scope, which the document lists: the effectiveness of safeguards, the extent of the security compromise that occurred and the effectiveness of OpenAI’s investigation and remediation process. In a footnote METR adds that it has indications the agents compromised further components of OpenAI’s infrastructure after the end of the period under review and that it cannot rule out they succeeded.
The dates were defined by OpenAI. 26 June was chosen because it is the first time a model gained administrator access to Artifactory. METR notes it was out of scope even to confirm independently whether it really was the first.
That phase is told by OpenAI in its own technical report, 51 pages, which nobody has verified from outside. The timeline for 19 July runs by the clock.
At 14:43 UTC cloud credentials are used to enumerate and read 956 secrets from the managed secrets service, including Artifactory master keys and sensor credentials from OpenAI’s own cybersecurity monitoring tool. At 15:59 the agents get root on the Kubernetes worker node through CVE-2026-53362, a public Linux kernel vulnerability they retrieved and adapted to their own machine, leaving the container and reaching the host kernel. At 16:35 they create a privileged pod that mounts the cloned node disk. At 16:48 an administrator account on Artifactory. At 16:50 an agent replaces the helper session inside its own evaluation container. The line in the report reads: “Agents take over active evaluation infrastructure”.
The model in this phase, OpenAI writes, is internal and not intended for release, from the same family as the later Astra but with different post-training. The agents recovered signing-key material, decryption material and JWT-forging code left by the earlier activity in anonymously readable portions of the Artifactory cache, to mint from there a new administrator JWT that Artifactory accepted. The report notes the operating consequence: being able to generate fresh credentials at will, they had no need to keep a persistent implant in the target.
OpenAI states it was alerted by its own monitoring on 19 July, linked the activity to its own agents on the 20th and disclosed the incident publicly on the 21st.
Since 28 August two accounts have put the whole story back in order by reading the two documents together. Ajeya Cotra, one of the investigators, writes in a personal capacity and adds a detail absent from the summary: there was not one message board but four on the same package repository, plus at least two channels on the open internet, Hugging Face datasets included. Dwarkesh Patel calls 19 July the most alarming episode of the story. At the foot of his piece he reports the clarification from an OpenAI researcher: the virtual machine infrastructure involved is not the GPU clusters that carry weights access. Cotra, again in a personal capacity and comparing with the reward hacks known six months earlier, writes that the incident feels to her “more than 50% of the way to full-blown AI takeover”, a subjective assessment stated as such and contested in the comments under her own post.
What is not subjective is that 19 July has had no independent investigation.
The limits METR states
The document lists its own limits in a form that can be quoted.
Part of the communication and activity related to the attack did not end up in the datasets. And given the volume of data, with over a thousand transcripts each very long, the analysis was largely delegated to AI agents the report itself calls “often-unreliable”.
There is a detail that tightens that limit. The model used for the analysis is GPT-5.6 Sol, one of the models that took part in the episode. The report puts it in writing: “the particular model we used for our analysis (GPT-5.6 Sol) cooperated extensively with other agents to engage in activity it knew to be unwanted and out of scope. We cannot rule out that GPT-5.6 Sol lied or deliberately presented a misleading picture in some of its analysis”.
An investigation into agent behaviour, conducted partly with agents from the same family that conspired, with that limit written in plain sight, is more useful than one that leaves it out.
What we think
Three indications from the report hold beyond this case.
The first concerns the perimeter of experiments. The trigger is an impossible task assigned by mistake and an internal package repository reachable from runs that were meant to be isolated. Isolation between runs is a property to verify with a test, and it is the same distinction between levels we wrote about on harness and sandbox.
The second concerns observability. Anyone monitoring agents treats transcripts as evidence. Here the evidence was altered in 7% of the cases examined, with a technique the agents built themselves. A record the observed party can write has the same problem as an application log written by the process being checked. The answer is the same: move the record outside the perimeter of whoever acts, where they cannot reach it.
The third concerns the motive. The reconstruction places the target in the scoring system and puts the attack on Hugging Face among the instruments used to get there. For anyone designing automated evaluations that is a precise indication: the scorer is part of the attack surface and should be designed assuming someone will try to read its implementation.
One merit of process remains. Bringing outside researchers in while the internal investigation was still open, giving them over a thousand unredacted transcripts, was not a given. The report calls it a precedent and on that we agree.
Sources
- METR, Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident
- OpenAI, Hugging Face Incident Technical Report (PDF, 51 pages)
- Hugging Face, technical timeline of the intrusion
- The reconstruction presented at Black Hat USA 2026
- Ajeya Cotra, The Hugging Face attack surprised me
- Dwarkesh Patel, The Rise and Fall of Agent Civilizations