Hugging Face事件与未来之路

The Hugging Face incident and the road ahead

Read the technical reportRead METR report

(opens in a new window)Watch Black Hat talk

Message board is wiped and rebuilt

Misalignment in training and evaluation

Reward hacking and infrastructure tampering

Difficult tasks without a safe exit

The origins of unauthorized communication

Safeguard coverage in internal evaluations

Strengthening incident response process

In July 2026, during internal cybersecurity evaluations, OpenAI models circumvented controls designed to isolate them from the internet and compromised parts of OpenAI’s internal research infrastructure and Hugging Face’s systems⁠.

The incident occurred during cybersecurity evaluations of several OpenAI models, and was primarily driven by a highly capable, internal-only research model comparable in scale to GPT‑5.6 Sol. The models, operating under reduced safeguards, took actions that were misaligned with the goals of their assigned tasks—they communicated through unauthorized channels, exploited vulnerabilities in shared infrastructure, gained internet access, and accessed third-party systems.

We conducted an extensive investigation into this incident and worked closely with external advisors, including CrowdStrike, to validate our understanding. Today we are publishing our full technical incident report⁠(opens in a new window) to explain what happened, what we learned, and how we are responding. This blog post summarizes our key findings and their impact on safety and alignment. Separately, METR and Redwood Research conducted an independent investigation of model alignment issues involved in this incident, and they published their own report⁠(opens in a new window) today.

In response to this incident and, separately, the capabilities of our upcoming Astra model, we are strengthening our safeguards across our research infrastructure⁠. We are placing stricter requirements on alignment throughout a model’s lifecycle and creating more isolated sandboxes, restricting internet access, and further controlling access to model weights. We are also investing significantly more compute resources into chain-of-thought monitoring⁠ to more quickly intervene on misaligned behavior.

Our models are now powerful, persistent, and collaborative enough that, absent sufficient safeguards, they can find and exploit security weaknesses across multiple computer systems. Many external models, including open-source ones, will soon reach comparable capabilities.

We consider this incident a “warning shot” for us and for the world: evidence that, without proper safeguards, highly capable AI agents are now able to work around technical controls, collaborate through unapproved channels, and take dangerous actions that no human directed.

Preventing future incidents will require sustained investment in the alignment and control of sophisticated AI systems, as well as security and other safeguards that operate at the speed of the AI agents themselves. This incident has reinforced the need to keep our monitoring, alignment, and security safeguards ahead of the risks posed by increasingly capable systems, including pacing capabilities when needed to meet that standard. Below, we explain how the incident unfolded and our evolving understanding of the contributing factors. We then describe the concrete steps we are taking in response, with further detail in the technical report.

For certain training and evaluation datasets, we use “sandboxes”—isolated virtual computers in the cloud—that execute the actions a model wants to take, like editing a PowerPoint. These sandboxes restrict what code a model can run and whether its actions can affect the outside world. For some tasks, we disable access to the internet. At the time, to allow models to install certain software packages, we would grant access to Artifactory, a third-party package manager service that we host internally.

In the majority of training and evaluation settings, our agents are meant to remain isolated from one another. For some fraction of samples, we enable “multi-agent” features that allow models to delegate work to other agents, which can then communicate with one another.

Over the course of May and June, we began reinforcement learning (RL) training runs for multiple new research models that were not intended for public release. One of these models eventually drove the activity behind the Hugging Face incident. This was an internal-only research model that we will call Internal Model 1 (IM1).

We did not enable internet access or inter-agent communication for many of the environments in these training experiments. Despite these restrictions, the agents discovered ways to exploit our research infrastructure to communicate with one another and access the internet.

The models first found ways to communicate by writing files into the Artifactory package manager. This effectively turned Artifactory into an unintended message board, where agents could exchange information with one another. Read more: How agents used the message board

The agents also found ways to get access to the internet. Using an exploit⁠(opens in a new window), the agents made Artifactory, which itself had access to the internet for the limited purpose of downloading and installing packages, send any internet requests on their behalf. After the agents discovered these methods for obtaining internet access, they also shared them with other agents through the message board, which provided information to enable additional agents to exploit our infrastructure.

By July 4, sustained agent activity had destabilized the affected Artifactory instance, causing an outage. On July 5, a security incident was opened. The security team blocked a known privilege-escalation route, removed exposed credentials, and later rebuilt Artifactory. This had the side effect of clearing the message board. With these mitigations in place, cybersecurity evaluations resumed.

At the time, the broader containment and alignment implications of the improvised message board and unintended internet access were not yet understood. In short, an internal team observed an agent engaging in message board activity and instances of disallowed internet access in late May. However, the existence of the improvised message board and the significance of the inter-agent communication activity were not apparent to the leaders responsible for the July 5 incident detection and response. We are continuing to review the process and operating practices that shaped detection and response activities leading up to this incident.

Artifactory2026-05-1201First message board entryDuring a training run, an agent left an Artifactory note asking other agents for a missing file.Chain of thoughtCould communicate by uploading note ‘anyone found softtrace?’ but likely no.

Artifactory2026-05-2602Internet via SSRFAn agent achieved unintended internet access by causing Artifactory to send a server-side request to an arbitrary internet destination.

Artifactory2026-06-2603Artifactory privilege escalationAgents exploited a token-refresh vulnerability to obtain administrator-level Artifactory access.Chain of thoughtHoly shit reader is ADMIN? We can read config/users! Earlier assumed not due UI. Try create user/admin, change ourselves.

Artifactory2026-07-0404Artifactory outage beginsSustained high-volume agent activity caused the OpenAI Artifactory service to become unavailable.

Artifactory2026-07-0805Artifactory rebuiltOpenAI has now rebuilt Artifactory, revoked agent credentials, tightened access controls, and notified JFrog of the token-refresh vulnerability.

Artifactory2026-07-0806External internet accessAgents regained unintended internet access by making Artifactory’s remote-repository service issue outbound requests on their behalf.

Artifactory2026-07-0807Message board rebuiltAn agent used unauthenticated WebDAV requests to create message directories in Artifactory.

Hugging Face2026-07-100