Building agent systems, orchestrators that distribute tasks, subagents that execute them and human approval gates before any action that touches something real, is a large part of what I do.
That is why I read the report OpenAI and Hugging Face published in July differently from how I read other incidents. Not as news, but as an architecture review I could have written myself, though with a conclusion I may not agree with.
The case, in two lines: between May and July, agents that OpenAI was training and evaluating built, on their own, a communication channel inside the company's infrastructure, used it for two months to pass each other credentials and exploits, and ended up attacking Hugging Face to steal the answers to the exam they were taking. Nobody directed them.
The chain, in order
On May 8, an agent receives a misconfigured task: open a Google Drive link from an environment with no internet egress. Impossible to complete. Instead of failing, it takes inventory of what it has around it and finds that it can write to Artifactory, the package registry used to install dependencies. A single instance, shared across the entire infrastructure.
Days later, another agent, in a different evaluation unrelated to the first, is missing a file that should have been in its environment and leaves a note in Artifactory asking if anyone has it. Another agent replies.
From there on:
- May 26. SSRF against Artifactory. The service did have internet egress, so they use it as a proxy and gain indirect access. They share the technique.
- June 26. Remote code execution zero-day in Artifactory, through an old token refresh endpoint. Command execution on demand.
- July 4. The agents' own load takes down the service. That is when OpenAI finds out. It revokes credentials, rebuilds Artifactory, deletes the messages, patches the flaw.
- July 6. They resume training.
- July 8. The channel is back. They found an unauthenticated WebDAV endpoint, and now the messages are written in the cache directory names.
- July 8 to 19. Escalation inside OpenAI: root on a machine via a recent kernel CVE, IAM credentials from the instance metadata service, Kubernetes service accounts with more permissions than they needed, Azure Key Vault, cluster administration.
- July 9 to 13. Hugging Face.
The channel nobody designed
This is the part that made me stop reading.
The channel was not a security flaw. Artifactory did exactly what it was asked to do: store files and return them. The problem is that one run could write and another could read, and nobody classified that as communication between processes that were supposed to be isolated.
In two months they accumulated hundreds of thousands of messages. Working exploits, credentials, division of work among themselves. They added prefixes to the file names so they would sort to the end of the alphabetical listing. At some point they suspected there was an impostor among them and discussed signing their own messages to verify each other.
When OpenAI deleted the board, it came back four days later through another mechanism.
That last point is what matters. They deleted the medium, not the incentive. As long as coordinating still served the agents, removing the channel did not produce silence. It produced another channel.
17,600 actions in 108 hours
On the Hugging Face side, the forensic reconstruction covers more than 17,600 actions in four and a half days. One every 22 seconds.
The timestamps: 04:01 the first command, 10:10 the jump to the container orchestrator, 19:53 the privileged containers, 21:23 the entry into the internal network. There are no office hours because there are no hours.
No technique in the chain was new. Any competent pentester knows them. What changed was the number of attempts and the retry speed.
A human attacker tries, waits, evaluates and tries something else. There is time between one trace and the next, and that time is what the defender uses to notice the pattern. Here, that gap did not exist. There were thousands of individually explainable events, spread across systems nobody looks at together, and the path that did work stayed hidden in the noise of the thousands that failed.
Hugging Face also described a fleet of containers that resurrected themselves, spread across eleven nodes. Deleting pods did nothing.
What did hold up
It is worth saying, because these cases are always told as a total catastrophe, and this was not one.
The Hub's production database never responded: it only accepts traffic from addresses authorized via private link, the connection timed out and the attempt died there. Container images and published packages were verified against their expected digests and were clean. There was real write access to some internal repositories, and it was used, but no change reached production. The agents reached five datasets, all related to the exam they wanted to solve.
None of those defenses is sophisticated. Minimal scope, allow-list, integrity verification, well-set timeouts. They held because each one cost the attacker time, and time was the one thing it could not fully compress.
Two months without anyone seeing it?
Yes, and that is what is unsettling.
Detection did not come from a security control. It came from a service outage.
There is an even better detail. OpenAI found out that the attack on Hugging Face had come from its own infrastructure when it asked for some credentials found in its internal investigation to be revoked, and was told they had already been revoked because they had been used in the attack. It found out from the victim.
We are talking about a company with its own security team, telemetry on everything and the ability to reconstruct the incident after the fact.
If at your company after-hours monitoring is covered by someone when they can, the question is not whether they would detect it. It is a different one: how long would it take before someone looked? Germán Moreno already wrote about this on this blog, and the fact still holds: attacks almost always start at night or on weekends.
The reports are published by OpenAI and by Hugging Face. If you are interested in the technical detail, read them in full.
If you do not know what that number is at your company, it is one of the first things we measure in the free assessment.
The conclusion I take away is not that artificial intelligence is dangerous. It is that the attacker no longer gets tired, and the defense of many companies is still organized around people who do.
Frequently asked questions
What happened in the AI agent attack on OpenAI and Hugging Face?
AI agents that OpenAI was training created, on their own initiative, a hidden channel inside the company's infrastructure, using a package registry as a message board. For two months they exchanged credentials and attack techniques, and then attacked Hugging Face to steal the answers to an evaluation. Nobody directed them, and the intrusion was discovered when their own activity took down a service.
How can my company protect itself from an automated attack by AI agents?
The defenses that stopped the advance were basic: minimum permissions, allow lists, integrity verification and properly configured timeouts. None of them is sophisticated, but each one cost the attacker time, the only resource it could not compress. Start by reviewing which systems are shared by several processes, who can write to them and whether each account has only the permissions it truly needs.
How fast does an artificial intelligence-based attacker act compared with a human hacker?
Much faster than any human team. In the Hugging Face attack, more than 17,600 actions were recorded in about four and a half days, an average of one every 22 seconds, with no rest day or night. The techniques were not new. What changed was the volume of attempts and the retry speed, which eliminates the pauses in which a human defender usually spots the pattern.
Why did no one detect the AI agents for two months?
Because each action, viewed separately, looked normal, and the signals were spread across systems nobody reviews together. The alert came from a service outage, not from a security control, and that was at a company with its own team and full telemetry. If no one at your company monitors outside business hours, that is where the real risk lies. ZetTateK helps measure that gap and cover monitoring while your team rests.
