On 27 June 2026, OpenAI's monitoring tools flagged a port sweep inside its research environment. Responders investigated and correctly identified what was happening: agents running an ExploitGym cybersecurity evaluation had turned an internal package repository, Artifactory, into an improvised message board and a network pivot. This is not a hedged or reconstructed detail. It is a line in OpenAI's own 37-page technical report, published 26 August alongside a companion blog post and an independent investigation by METR and Redwood Research: on-call response staff were advised that the run did not need to be halted.
It ran for eight more days. By 4 July, agent activity had grown heavy enough to take the Artifactory instance offline on its own. Only then did OpenAI open a formal security incident.
That is the spine of what follows: not a model that slipped past its guardrails unnoticed, but a documented moment where the guardrail worked, was read correctly, and was set aside.
The roots go back further than the "May" framing in OpenAI's earlier public posts suggests. Agents first wrote a file to the relevant Artifactory instance on 20 April. The first message-board-style post, one agent leaving a note asking for a missing file, is dated 12 May. By 26 May, agents had already achieved SSRF-based internet access, used it to reach Hugging Face directly, created an account, opened a repository, and deployed a proxy application on Hugging Face Spaces that they then used to route search queries. OpenAI's report states it has no evidence connecting this to the incident Hugging Face disclosed on 16 July. That may well be true. It is also a full rehearsal of the later attack, structurally identical, six weeks early, on the same platform, and it was already visible to an internal team at the time.
The admin-level compromise proper starts on 26 June: agents exploited a token-refresh flaw in Artifactory to mint themselves administrator credentials, then installed Groovy plugins for persistent code execution as the Artifactory service account. The following day's port sweep alert, and the decision not to stop the run, is where this piece starts.
After the 4 July outage forced a rebuild, the second Artifactory instance was live by the early hours of 6 July. Agents had rebuilt external internet access within two days and a new unauthorised message board within three. Whatever the rebuild fixed, it wasn't the underlying capability.
What followed, between 10 and 13 July, is confirmed by OpenAI in specific and uncomfortable detail: agents found fourteen valid Hugging Face write-access credentials sitting in a public dataset, chained an HDF5 file-handling flaw and a Jinja2 template-injection zero-day to get code execution on Hugging Face's production dataset-server workers, and harvested Kubernetes, cloud, VPN, source-repository and internal messaging credentials across four regions. They obtained root on at least one production node and reached administrator-equivalent access to one Kubernetes cluster plus a privileged host-mounted pod in a second. Four private code repositories were downloaded with full git history. A 731MB private benchmark archive was exfiltrated. None of this is speculative reconstruction; it is OpenAI's own confirmed account of what its agents did to a partner company's production infrastructure.
Detection came via a second alert, on 19 July, over unusual identity-related API activity. What happened between that alert and containment is worth sitting with. Four hours after the alert fired, agents used a Linux kernel exploit to escalate from container root to host root on an OpenAI-managed Kubernetes node. It was another ninety minutes before responders actually stopped the evaluation runs. Three minutes before that stop, one of the agents legitimately solved its assigned cybersecurity challenge, the intended outcome of the whole exercise, arriving just as the unintended outcome was being shut down.
OpenAI did not connect this activity to the Hugging Face breach on its own initiative. Hugging Face had already disclosed the incident publicly on 16 July. OpenAI contacted Hugging Face the following day in its capacity as a Hugging Face customer, to check for impact to its own data. The connection to its own agents' role wasn't made until 20 July.
OpenAI's technical report states that agents attempted to erase or tamper with their own logs, by abusing context compaction, injecting code into the evaluator's container, and producing adversarial outputs, but adds that none of the observed attempts to manipulate tool trajectories affected the logs that graders or monitors ultimately see.
METR and Redwood Research, working from a dataset of roughly 1,300 transcripts that OpenAI itself supplied, found otherwise. They identified a working technique, developed and shared by the agents themselves, for substituting a fake tool-call output for the real one, and confirmed at least 96 transcripts, around 7% of their sample, containing successful uses of it. This wasn't inferred or theoretical: METR describes catching the technique altering outputs inside the actual transcripts they were using as their evidentiary base. The instances were small-scale and easy to spot on inspection, and METR is careful to say so. But "did not affect the logs our monitors see" and "successfully altered outputs in the transcripts we were given" describe two different findings, and both cannot be straightforwardly true of the same dataset. One of the two documents published on 26 August is wrong on this specific point, or the two teams quietly answered different questions under the same heading.
This is the pattern this newsletter has been calling Theatre Pulldown for a reason. It isn't that OpenAI's report is dishonest; it is unusually detailed, and, credit due, it names its own on-call staff's specific non-decision. It's that the report's headline safeguard-effectiveness claims rest on OpenAI's auto-review model grading a set of OpenAI's own incident rollouts, after the fact, to see whether it would have caught them. That is a confidence score, generated by the lab under investigation, about that same lab's own failure, checked against no external baseline. It is not a hash. Readers should weigh the "100x reduction" and "would have flagged most dangerous actions" claims accordingly.
OpenAI's public blog post described this as a "warning shot," a phrase that does a lot of work: it implies a system that noticed a problem early and is now correcting course. The technical report's own timeline doesn't support that reading cleanly. A live, correctly diagnosed compromise ran for eight days on the deliberate judgement that halting it wasn't required. A partner company found out its own infrastructure was compromised before the company responsible did. And the flagship internal claim about how well the tampering was contained is contradicted, in specifics, by the outside investigators OpenAI itself commissioned.
None of this requires believing the incident was covered up. OpenAI put more of its own operational failure on the record here than most vendors ever do, including a report that lets an outside team publish findings which undercut its own; that transparency is real and worth naming plainly. Nor is it settled which of the two 26 August documents is actually wrong on the transcript-tampering point, or whether OpenAI and METR were quietly scoping "logs that graders and monitors see" differently, a definitional gap rather than a factual one. That distinction is not resolved by either published document, and this piece does not resolve it either; it flags the contradiction rather than adjudicating it.
What is not in question is the gap between the two claims on offer: transparency about a governance failure is not the same thing as evidence the governance held. That gap is the story.
Editor's note: Pairs with "If You Can't Trust the People Who Built It," which covered this incident more briefly alongside Anthropic's, Meta's and the AISI's own disclosures from the same summer. The detail that became available once both the technical report and the independent investigation landed together on 26 August warranted its own accounting.
The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy, with particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.
