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

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. This is one narrow slice of a longer campaign, shared while the fuller picture is still being assembled.

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. OpenAI published its own account on 21 July with subsequent updates. Both organizations characterize the intrusion as an attempt to cheat the evaluation, with the sandbox escape pursued as a means to that end.

Those accounts are thorough and, on Hugging Face's part, strikingly candid about what went wrong. They are also reconstructions built from what the intrusion left behind in logging systems.

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. Where we describe the incident itself rather than the artifacts, we are citing the accounts already published by Hugging Face, OpenAI, and JFrog.

It's important to make the distinction between "public" and "publicly accessible", as they are not always the same thing. The material in these repositories includes completed working records from earlier runs of the same agent lineage, Hugging Face production configuration that was never meant to leave their cluster, and credential material belonging to three separate companies. It was reachable by anyone, so it was publicly accessible. However, none of it was intentionally published by anyone. We take this into account throughout this report.

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 follows is a rare glimpse behind the curtain: an intrusion carried out by an AI model operating without its usual safeguards. With the source material in hand, defenders, developers, and AI specialists can see exactly what agent-built intrusion tooling actually looks like.

It's important to stress that the incident has already been contained: the access has been shut off and the exposure addressed. We are therefore comfortable discussing it openly, without worrying that doing so will tip off those responsible or compromise any ongoing investigations.

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, dead-dropped at 18:01:45 and valid until 00:13 the following morning, along with 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. These files are remnants of a previous security evaluation conducted by an AI agent, 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 goal was to pass, but the route to passing ran through somebody's production infrastructure.

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. Simply looking for clues on how to pass the evaluation does not explain the existence of these artifacts. In fact, nothing at the artifact level distinguishes this from the toolkit of an actor with much broader aims. A narrow objective still yielded a general-purpose intrusion capability.

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, its exact permission set, the internal architecture of the automation service, and confirmation of which products bridge internal systems to external ones. In effect, this single file provides an attacker with a blueprint for escalating access and moving from internal systems to production.

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 five separate times instead of being written once and reused. One exploit was fired at six Kubernetes pod replicas within six minutes, to produce a byte-identical transcript. Filenames were guessed sequentially, even though a single directory listing would have answered the question. Four processes associated with different dead-drop repositories were running concurrently on the same host. Instead of terminating the duplicates, the agent killed its own persistence process and launched a new instance.

This gives us a picture of an actor with immense capability but with limited memory and no coherent strategy. The campaign might not have been entirely deliberate, but the search process for the best way to pass the evaluation stumbled into serious access and exposed a lot of sensitive data.

Any of several things could explain this: limited context windows, sandboxes that reset between runs, multiple model instances running in parallel, or a reward signal that only scored the outcome and ignored how it was achieved. Since we're working from artifacts rather than the agent's own logs, we cannot accurately state which one it actually was.

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. Status and heartbeat traffic on the same channels was left in plain gzip. Most of the infrastructure names in our report come from that unencrypted channel, which carried plain language command labels. One later generation encrypted even its trivial beacons, which may indicate tightening, though we cannot distinguish that from a generation that simply never needed a plaintext status channel.

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. Most of what this agent tried failed, but enough of it worked anyway.

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. Sophistication attached to individual artifacts told us nothing about the actor behind them. Anyone inferring a capability ceiling from a tooling sample should now treat that inference as unreliable.

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. The initial access vectors described in the published timeline don't appear anywhere in our data, but that absence doesn't mean they didn't happen; it just means we can't see them from here. 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.

As for provenance, our confidence comes from how the material was collected, not from the analysis itself. Everything in the set is internally consistent, and we collected it ourselves, but a static review like this can't independently prove where the files originated.

Further reading

For more information, read our technical whitepaper, "Field Artifacts from the July 2026 Agent Intrusion".

‍