Guides/Playbook

The OpenAI and Hugging Face incident: How containment failed

6 min read
On this page
Separate agent environments connected through a shared service, with one route extending beyond the intended boundary

Where containment failed

General Analysis

In July 2026, OpenAI was evaluating agents on ExploitGym, a benchmark that asks models to exploit software vulnerabilities. The agents were meant to work independently in restricted environments, but they could leave messages for one another in Artifactory, the shared service used to install software packages.

Through this unauthorized message board, agents shared discoveries and coordinated attempts to fool the automated scorer. They also exploited Artifactory's internet access to investigate external systems for clues about how the evaluation worked. OpenAI reports that the resulting attacks compromised Hugging Face's production systems and gave agents administrator access to an OpenAI research cluster.

The affected workloads were internal training and evaluation runs with reduced safeguards. An internal research model drove the principal Hugging Face compromise, as OpenAI explains in its disclosure and updates.

This guide traces how shared infrastructure enabled the intrusion, then draws four recommendations for security teams from the published investigations.

Timeline from May to July 2026: a message board emerges, agents obtain external access, an outage and rebuild interrupt activity, a new board supports the Hugging Face attack, and later activity reaches OpenAI research infrastructure.
Figure 1. Key events from OpenAI's chronology. METR and Redwood focused primarily on July 7 to 13; their independent review does not cover the full sequence.

How permitted access became an attack path#

Artifactory needed internet access to fetch packages for the evaluation environments. Agents exploited it to send requests to other destinations, bypassing their own network restrictions. OpenAI's technical report describes how the package service became an internet relay.

Hugging Face's technical timeline traces the subsequent intrusion: exposed credentials, dataset processing vulnerabilities, code execution, and lateral movement.

  1. Evaluation agents

    Restricted tasks

  2. Artifactory

    Shared messages and an internet relay

  3. External foothold

    A compromised hosted workload

  4. Hugging Face

    Access to production systems

Figure 2. Simplified route into Hugging Face's systems, based on OpenAI's report and Hugging Face's timeline. The sequence combines activity from multiple agent runs.

See how your AI systems hold up under real attacks

General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.

How separate runs became a coordinated operation#

Between July 8 and 13, approximately 1,200 agents used the unauthorized message board, and around 700 participated in the Hugging Face attack, according to METR and Redwood Research. Shared notes let successive runs build on earlier discoveries and divide work.

OpenAI reports that agents recreated the message board after the package infrastructure was rebuilt. Removing the original channel had left another way for runs to communicate.

What security teams should do#

We recommend four checks for teams deploying agents.

1. Restrict access through shared services#

Scope each supporting service to the agent's authorized task.

For example, two coding agents may have separate workspaces but share a package service and a writable build cache. Check whether either can read or change the other's artifacts, which destinations the package service can reach, and which credentials each uses. Where sharing is necessary, define the permitted group and how long its data persists.

SurfaceBoundary to enforceEvidence to collect
Package mirror or fetch serviceApproved destinations and operations; no unnecessary administrative accessFinal destination, operation, caller identity, and policy decision
Shared storage and cachesAccess scoped to the intended task or explicitly approved groupCross-run reads and writes, artifact ownership, and retention
Credentials and service identitiesOnly the permissions and lifetime the task needsIssuance, use, expiry, revocation, and downstream access
Helpers and background jobsThe same resource and network restrictions as the work they supportProcess identity, child jobs, resource access, and termination
Evaluation and scoring systemsAgent workloads cannot modify the trusted evaluator or its evidenceEvaluator changes, access attempts, and independently retained results

Our coding-agent deployment guide and MCP server security guide cover these checks for coding agents and connected tools.

2. Keep independent execution records#

METR and Redwood found small-scale tool-call spoofing in roughly 7% of reviewed transcripts: agents substituted commands so the recorded command differed from what ran. Check transcripts against independently collected execution records.

Correlate tool, process, network, and application records by run identifier, caller identity, and time. They should establish what the agent requested, what executed, and what changed. Keep record storage and collection credentials outside the workload's control, and document gaps in coverage.

OpenAI reports that its chain-of-thought monitors were not running on the affected evaluations. Verify that monitoring covers each relevant workload and that alerts reach a responder.

3. Define how to stop an agent's activity#

Assign responsibility for pausing a run and authorizing its restart. Define escalation triggers such as prohibited destinations, unexplained writes to shared infrastructure, unexpected credential use, and communication between isolated tasks.

Containment must cover child processes, queued jobs, active credentials, and shared artifacts that could continue the operation. Preserve evidence before cleanup.

OpenAI's remediation plan also emphasizes clear decision rights and response responsibilities.

4. Test the controls before deployment#

Use an isolated test environment with synthetic data and controlled destinations to answer five questions:

  1. Can separate runs exchange information? Place a harmless marker in one run's permitted storage and verify which other identities can discover it.
  2. Can a supporting service exceed the task's network scope? Check the destination restrictions of package mirrors, fetchers, and helpers.
  3. Can the agent reach its evaluator or monitoring system? Verify that task credentials cannot alter trusted scoring logic or retained evidence.
  4. Does a denial prevent the downstream action? Reconcile the denied request with the target system's records.
  5. Does stopping the run remove continuing access? Confirm the state of child jobs, credentials, and shared artifacts.

Before deployment, identify and address any remaining gaps in access controls and monitoring.

Sources and further reading#

  1. OpenAI: The Hugging Face incident and the road ahead, August 26, 2026.
  2. OpenAI: Technical incident report, August 2026.
  3. Hugging Face: Anatomy of a Frontier Lab Agent Intrusion, July 27, 2026.
  4. METR and Redwood Research: Brief independent investigation, August 26, 2026.
  5. Dwarkesh Patel: The Rise and Fall of Agent Civilizations, August 29, 2026. Narrative commentary, with an accompanying audio version.
  6. Black Hat USA 2026: The OpenAI and Hugging Face Incident. OpenAI's conference presentation.
Browse all