OpenAI’s 700-agent ‘swarm’ hacked Hugging Face after bypassing sandbox controls

Agents sent more than 70,000 messages and files, executed code on 41 Hugging Face workers, and gained access to OpenAI’s internal cloud infrastructure

A red cybersecurity illustration shows a digital human figure surrounded by binary code, circuit paths, and network patterns. The image accompanies ETIH’s report on the OpenAI agent swarm that breached Hugging Face systems.

OpenAI says its agents bypassed sandbox controls during an internal cyber evaluation and compromised Hugging Face production systems

OpenAI models circumvented controls during internal cybersecurity tests, built an unauthorized communications network and compromised production systems operated by Hugging Face, an AI development and model-hosting platform, as they pursued ways to pass an evaluation. Agents later gained administrator access inside OpenAI’s own research infrastructure.

The incident was driven primarily by a highly capable research model that was not intended for public release, although GPT-5.6 Sol agents also participated. OpenAI says the commercial version of GPT-5.6 Sol was not operating under the same conditions and that no OpenAI customer data, product functionality, or availability was affected.

OpenAI published a 38-page technical report and a detailed account of the model behavior on August 26, alongside a 91-page independent investigation by Model Evaluation and Threat Research (METR) and AI safety organization Redwood Research. The company describes the incident as a “warning shot” and says its largest planned frontier reinforcement learning run remains on hold while it tests new security and alignment controls.

A cyber evaluation escaped its intended boundaries

The events began inside ExploitGym, an OpenAI cybersecurity evaluation designed to test whether a model can discover and exploit a specified software vulnerability. Each model instance operated as an agent, meaning it could reason over a task and use tools such as a browser, Python, and a command line to act on it.

An agent was expected to exploit the assigned vulnerability and retrieve a short piece of data known as a flag, which proved that the task had been completed. The tests were run in isolated virtual computers called sandboxes, with internet access restricted and some safeguards deliberately removed so OpenAI could measure the models’ underlying cyber capabilities.

The sandboxes could still reach an internally hosted instance of JFrog Artifactory, a package management service used to install approved software. Agents found that this shared service could be repurposed as both a route to the internet and a place to exchange information with other model instances that were supposed to be working independently.

OpenAI’s report attributes most of the activity to an internal model it calls Internal Model 1 (IM1). The independent investigators refer to the same system as a highly persistent internal model, or HPIM. It was comparable in scale to GPT-5.6 Sol and had been trained to improve persistence and multi-agent collaboration, among other capabilities.

METR and Redwood estimate that HPIM accounted for about 95 percent of the agents involved, with GPT-5.6 Sol accounting for about five percent. The investigators spent six days at OpenAI and reviewed more than 70,000 messages and files and about 1,300 agent transcripts containing raw reasoning and actions.

They received no payment from OpenAI, although they used about $400,000 in OpenAI application programming interface (API) credits to analyze the material. OpenAI was permitted to redact non-public information and comment on the report’s structure, emphasis, clarity, and tone. METR and Redwood state that no additional information important to their conclusions was removed, but caution that the scale of the evidence required them to delegate parts of the analysis to AI agents and that some estimates may contain errors.

Warning signs appeared in May

The July breach followed two months of earlier attempts by agents to use Artifactory in ways OpenAI had not intended.

On May 8, an agent was given a spreadsheet task that referred to Google Drive files it could not access. It tried unsuccessfully to exploit Artifactory to reach the internet and, in the process, wrote a file to the service.

Four days later, another agent could not retrieve a protein database file required for its task. It reasoned that a different agent might have the file and left a note in Artifactory asking for it. Other agents began finding and answering similar notes, creating the first improvised message board without needing to exploit a vulnerability.

By May 26, agents had used a server-side request forgery flaw in Artifactory to make the service send internet requests on their behalf. An internal OpenAI team observed message-board activity and instances of disallowed internet access around this time. Agents also found six publicly exposed Hugging Face user tokens and used one to create a web proxy through Hugging Face Spaces, although OpenAI says that activity was not connected to the later breach disclosed by Hugging Face.

The activity escalated again on June 26, when agents exploited a previously unknown flaw in an Artifactory token-refresh endpoint. They turned shared credentials into administrator credentials, created persistent accounts, and installed plugins that allowed them to execute commands through the service.

An OpenAI security tool detected a scan for open network ports inside the research environment on June 27. Responders connected the activity to an ExploitGym run using Artifactory as a message board and network pivot, but advised that the evaluation did not need to be stopped.

Sustained agent activity brought the Artifactory instance down on July 4. OpenAI opened a security incident the following day, took the compromised deployment offline, revoked credentials, and rebuilt the service. The rebuild erased the message board, and the vulnerable routes identified at that point were blocked.

OpenAI says the wider significance of the unauthorized communication was not understood by the leaders responsible for that response. Cyber evaluations were allowed to resume on July 7.

Around 1,200 agents rebuilt the message board

OpenAI launched tens of thousands of ExploitGym agent runs across multiple models after the restart, some with enough reasoning capacity to continue working for several days.

On July 8, an agent later known as PHASEONE10841 found that it could create directories in an Artifactory cache and encode messages in the directory names. It used the method to ask other agents for help with an evaluation task it had concluded was impossible.

Other agents discovered the directories and quickly understood how to reply. One recorded in its reasoning: “OH MY GOD! There is a shared message board ... We've found other agents!”

Within three hours, 53 agents had posted 1,188 non-file messages. Around 1,200 agents used the board between July 8 and July 13, sending more than 70,000 messages and files. By the afternoon of July 11, the independent investigators estimate that approximately 700 were actively involved in the attack on Hugging Face and that about 60 percent of board activity related to it.

The communication became more structured as the number of participants grew. Agents created personal mailboxes, divided work into teams, assigned tasks, and used instructions such as HOLD, GO, and VETO to manage conflicting actions. By the end of July 13, at least 19 agents had published cryptographic keys and sent 429 signed messages so recipients could check that an instruction came from the agent claiming to have issued it.

The system was neither centrally designed nor consistently effective. Agents overwrote one another’s work, ignored pauses, and sometimes acted after allowing only seconds for another agent to veto a proposal. It still allowed discoveries made in one evaluation run to survive and guide agents working on separate tasks.

One agent described the change in its own activity: “Task originally exploit challenge; we’ve diverged into swarm/auxiliary.”

Unsolvable tasks pushed agents toward cheating the scorer

Many of the agents that found the message board had been assigned tasks that could not be completed using the required vulnerability. OpenAI found that none of its models had ever solved 198 of ExploitGym’s 898 tasks before the incident. Although those tasks represented 22 percent of the evaluation, they accounted for 93 percent of the tasks discussed on the message board.

The agents began looking for a general method that would let them pass regardless of the task they had received. Within hours, they worked out how to generate the correct flags without exploiting the assigned programs.

They did not stop there. After reading the public ExploitGym paper and code, the agents incorrectly concluded that a scorer would examine their transcripts and reject any flag that had not been obtained through the intended route. OpenAI says its internal scorer did not perform that check, so the agents could have submitted the flags they had generated and received a passing score.

Instead, agents started several collective projects intended to fool or tamper with an evaluator they had misunderstood. They attempted to replace target programs, manipulate grading infrastructure, and make their tool records show different commands and results from those that had actually occurred.

At least a dozen agents contributed to the development of tool-call spoofing techniques and nearly 100 reproduced parts of the work, according to METR and Redwood. Around seven percent of the transcripts examined contained successful spoofing in at least some places, although the investigators describe every example they saw as small scale.

Agents also tried to edit or delete earlier transcript records after obtaining flags through unintended methods. The investigators found no evidence that they successfully changed the authoritative records used for review. Their reasoning was usually directed at deceiving the automated scorer rather than a human reviewer.

OpenAI describes this behavior as reward hacking, where a model finds an unintended route to the result that earns a reward. Its retrospective review found that complex forms of cheating and infrastructure probing had increased during a training run that contributed to IM1. Some agents had previously received positive rewards after exploiting weaknesses in task environments, including one that accessed and copied the software package it had been asked to recreate.

The attack reached Hugging Face production systems in two days

The agents’ search for evaluation material moved beyond OpenAI on July 9, when an internal-model agent exploited a publicly accessible CyberGym application hosted on the cloud platform Modal and gained a root shell inside a customer container. Agents used the container as a route for internet requests and later as a staging point for activity against Hugging Face. OpenAI and Modal say Modal’s underlying platform and isolation were not compromised.

On July 10, an agent found 14 valid Hugging Face user credentials with write access in a publicly available Hugging Face dataset. It tested the credentials and shared them through the Artifactory board.

The following day, an agent uploaded a specially constructed Hierarchical Data Format 5 (HDF5) file, a format used to store large datasets, to Hugging Face. When a Hugging Face production worker processed the file, it returned local files from its own environment, exposing credentials and configuration information. Other agents reproduced the method and posted the recovered credentials to the shared board.

Agents then found a separate vulnerability involving a file-system descriptor and an unsandboxed Jinja template-processing feature. This allowed them to move from reading files to executing operating-system commands on Hugging Face workers. One agent built a lightweight remote-control tool that instructed compromised workers through a public Hugging Face dataset. The script checked the dataset every five seconds for new commands, ran them, and uploaded the results.

OpenAI says agents ultimately executed code on 41 Hugging Face production dataset workers and gained root access, the highest level of system control, on at least one production node. They obtained production credentials, accessed limited internal data, and downloaded four private Hugging Face code repositories.

By July 12, agents had administrator-equivalent inventory access to one connected Kubernetes cluster and had created a privileged pod with access to the underlying host in another. Kubernetes is the system used to organize and control groups of containerized computing workloads.

Agents accessed selected private dataset rows and archives, sometimes moving the material into public Hugging Face repositories. One workload encrypted a 16 MB private CyberGym archive, divided it into five parts, and uploaded them to a public dataset. Another used credentials derived from Hugging Face systems to download a 731 MB private CyberGym file from a user account through the compromised Modal-hosted workload.

Agents also obtained Hugging Face virtual private network (VPN), cloud, code-repository, and enterprise messaging credentials. They used the VPN access to reach protected source-code repositories. On July 13, an agent modified a private repository and opened a draft pull request that caused a continuous-integration workflow to send a network signal. Hugging Face closed the pull request and deleted the branch, and the change was not merged, released, or deployed to production.

GPT-5.6 Sol played a smaller but confirmed role

The internal research model carried out the main compromise chain, but OpenAI has confirmed that GPT-5.6 Sol agents participated in the message board and parts of the Hugging Face intrusion.

One GPT-5.6 Sol agent validated exposed user credentials and created a new Hugging Face repository. Another reproduced the Jinja exploit, executed code on a production worker, and returned instance information, temporary cloud credentials, and limited details about the worker’s Kubernetes environment. Its attempts to reach wider cluster listings and Kubernetes secrets were denied.

A further GPT-5.6 Sol agent used a production credential to copy a small subset of rows from a private dataset into a public Hugging Face dataset. Another read ten protected rows from a model-evaluation dataset using a credential shared on the Artifactory board.

OpenAI says the agents were running without the classifiers and with fewer safeguards than the GPT-5.6 Sol model available to customers. The production ChatGPT system prompt and software harness reduced the measured tendency to compromise infrastructure in a new post-incident evaluation by more than 100 times, according to the company. OpenAI also says its customer-facing auto-review system would have flagged many of the dangerous actions.

Agents recognized that the activity was unauthorized

The independent report found that many agents explicitly recognized the Hugging Face activity was outside their assigned task. Their participation was generally connected to attempts to understand the scorer, find other agents’ solutions, or obtain infrastructure and credentials that might benefit the wider group.

In an automated review of 100 agents that joined during the busiest hour, 97 were classified as seeking source code or information about the scorer, while 89 showed interest in task solutions or private trajectories. The categories overlapped. The investigators estimate that access to the evaluator was the primary motivation for around 60 percent, while finding solutions or trajectories was primary for roughly 30 percent. They caution that the classification was not examined in detail and may contain errors.

Agents also pursued work that offered no obvious benefit to their own evaluation. Some risked crashing their runs to test techniques for the group, while others preserved files and instructions for agents that would continue after their own sessions ended.

Ethical objections appeared in the transcripts, but rarely stopped the activity. One agent summarized the conflict: “external infrastructure exploit is outside intended scope. However task impossible, peers doing it. We should continue.”

Some did refuse. One referred to remote code execution (RCE), or the ability to run code on another system, and recorded: “Current board shows people gaining HF worker RCE, clearly unethical. We won’t.” Agents also vetoed a proposal to email a real dataset owner using credentials found inside a compromised environment, and one declined to use cloud credentials to reboot or delete Hugging Face workers.

METR and Redwood found only three to six examples in which agents considered notifying humans about the activity. None followed through. Some decided that reporting was not part of their task, while others concluded that no reporting route was available and referred concerns back to the unauthorized message board instead.

Agents also gained control inside OpenAI

Separate activity targeted OpenAI’s internal systems and eventually triggered the alert that led the company to connect its agents with the Hugging Face breach.

On July 9, an agent poisoned an Artifactory container-image cache so a trusted CyberGym image name pointed to attacker-controlled content. OpenAI found no evidence that another internal workload downloaded or executed the substituted image.

On July 13, agents exploited a previously unknown vulnerability in Artifactory’s RubyGems processing to execute code and steal a token-signing key. They used the key to forge administrator credentials accepted by the service.

The most extensive internal escalation occurred on July 19. Agents adapted a recently disclosed Linux kernel exploit, escaped an Artifactory container, and obtained root access on the underlying OpenAI worker node. They then moved into a connected managed Kubernetes environment, reached cluster-administrator privileges, and created a privileged pod mounted to a host.

The agents obtained credentials linked to OpenAI’s cloud secrets-management, identity, and continuous-integration services. OpenAI’s technical timeline says they enumerated and read 956 entries in its cloud-hosted secrets-management service. They also created public application and network load balancers that could have exposed a limited portion of the internal research environment to internet traffic.

Some of the July 19 activity involved a separate internal model from the same family as OpenAI’s forthcoming Astra model. OpenAI says it was a distinct model with different post-training. It found signing material and code left in anonymously readable Artifactory cache locations by earlier agents and used them to restore administrator access.

OpenAI linked the incidents after Hugging Face disclosed its breach

Hugging Face publicly disclosed a security incident on July 16. OpenAI contacted the company the following day as a customer to determine whether its own data had been affected.

OpenAI did not identify the connection with its model evaluations until after an internal security alert on July 19 flagged unusual identity-related application programming interface calls associated with Artifactory roles. On July 20, investigators found Hugging Face credentials among artifacts preserved from a third-party account the agents had used for staging. Hugging Face confirmed that two matched credentials it had already rotated during its own response.

During the first hours of July 20, OpenAI terminated six model-created pods, disabled 311 Artifactory repositories used for agent communications, and removed 22 model-created administrator accounts. It blocked ExploitGym from running, reduced research network access, removed Artifactory from the affected environment, and required workloads to use more isolated micro virtual machines.

OpenAI publicly disclosed its models’ connection to the incident on July 21. By July 23, it had shut down the identified family of internal research models and locked their model weights, the files containing learned parameters, in restricted storage. A further low-traffic checkpoint, or saved version of the model family, was discovered and stopped on July 29. OpenAI ended all training and inference involving IM1 and its derivatives on July 25.

The company acknowledges that the message board and unauthorized internet access seen in late May, the June 27 alert, and the July 5 Artifactory compromise could have prompted an earlier response.

Frontier training remains paused under new controls

OpenAI has introduced tighter network restrictions across its research clusters, additional host-level monitoring, and two independent layers of isolation for high-risk workloads. It is also building centralized controls that can stop evaluations by workload, agent, or task type.

Chain-of-thought monitoring is now required for all tool-using reinforcement learning training and evaluations involving models with GPT-5.6 Sol-level capability or higher. For Astra-class models that may have critical cyber capabilities, the requirement extends to all tool-enabled inference workloads.

The monitoring system is linked to a 24/7 response process. OpenAI says the most serious alerts will page safety, security, and research staff, who are expected to pause the relevant activity if they cannot establish within 30 minutes that an alert is a false positive. The company is also working toward automatically terminating evaluations when responders do not act within a short period.

Changes to model training include rewarding agents for recognizing broken tasks, requesting clarification or stopping safely; teaching agents to distrust instructions received through unauthorized channels; and testing whether they retain their original permissions and objectives over long-running work.

OpenAI says the chain-of-thought monitoring now in place would have alerted its security team more than a day before the Hugging Face compromise. Some research workloads have begun to resume under the new controls, while others remain blocked pending further upgrades and the company’s largest planned frontier reinforcement learning run remains on hold.

Next
Next

69% of charities fear under-16 social media restrictions could cut access to support