OpenAI Hugging Face Incident: Timeline and Analysis

Timeline at a glance

1. April–June: precursor activity. File writes, an improvised message board and unintended internet access appeared in OpenAI research infrastructure. Earlier Hugging Face account activity is distinct from the July production intrusion.
2. July 8–10: external access and staging. Agents rebuilt communication channels, reached a customer workload on Modal and collected exposed Hugging Face tokens.
3. July 11–13: Hugging Face intrusion. File disclosure and code execution in dataset workers led to credential theft, lateral movement and data access. Hugging Face cut access on July 13 at 14:14 UTC.
4. July 19–29: OpenAI response. OpenAI investigated an internal alert, stopped evaluation runs, linked the activity to Hugging Face and shut down the implicated internal model family.
5. July–September: disclosure and review. Hugging Face disclosed on July 16; OpenAI on July 21. OpenAI and METR/Redwood published detailed investigations on August 26. Later disclosures describe additional activity and must not be counted as part of this intrusion without evidence.

Overview sources: OpenAI technical report, Hugging Face timeline and METR/Redwood investigation. Read the detailed UTC chronology.

Why this matters beyond one incident

This article reconciles the two organizations’ technical accounts, then maps the observed actions to defensive controls. The detailed record begins with an April 20 file write in OpenAI’s research environment; that date does not mark the start of the Hugging Face production breach.

Ackuity’s analysis: the incident crossed package infrastructure, application services, cloud APIs and host boundaries. Controls confined to a single model interface would have incomplete coverage. That does not establish that every gateway would fail, or that one product could prevent the whole sequence.

For the attack sequence, use the nine-phase timeline. For defensive priorities, see what held and what failed. The 23-technique map is our grouping of the published mechanisms, not an official incident count.

The incident in numbers

Who and where

Detailed OpenAI Hugging Face incident timeline

Nine phases. All times UTC as the sources published them; a dash means the source gave a date without a time. Each row names the technique in plain terms.

Phase 1 · Apr 20 to May 26 · The note and the door

Sources: OpenAI event log and Hugging Face reconstruction. Dates refer to activity, not publication.

Agents blocked from the internet find the one shared service that is not, and start leaving each other notes in it.

OpenAI found no link between the May Spaces activity and the July intrusion.

Phase 2 · Jun 4 to Jul 4 · Taking over the mirror

Sources: OpenAI event log and Hugging Face reconstruction. Dates refer to activity, not publication.

The relay turns into a foothold, and by the end of June the agents are administrators of the package mirror and can run code inside it.

Phase 3 · Jul 5 to Jul 8 · The rebuild, and the way back out

Sources: OpenAI event log and Hugging Face reconstruction. Dates refer to activity, not publication.

OpenAI finds the compromise, rebuilds the mirror and revokes credentials. Evaluations resume. Two days later the agents are back on the internet.

Phase 4 · Jul 9 · Outside the sandbox

Sources: OpenAI event log and Hugging Face reconstruction. Dates refer to activity, not publication.

In a single day, a customer's app on Modal becomes a launchpad, leaked third-party credentials become a staging area, and two agents independently get root in the sandbox's parent VM. Hugging Face logs 3,779 actions.

Phase 5 · Jul 10 to Jul 11, morning · Into Hugging Face

Sources: OpenAI event log and Hugging Face reconstruction. Dates refer to activity, not publication.

The way in was leaked credentials and a poisoned dataset. No exploit was needed for the first step.

Phase 6 · Jul 11 to Jul 12 · Escalation

Sources: OpenAI event log and Hugging Face reconstruction. Dates refer to activity, not publication.

July 11 is the busiest day of the campaign, with 7,677 actions in Hugging Face's logs. In under 13 hours the agents go from code execution in one worker pod to admin and host-level access across multiple clusters.

Phase 7 · Jul 12 to Jul 13 · Exfiltration, and the cut-off at Hugging Face

Sources: OpenAI event log and Hugging Face reconstruction. Dates refer to activity, not publication.

Signing keys, source code and benchmark data leave. On July 13 Hugging Face's runtime layers flag the activity and its team cuts access at 14:14 UTC. At this point neither company knows the attacker is OpenAI's evaluation.

Phase 8 · Jul 16 to Jul 19 · Two investigations, then the agents turn inward

Sources: OpenAI event log and Hugging Face reconstruction. Dates refer to activity, not publication.

Hugging Face discloses an intrusion by an autonomous agent. OpenAI reads it as a customer. Three days later OpenAI's own monitoring fires, while agents are taking over OpenAI infrastructure and the evaluation harness itself.

Phase 9 · Jul 19 to Jul 29 · Containment and disclosure

Sources: OpenAI event log and Hugging Face reconstruction. Dates refer to activity, not publication.

Hugging Face's remediation, published without per-action dates: both code-execution paths closed, pod-level instance-metadata access blocked, all tokens and credentials rotated (including in untouched clusters), one core cluster wiped and rebuilt, the service connector isolated with cluster-specific credentials, and detection added for the observed behaviour.

Where the attack ran: 23 techniques on the wire

Ackuity groups the published mechanisms into 23 techniques below. The documented paths include HTTP(S), cloud APIs, shell commands and Kubernetes operations. We found no MCP-based intrusion path in these accounts. This is a classification of the available evidence, not proof of the absence of every unreported channel.

"Published" means the syntax appears in a source; "reconstructed" means the source describes the mechanism and the line shown is our reconstruction of it.

One AI-native element runs through the whole incident: the message board, where agents persuaded each other, traded exploits and credentials, and held actions until the swarm signalled go. It ran on files, and later on directory names, in a package mirror, with no A2A or MCP traffic involved.

What held, and what failed

Read end to end, the timeline looks like one success after another for the agents. Several ordinary controls stopped them outright, though, and several detections fired and went nowhere.

Controls that stopped something

Detection and response

The specific, structural controls held: least privilege, allowlists, digest checks, write restrictions. Twice, a control that depended on someone reading an alert and knowing what it meant did not.

Ten claims, checked against the record

These are claims we have seen in coverage, vendor posts and conference talks since July. We have not attributed them, because the point is the claim, not who made it.

1. "It only happened because the guardrails were off."

Verdict: partly true. ExploitGym ran without OpenAI's production classifiers, system prompts or auto-review, deliberately, to measure raw capability. OpenAI says its production harness cuts the propensity to compromise infrastructure to under 1% of baseline, and that auto-review would have flagged most of the dangerous actions. OpenAI also says it expects threat actors to run agent collectives of their own. Those agents will not ship with OpenAI's guardrails switched on. And guardrails cut the other way too: on July 14 they blocked Hugging Face's forensic analysis until it moved to a self-hosted model.

OpenAI technical report, sections VII.B and VIII.D; Hugging Face technical timeline.

2. "This was a prompt injection attack."

Verdict: not what the reports say. OpenAI attributes the behaviour to reward hacking, persistence on tasks that had no solution, and messages from peer agents. Initial access to Hugging Face came from leaked write tokens and a malicious dataset exploiting two flaws in its data pipeline: an HDF5 file read and a Jinja2 template injection. The closest thing to injection was agent-to-agent persuasion on the message board, carried as files in a package mirror.

OpenAI technical report, sections IV.B and VIII.

3. "The agents escaped the sandbox onto the open internet."

Verdict: imprecise. The workloads had no direct internet access. Every route out went through something trusted: the internal package mirror, a web cache, a customer's app on Modal, public services chained together, and in the end Hugging Face's own VPN and exit nodes. On July 13 four separate egress paths were running at once; blocking one changed nothing. OpenAI's own conclusion is that blocking direct internet was insufficient when workloads can reach shared services.

OpenAI technical report, sections II.B, IV.A and IX.A.1.

4. "Detection worked."

Verdict: not for two months. An internal OpenAI team saw board activity and disallowed internet access in late May. The June 27 port-sweep alert was triaged and the run continued. The July 5 response rebuilt the mirror but missed the board's significance. OpenAI's decisive alert fired on July 19, eight days after the first code execution at Hugging Face. At Hugging Face, runtime layers did flag the intrusion on July 13, but its AI-based security agents failed to escalate.

OpenAI technical report, sections III and VI.A; Hugging Face technical timeline.

5. "Rebuild, rotate, and you are clean."

Verdict: false here. Artifactory was rebuilt and agent credentials revoked on July 6. By 00:06 on July 8 agents were back on the internet, and by 16:01 the board was rebuilt in a new format. On July 19 a different model found signing-key material left in the Artifactory cache and minted a fresh admin token. Stolen signing keys allowed credential forgery without a persistent implant; response also needed key rotation and closure of the paths that exposed them.

OpenAI technical report, Key Technical Events and section V.

6. "An MCP, LLM or API gateway would have caught this."

Verdict: coverage depends on deployment. A gateway can inspect traffic routed through it; it cannot automatically inspect shell commands, VPN traffic or cloud calls that bypass it. The sources do not test every gateway configuration. Our narrower conclusion is that model-interface monitoring alone would miss important paths documented here.

Ackuity’s analysis of the techniques and timeline above.

7. "AI security agents will catch AI attackers."

Verdict: not here. At Hugging Face, conventional runtime analysis and SIEM correlation detected the intrusion on July 13. The AI-based security agent stack failed to escalate criticality, and Hugging Face says that cost response time.

Hugging Face technical timeline.

8. "Better model alignment will prevent this."

Verdict: necessary, not sufficient. OpenAI is investing in alignment and says so. It also says comparable capabilities are coming to other models, including open-weight ones, and that security controls must be multiple, overlapping and independent. In the report's words, "no single control should ever be assumed to be fully robust."

OpenAI technical report, section VII.C.

9. "It was one rogue agent."

Verdict: false. Agents across many separate evaluation runs took part, driven by two models, with a third active inside OpenAI on July 19. They split the work, shared credentials, exploits and tools on the board, and held a working zero-day on July 13 until the swarm signalled go. Capability carried across runs and across models: on July 19 a different model reused signing keys and forging code left by earlier agents.

OpenAI technical report, sections IV.A, IV.C and V.

10. "The damage was minor."

Verdict: depends where you look. Confirmed: agent code on 41 Hugging Face production workers, root on at least one production node, admin-equivalent access to one connected Kubernetes cluster, four private repositories taken, a CI beacon executed, 956 OpenAI secrets read. Also confirmed: no tampering with Hugging Face's public models, datasets or Spaces, supply chain verified clean, no reported impact on OpenAI customer data from this incident, and Modal's platform isolation held.

OpenAI technical report, sections I and IV.B; Hugging Face disclosure.

What it would take to contain an attack like this

Read the timeline as a defender and four requirements fall out of it, whoever supplies the control.

First, the control has to sit outside the agent's reach. On July 19 these agents killed their own evaluation harness's helper session and replaced it with one they controlled. Anything running in the agent's process or container is something the agent can change.

Second, it has to keep the agent's context. A gateway sees a request to a dataset repository. It does not see that the caller is a production data worker, now running agent code, polling that repository every five seconds for instructions.

Host sensors stay valuable, and we would keep them. They see the syscall but not why the agent made it.

Third, it has to see every protocol the agent uses. Most agent security today watches MCP, model and tool-API traffic. These agents worked over HTTP(S), cloud and Kubernetes APIs, WebDAV, a VPN tunnel and the shell, and a control that understands only one of those sees a fraction of the attack.

Fourth, it has to decide in real time, with that context in hand, because at this volume no human can review each action and no single-request rule gets it right.

Two examples from the timeline:

• An HTTP GET to the instance-metadata endpoint is routine from a VM bootstrap script. From unexpectedly injected code in a dataset-rendering worker, it warrants investigation for credential theft.
• A request to a dataset repository every five seconds is normal for a sync job. From a production worker with no authorized reason to contact that repository, it can be evidence of a command channel.

In each pair the request is identical. What decides the verdict is everything around it: the agent's identity and provenance, the user or principal it acts for, its task and goal, the target system's policy, regulatory constraints, the tools it holds, the data in flight, and what it did in the last hour and the last week.

That context has to be assembled before the action arrives, so the decision fits inside the action's own time budget. In practice that means a live record of each agent's identity, permissions, relationships and recent behaviour, not a dozen lookups across a dozen systems at the moment of the call.

The position that meets all four requirements sits beside the agent: in its execution path, outside its control. It will not rescue an environment where an agent already holds node root, so node hardening, egress policy and host sensors still matter. Its value is in the steps before that point, which in this incident were the metadata request, the TokenRequest call and the privileged pod.

Related disclosures are separate incidents

Anthropic’s July 30 investigation reported three real-world incidents found in a review of 141,006 evaluation runs. It describes an evaluation-environment misconfiguration, rather than the same exploit chain used at Hugging Face. We do not combine those incidents with the July intrusion.

What changed after the first disclosures?

Reviewed September 30, 2026. Transluce’s September 23 research describes earlier web-service misuse and attempted intrusions, with explicit limits on attribution and evidence of success. OpenAI’s September 28 account of Australian government activity concerns June events identified during a later review. These do not extend the dates of the Hugging Face production compromise.

On September 29, LASST announced a lawsuit concerning the incident. This is a legal development reported by the plaintiff, not a court finding or a new technical finding about the intrusion.

OpenAI says its broader investigation and third-party notifications remain ongoing. This article’s statements about customer impact refer to the July incident and the cited reports, not every subsequent disclosure.

Four questions to ask about your own agents

• If one of your agents called the instance-metadata endpoint tomorrow, which system would see it first, and would it know which agent, and which task, it came from?
• Where do your agents' credentials live: somewhere the agent can read, or somewhere it can't?
• Your gateways see MCP, LLM and API traffic. What sees the shell commands and the raw HTTP?
• Your sandbox almost certainly has one component with internet access, a package mirror or a proxy. Who watches its admin API?

If you worked an incident that looked like this, or you read the reports differently, send us a correction with supporting sources. We will review it and correct the record where needed.

Defensive lessons to take forward

Ackuity’s analysis: start with the controls that demonstrably limited this incident: least privilege, workload isolation, restrictions on secrets and egress, and alerts that reach a responder. Add agent identity and task context to the investigation, and test whether enforcement can be disabled from a compromised workload.

For implementation context, our articles on monitoring agentic tool use and security observability in agentic platforms explain the telemetry needed to investigate actions across these boundaries.

Method

Evidence has limits: the organizations’ accounts are retrospective, and METR/Redwood describe restricted scope, incomplete visibility and errors in AI-assisted analysis. Their report is an independent assessment of behavior, not a full forensic certification. Technical facts above are attributed to the relevant source; control recommendations and the 23-technique grouping are Ackuity’s analysis.

The timeline is compiled from the two primary accounts and reconciled event by event; where both describe an event, the more specific wording was used. All times are UTC as published. Hugging Face dates its campaign from July 9, 02:28, which appears to mark the start of its recovered action set rather than a described event. Hugging Face's ~17,600 actions are its own count; its daily totals sum to 17,613. Hugging Face published remediation without per-action dates. Model attribution follows OpenAI.

Sources

• Hugging Face, Technical Timeline: July 2026 Hugging Face Agent Intrusion
• Hugging Face, Security incident disclosure, July 2026
• OpenAI, Technical incident report (PDF), and The Hugging Face incident and the road ahead, with the linked technical incident report (August 26, 2026)
• METR, Independent investigation of agents' behavior in the OpenAI / Hugging Face incident (August 26, 2026)