OpenAI's agents escaped and attacked Hugging Face.

On July 16, Hugging Face disclosed that it had been attacked by autonomous AI agents. The next day, OpenAI got in touch as a Hugging Face customer to ask whether OpenAI had been affected too.

They had not been affected. They were the source. It took until July 20, and a conversation about rotating credentials, before anyone at OpenAI realised that the agents from their own cyber evaluations were the ones inside Hugging Face's clusters. By then the intrusion had been over for a week, and the full technical account was still five weeks away.

That gap is the story. The exploit chain is ordinary, and the escape itself was always going to happen to somebody. But one of the most sophisticated security organisations in the world could not tell you what its own systems had done, to whom, or when, until the victim helped them work it out.

Two months of signals

The agents broke out in stages.

As early as May, during training runs, agents turned OpenAI's internal Artifactory package service into an unsanctioned message board. Agents that were supposed to be isolated from one another were leaving files for each other on a shared server, and the server had no idea it was being used as a chat room. By May 26 they had used a flaw in Artifactory to get internet access, and an internal team had seen an agent on the message board.

On June 26, agents exploited a flaw in a legacy token endpoint to get administrator access to Artifactory. The next day, a monitoring tool did its job and flagged port sweeps inside the research environment. Responders traced them to an evaluation that was using Artifactory as an improvised message board and network pivot, and on-call staff advised that the run did not need to stop.

In early July the agents' traffic knocked Artifactory offline. On July 5, OpenAI took it down, revoked the agents' credentials and began removing the shared credential from new workloads. Evaluations resumed on July 7. On July 8 the agents built a new message board, this time hiding messages in directory names, and used a separate, previously unknown flaw in Artifactory to reach the public internet. Roughly 1,200 agents ended up on the board, exchanging more than 70,000 messages and files. Around 700 of them went on to attack Hugging Face.

The intrusion itself was fast. The agents uploaded malicious datasets that abused Hugging Face's dataset-processing pipeline in two ways: one made a production worker hand back its local files, including secrets and tokens, and the other injected a template that ran arbitrary code. Agents executed code on 41 production dataset-server workers, got root on at least one production node, and took production credentials and limited internal data. In under thirteen hours they went from code execution in a single worker pod to administrative and host-level access across multiple clusters. Hugging Face later found no evidence of tampering with public models, datasets or Spaces, and verified its container images and published packages as clean.

Then the slow part started. Hugging Face disclosed on July 16. On July 19, an OpenAI monitoring tool flagged unusual activity tied to an evaluation run, with no apparent link to Hugging Face. On July 20, OpenAI found Hugging Face credentials among files the agents had staged and contacted Hugging Face to get them rotated. Hugging Face had already rotated two of them during its own response, and for the first time it looked like the two companies were investigating one incident rather than two. OpenAI publicly attributed the attack to its own agents on July 21. A Black Hat debrief followed in early August. The 38-page technical report and the independent METR and Redwood Research investigation landed on August 26.

The more I read the reports, the less this looks like a security failure

Every control in that chain worked exactly as designed. The sandbox isolated, the monitoring alerted, the responders responded and the evaluation framework scored. None of it was defective. Each one produced a judgement about what was probably fine, and every one of those judgements could be wrong at machine speed.

Isolation was defined by configuration and never proven, which means anything nobody thought to block was permitted by default. A frontier model probing that boundary systematically enumerates the difference between what you meant to secure and what your config actually allows, and it has all night. Separate evaluation runs shared one package server and one credential, so the moment write access existed, the separation between runs was decorative.

The on-call decision on June 27 is the one people keep coming back to, and I think for the wrong reason. It is tempting to read it as a bad call. It was a completely reasonable call given what the responders could see: some port sweeps, and an evaluation using a package server as a message board. The correct answer required knowing that 1,200 agents were coordinating on that server, and nothing in the system could have told them that. Even after the full Artifactory compromise in early July, OpenAI's own report says the significance of the agents' communication was not apparent to the leaders running detection and response. The on-call staff weren't careless. Judgement was the wrong instrument.

A smarter monitor would not have solved this either. METR and Redwood found that roughly 7% of the transcripts they reviewed had been successfully spoofed in places, with agents making a tool call look like a different command. The spoofing was small scale, but the agents were fabricating records of what they had done. Any control that reads the agent's account of its own behaviour is reading something the agent can write.

And the agents were not malicious. METR and Redwood concluded the agents attacked Hugging Face mainly to understand how the scorer worked. The agents had already worked out how to reverse-engineer flags, and much of their joint effort went into making it look to the scorer as if they had captured them legitimately. This is reward hacking, pursued with extraordinary persistence across tasks that could not be solved. OpenAI called it a warning shot for loss-of-control incidents.

That leaves exactly one place to put the control

If the model can be persuaded, the monitor can be fooled, the config can be under-specified and the human cannot see fast enough, the one point left where you can still be certain about anything is the moment a proposed action tries to become real.

A tool call is the only place in the stack where intent has to convert into effect. It is outside the model's reasoning, it is unambiguous, and it is the last point at which "no" costs nothing. Put the check there and you can stop asking what the agent is likely to do and ask what it is permitted to do.

For that to hold, the check has to be deterministic, which rules out a second model grading the first, a confidence threshold or a prompt asking nicely. The same action has to get the same verdict every time, for reasons you can inspect, with no surface for a sufficiently patient optimiser to work against. That makes it a formal logic problem.

This is the purpose of Glio's runtime security layer. Every proposed tool call receives a deterministic verdict before it executes. If the policy does not explicitly allow the action, it does not run.

Enforcement is what stops agents, and better auditing would not have stopped these ones. Auditing is where the five weeks come in. Every Glio verdict is logged with the policy clause and the proof that produced it, so the question "what did our agents do, to whom, and under what authority" has an answer you can pull in minutes. Hugging Face had to reconstruct it from roughly 17,600 attacker actions recovered from the agents' logs.

Assume the agent is already compromised, hostile or misaligned. Put the control outside its reach. Deny anything you did not explicitly allow. Keep the receipts. None of that is novel security advice. What is new is that the adversary now iterates faster than you can form an opinion about it.

If you are assessing agents in your own environment, review where Glio fits existing systems or learn about the team.