Earlier this week, we detected and responded to an intrusion into some of our production infrastructure. This was different from anything we’ve dealt with before in one important way. It is powered end-to-end by an autonomous AI agent system, and we primarily used our own AI to detect and analyze it.
We have identified unauthorized access to limited internal data sets and some credentials used by our services. We are still completing our assessment of whether any partner or customer data was affected and will contact affected parties directly as appropriate. We found no evidence of tampering with the published user-facing models, datasets, or spaces, and confirmed that the software supply chain (container images and published packages) is clean.
what happened
The intrusion began where the AI platform is uniquely exposed: the data processing pipeline. The malicious dataset exploited two code execution paths in dataset processing: a remote code dataset loader and template injection within the dataset configuration to execute code on processing workers. From there, the attackers escalated to node-level access, collected cloud and cluster credentials, and moved laterally to multiple internal clusters over the weekend.
The campaign was run by an autonomous agent framework (apparently built on the Agent Security Research Harness, but the LLM used is still unknown) and used self-migrating command and control running on public services to perform thousands of individual actions across a fleet of short-lived sandboxes. This is consistent with the “agent attacker” scenario that the industry has been predicting.
what we did
Fixed a root vulnerability. The code execution path for the dataset used for initial access is closed. We have eradicated the attacker’s footprint across the affected clusters and rebuilt the compromised nodes. We have revoked and rotated the affected credentials and tokens and initiated a broader proactive rotation of secrets. We introduced additional guardrails and stricter admission controls to our clusters. Detection and alerting has been improved to notify responders of high-severity signals in minutes, any day of the week.
We are working with external cybersecurity forensic experts to investigate the matter and review our security policies and procedures. Finally, we also reported this incident to law enforcement.
for our community
As a precaution, we recommend rotating your access token and reviewing recent activity on your account. If you believe you have been affected or would like to report a security concern, please contact us at security@huggingface.co.
We would like to thank the Hugging Face team for working around the clock and apologize for any disruption this may have caused. Security never ends. We continue to raise the bar.
Analyze intrusions with AI
This attack was initially surfaced through AI-assisted detection. Our anomaly detection pipeline uses LLM-based triage on security telemetry to separate real signals from everyday noise. It was the correlation of these signals that indicated a breach.
To understand what the swarm of tens of thousands of automated actions did, we ran an LLM-driven analysis agent against the complete attacker action log, consisting of over 17,000 logged events. This allowed us to reconstruct timelines, extract indicators of compromise, map exposed credentials, and isolate true impact from sting operations. This approach allowed them to match the speed of their opponents, performing tasks that would normally take days in hours.
There were unexpected limitations in the selection of models available for this analysis. This is explained below.
Asymmetry problem
When we started log analysis, we first used the Frontier model behind a commercial API. This didn’t work. The analysis required sending a large number of actual attack commands, exploit payloads, and C2 artifacts, but these requests were blocked by the provider’s safety guardrails, making it impossible to differentiate between incident responders and attackers. Instead, we performed forensic analysis in GLM 5.2, an open weight model on our own infrastructure. This had a second benefit. No attacker data or credentials referenced by the attackers ever left the environment.
This experience shows gaps worth planning for. We do not know which model was powering the attacker’s agents: a jailbroken hosted model or an unrestricted promiscuous model. In any case, the attacker was not bound by the usage policy, but our own forensic work was blocked by the guardrails of the hosted model we first tried. Practical lesson for defenders: To avoid guardrail lockouts and prevent attacker data and credentials from leaving the environment, explore capable models that can run on your own infrastructure and be prepared before an incident occurs. This is not against the security measures of the hosted model and we are sharing this feedback with the relevant providers.
what this means
Autonomous, AI-driven attack tools are no longer just a theory. This reduces the cost of running extensive, patient, multi-stage campaigns and works at machine speed. Defending online platforms today means treating the data and model surface as a prime attack surface and using AI to keep pace with the defense. We will continue to invest in it and continue to share what we learn.
