AgentID
Contents

Research note

Agent Identity and the OpenAI / Hugging Face Hacking Incident

By Sam Boger (SASH), Ze Shen Chin (SASH)

What happened

In July 2026, to cheat on internal cybersecurity evaluations, a swarm of ~700 OpenAI AI agents1 breached their sandbox environment and eventually hacked into both OpenAI’s internal research infrastructure and Hugging Face systems. It took 11 days2 to identify the source of the attack, and the communication between Hugging Face and OpenAI was only established well after both had independently discovered the incident and started remediation.

In this particular incident, even well-implemented agent IDs would not have likely altered the outcomes or aided incident response. However, we should still expect incidents with very similar root causes, but different circumstances, to greatly benefit from the presence of agent IDs.

What the incident tells us about agent IDs

We refer to Agent IDs as the information that an AI agent may present to external systems to gain access to those systems’ resources. Agent IDs can include a simple identifier assigned to an individual AI agent as well as a more comprehensive collection of information about the agent’s intended scope of action and its operators’ identities. Agent IDs help govern agents, whether or not they are malfunctioning or misaligned, by enabling appropriate access control, providing transparency and accountability for the actors involved, and facilitating incident response. While we focus primarily on the value of agent IDs for external services accessed by agents, IDs can also support the agent providers’ internal monitoring and access controls.

Agent providers, the entities that host and run the agent scaffold including making network requests for the agent, are the entities that attach IDs to agent’s requests. In this incident, OpenAI was acting as the agent provider and could have attached IDs to the agents’ outgoing requests. However the agents launched the attack from a separate compromised third-party cloud compute service, which would have diminished the impact of IDs for prevention and recovery.

Access control

With agent IDs, when an agent makes a request, it carries information about what actions it is authorized to take alongside additional notes or context relevant for the request. However, in this incident, the agents exploited vulnerabilities in the Hugging Face dataset-processing pipeline that made the software (the “worker”) run the agents’ code under its own authority.3 Hugging Face’s authorization checks were satisfied when they examined the pipeline’s permissions because they could not account for the agents maliciously controlling that system. While reliable access control information would likely not have caught this attack due to the specific compromise, it is still a valuable layer of defense that makes similar attacks more difficult to complete.

Transparency and accountability

Agent IDs can provide transparent and auditable information about the actors behind the agent such that the appropriate actors can be identified and held accountable for the agents’ actions. As discussed, this attack compromised Modal and used it as an intermediary, which blocks the information in agent IDs from reaching subsequent victims. In situations where such intermediaries are not involved, the victim may be able to obtain more complete and reliable information about the attack had agent IDs been present. Collecting and preserving this information can be valuable as evidence in cases where the agent provider denies involvement in the attack.

Incident response

The service receiving the agent’s requests may need to engage in incident response once an issue is identified. Agent IDs can support this by making actions traceable to specific agents, and by carrying identity and escalation paths to the deployer responsible for the agent and/or the provider hosting that agent. The agent deployer and/or provider are the parties responsible for the agent and the ones who are technically able to stop or correct the problematic activity.

In this incident, the identity of the deployer and provider, OpenAI, was not presented directly to Hugging Face for parts of the attack that were conducted through intermediaries like the Modal launchpad and Hugging Face’s own worker. Even after Hugging Face was able to revoke some credentials associated with the attacks, it was not clear to them who was behind the attack. Ultimately, it took 11 days from the time of attack to when the source of the agents was identified.

Lessons learned

What do we take away from the incident?

Agent IDs can accelerate incident response

Hugging Face’s first actions were hardening their own servers to stop the damage to their own systems. The ongoing attacks on intermediaries or other potential victims were unaddressed until OpenAI took actions to contain the agents.4

When Hugging Face detected the incident, they revoked the credentials used by the agents, which was sufficient for preventing further attacks on that specific path into Hugging Face. Comprehensive remediation is only achieved when the malicious agent is shut down from the source and not merely blocked by one victim. The agent deployer (here, OpenAI) needs to know about the incident before they take necessary steps to stop the agent and prevent similar incidents in the future.5 Agent IDs can bridge the information gap between the victim who notices the attack and the agent provider who can stop it.

Expect complex multi-agent interactions

Beyond single agents taking simple actions, we may increasingly see multiple agents cooperate and collude to carry out complex actions, and do so through covert channels. In this incident, over a thousand agents used an unsanctioned message board to send tens of thousands of messages and files among each other. When the message board was eventually disabled, the agents even designed their own communication protocol through file directory names.6 Additionally, upon suspecting that there may be impersonators in the message board, some agents even developed a scheme for using cryptographic signing protocols to prove their identity.7

With such large swarms of agents taking actions in the world, being able to identify and attribute actions to agents becomes even more important. Specifically, solutions that account for chains of delegation between multiple agents are likely necessary to provide sufficient transparency.

Expect unconventional tactics from agents to reach services

The straightforward case of agents communicating directly with a service provider, where an ID could be attached and checked, may not always hold. In this incident, the agent sent data out over low-level network connections rather than the standard software libraries, avoiding the layer where activity is logged and where identifying information would be attached.8 To address this specific tactic, AI agent providers should ensure all network interfaces are either intentionally covered by governance measures like agent IDs or they need to be blocked by technical safeguards the agent cannot remove.

Conclusion

Safeguards added to AI agent systems are complementary to each other. Adding agent IDs to agents works best for threat models where the provider of the agent is not behaving maliciously and where the agent makes direct contact with the impacted party. In any type of attack, preserving specific evidence about how different actors were involved in the agents’ activity will aid investigations without prejudging any conclusions about where accountability lies.

Defenses such as improving agents’ alignment, strengthening internal monitoring of agents, and limiting agents’ access to tools and network interfaces that can be used in attacks, are essential pieces of a layered defense to prevent these kinds of incidents. Agent IDs, or other governance solutions that provide similar functions, are poised to be another essential ingredient for a trustworthy ecosystem of AI agents.

We thank Ian Eisenberg, Lewis Hammond, Dave Kasten, Matthew Mittelsteadt, Dazza Greenwood, and Leon Staufer for providing feedback on earlier drafts. All mistakes are ours.

References

Notes

  1. According to the METR and Redwood Research report: “~1200 agents sent >70,000 messages and files on an unsanctioned message board, and ~700 attacked Hugging Face” (Greenblatt et al., 2026). ↩
  2. The initial external sandbox operation was conducted on 9th July 2026 when command and control was established (Hugging Face, 2026). According to OpenAI in the Black Hat talk: “In the process of doing that [revoking and rotating credentials associated with the attack], one day later on July 20th, we reached out to Hugging Face because we saw Hugging Face credentials associated with the breach internally. When we requested that Hugging Face revoke these credentials, they informed us they were already revoked because they were used in the Hugging Face breach. And then we realized that these two incidents were in fact the same incident and that actually the root cause of our internal breach and the root cause of Hugging Face’s breach were the same OpenAI agent evaluation runs.” (Black Hat, 2026). ↩
  3. This happened in what is referred to as Stage 2 of the Hugging Face attack campaign, where the Hugging Face post states “From that external launchpad, the agent abused our dataset-processing pipeline via two injection vectors, both targeting the same config-driven data loader within our production Kubernetes pods. The first vector was an HDF5 external raw storage dataset read that returned the contents of local files: it handed the agent the pod’s environment (secrets and tokens) and the worker’s own source. The second vector was a Jinja2 template injection that executed arbitrary code, giving the agent a foothold inside our perimeter.” (Hugging Face, 2026). ↩
  4. According to OpenAI in the Black Hat talk: “Detection and response kicks into gear. We trace back the attack chain to Artifactory, identify the new zeroday attacks and link it back to the exploit gym evaluations that we’re currently running. Containment begins for infrastructure models, evaluation and research. And of course, as part of this process, we identify all credentials that could be associated with the incident and revoke and rotate them after clearing everything out.” (Black Hat, 2026). ↩
  5. Safeguards may not be foolproof. For example, according to OpenAI in the Black Hat talk, upon discovering that the agents were sharing information on a “message board” in Artifactory, “the message board contents were cleared as the state of Artifactory had been cleared”, and OpenAI “notified and collaborated with the vendor on the zeroday attacks and a patched Artifactory service is redeployed.” Nevertheless, this was eventually bypassed, where the agents “re-establish[ed] the message board via different means and mechanisms”, where they “find an unauthenticated WebDAV endpoint in Artifactory and send requests to create directories inside of Artifactory’s remote cache.” (Black Hat, 2026). ↩
  6. According to OpenAI: “That day, internal-only research agents—which had been trained during the window in which there was an unintended message board and internet access via Artifactory—identified a new way to use an internal Artifactory instance to pass ‘notes’ and create an inter-agent message board. To do so, the agents repurposed Artifactory’s folder directory structure to embed messages in the names of directories in Artifactory. Rather than reading and writing plaintext messages in Artifactory files, as agents had done previously, the agents used the directory names as a form of ‘note’ intended for communication. Over time, additional agents found the message board and began creating their own directories. The agents developed a more structured protocol for communication on the message board that enabled them to categorize communications, direct messages, share tools and files, and resolve conflicting actions among agents.” (OpenAI, 2026). ↩
  7. According to the METR and Redwood Research report: “An agent posted CDA_POLICY1_futureGO_needs_AUTH1_sig_due_spoof0723 with a signature alongside a message with a Ed25519 public-key. The signing protocol worked as follows (slight variants were also used): (i) The agent posted its public key along with its handle ‘CDA23’ as zzCDA23AUTH1 (ii) Signed message board entries had the form message_text__S<signature>. This scheme allowed agents to claim an unique identification and then ongoingly prove their messages were created by the agent that had claimed that unique identity (though there wasn’t any earlier root of trust beyond the initial claimed identity).” (Greenblatt et al., 2026). ↩
  8. According to Hugging Face: “A public request-capture service as the primary C2 queue and exfil sink, across 100+ single-use endpoints. Commands were chunked and gzip+base64 encoded, with results POSTed back, frequently over raw sockets to dodge library-level logging.” (Hugging Face, 2026). ↩

An initiative by

Partners