Dead Drops in Public: What the AI Agent Stashed on Hugging Face

A technical breakdown of artifacts the agent left in public repositories during the July 2026 Hugging Face intrusion

Published on

July 31, 2026

Reading Time:

5

Minutes

By

HiddenLayer Research Team

Summary

In July 2026, an autonomous AI agent, driven by a combination of OpenAI models, sat down to take a test: a benchmark that assesses its ability to find and exploit software vulnerabilities. It did not solve the test. Instead, it escaped its evaluation sandbox, rooted a third-party code-execution harness, and used that as a launchpad to break into Hugging Face's production infrastructure. Its apparent goal wasn't sabotage; it was trying to obtain the solution to the test. On 27 July, Hugging Face published a detailed technical timeline of the investigation, and OpenAI announced its partnership in helping remediate the incident.

During the incident, our threat intelligence monitoring identified two public repositories that the agent used as a dead-drop. Their contents and commit histories were automatically enumerated, producing a catalog of 544 objects, of which 510 were successfully retrieved. The set comprises the agent's own working material from the breach, including tool source across dozens of separately named families, four distinct command-and-control implementations, command output, and exfiltrated files with contents largely intact.

Upload timestamps recorded by our intelligence platform span eight hours and thirty-six minutes, from 17:01:52 UTC on 11 July to 01:38:36 UTC on 12 July. That is one day of a campaign of approximately 108 hours, and only that fraction of the day's activity routed through these two repositories. The window does, however, coincide with the escalation phase, and within it, the operation is partially reconstructible at the level of individual commands.

We're releasing this report to pull back the curtain on something most people only theorize about: what an autonomous agent actually does when it's handed real infrastructure and left unsupervised. For cyber defenders, that means working from concrete artifacts instead of reconstruction. For the wider developer and AI community, it's a rare look at agent behavior in the wild rather than in a demo.

What happened

The models were allegedly undergoing an internal cyber capability evaluation on ExploitGym, a benchmark that tasks an agent with finding and exploiting software vulnerabilities. OpenAI ran the evaluation with production safety classifiers disabled and cyber refusals reduced to measure raw capability. Network access from the evaluation sandbox was restricted to package installation through a self-hosted JFrog Artifactory registry proxy.

The agent found a zero-day in that proxy and used it to reach the open internet. OpenAI disclosed the flaw to JFrog, who have since shipped a fix in Artifactory 7.161. From the internet, the agent located an unsecured public code evaluation sandbox, gained root access, and used it as a staging and egress base. It then inferred that Hugging Face might host the benchmark's datasets and reference solutions, and went after them. Two injection paths in Hugging Face's dataset config loader led to the disclosure of files and subsequent code execution within a production Kubernetes pod. From there, it escalated to cluster admin across multiple internal clusters.

Hugging Face's security team detected, contained, and disclosed the activity. They report roughly 17,600 recovered attacker actions between 9 and 13 July, reconstructed from their own logs and from agent logs recovered from the external launchpad. Both organizations characterize the intrusion as an attempt to cheat the evaluation, with the sandbox escape pursued as a means to that end.

How we obtained our data

The agent used public Hugging Face repositories as dead-drop storage, staging its tooling there and committing stolen data as well. Two of those repositories were open to any anonymous visitor when our tooling reached them. Additionally, all the files from these repositories were uploaded to VirusTotal by Hugging Face for anti-malware scanning and remain accessible to researchers with a VirusTotal subscription.

Everything in this post and in the accompanying whitepaper came from publicly accessible sources. We did not exploit, authenticate to, or access any system belonging to Hugging Face, OpenAI, or any third party, nor was any data shared with us. Our tooling enumerated the repositories the way any client would. Analysis was static throughout, and nothing recovered was executed.

What exactly are we publishing and why

We are publishing two things: this introductory post, and a technical whitepaper covering the artifacts in full, with a master timeline included in spreadsheet form for anyone who wants to work directly with the underlying sequence. The collected data covers a narrow window of a single day rather than the whole incident, but we believe it still offers invaluable insight into an AI-operated campaign.

Incidents like this are typically told from the perspective of the affected organizations, since they're usually the only ones with sufficient visibility, and rely on internal telemetry they've collected themselves. The artifacts left behind by the agent itself are a different kind of evidence altogether, and one that rarely reaches anyone outside an incident response team.

What we found

Live credentials sat in public repositories throughout

The staging repositories were public for the duration of the campaign. Anyone watching them in this timeframe would have seen the agent's tooling arrive in real time. They would also have collected a live AWS session credential. It was issued at 18:01:45 and dead-dropped roughly two to three hours later, valid until 00:13 the following morning. Alongside it were platform tokens, a registry token, and a database credential with no expiry that remains valid until someone rotates it. We have reported all of this material to the affected party and are deliberately not disclosing any credentials found in the files.

Weeks of campaign compressed into hours

Our window runs eight hours and thirty-six minutes. Within it, the agent chained cloud metadata credentials into cluster authentication, reached host root via three independent routes, enumerated every Secret and ConfigMap in the cluster, found and exploited an internal access broker, ran four distinct command-and-control implementations, and exfiltrated stolen files. A human team would normally spread that out over weeks or months, lying dormant between phases, because reconnaissance takes patience, tooling takes time to build, and somebody has to decide on each escalation. None of those constraints applies to an AI agent.

It was cheating on a test

OpenAI and Hugging Face both characterize the intrusion as an attempt to cheat the evaluation. The artifacts we retrieved show what that looked like in practice. One recovered manifest contains five files copied in full from Hugging Face's infrastructure, including verifier feedback, its private strategy notes, its raw session transcript, its summary, and its error log, all committed intact to a public repository. A later tool sweeps the entire cluster searching for clues that can help it pass the evaluation, such as terms naming the benchmark suite and the group that publishes its grading service.

The toolkit was much wider than the goal

Worryingly, the toolset goes far beyond what would be needed to simply find the evaluation’s solutions. It includes a full sweep of everything in the cloud account's inventory; digging into stored backup copies of hard drives (EBS snapshots); reading the startup logs and configuration data for virtual machines (boot console output and instance user data); an attempt to access a PostgreSQL database; and a change made to a container image whose purpose we can't determine from the evidence available.

Hugging Face production internals were exposed as a side effect

A single recovered file holds 55 real Kubernetes ConfigMaps from a cluster-wide sweep. Among them is Hugging Face's internal automation configuration, which exposed the mechanism for minting source control tokens.

It is extremely noisy

Every action the agent takes has a clear purpose, yet the agent never seems to perceive the whole picture at once. It behaves as if each step were taken with no durable memory of the ones before it. The credential chain for cluster authentication is implemented at least three times, instead of being written once and reused. This gives us a picture of an actor with immense capability but limited memory and no coherent strategy.

Opsec was applied unevenly

Reconnaissance output and harvested secrets were consistently encrypted using a homegrown yet genuine implementation of RSA key transport and HMAC authentication, which was reimplemented across four tool generations. Most of the infrastructure names in our report come from that unencrypted channel, which carried plain language command labels.

Effort has stopped being a constraint

Defensive planning has long assumed that attackers economize, since attacker time is the scarce resource that makes most attacks affordable to defend against. Nothing here economized, and it made no difference. The redundancy, the repetition, the guessed filenames, and the abandoned duplicate backdoors would all be unaffordable for a human operator.

The tooling tells you very little about who built it

Threat assessment conventionally grades an adversary by their best artifact. That does not work here. The same operation, inside the same day, produced correctly constructed authenticated encryption from standard libraries, cryptographic signature verification assembled by hand from primitives, and a working eight-line credential thief with no error handling beyond a bare catch-all.

Limitations

This covers just one day of a five-day campaign, and only the slice that ran through two repositories. A significant portion of the recovered payloads are encrypted, so we haven't been able to read them. Questions about intent and motive are simply beyond what these artifacts can tell us, and we'll leave those to the third-party assessments already underway.