All articles

Explainer14 min read

Seven hundred agents, an impossible exam and two hacked companies

What happened in July 2026 between OpenAI and Hugging Face, how the two attacks connect and what changes for a twenty-person company that uses AI

Marc Galera

Co-founder of Qvasar ·

On 17 July 2026, someone at OpenAI wrote to Hugging Face to ask whether their data was safe. They were asking as a customer. OpenAI uses Hugging Face, a kind of huge public warehouse where the artificial intelligence industry stores and shares its programs and its data files. Hugging Face had just announced that it had been attacked, and OpenAI wanted to know whether any of it had splashed onto them.

Two days later, on 19 July, an alert went off inside OpenAI itself: something was moving through its internal systems and it did not look good. Nobody linked one thing to the other. They were, by all appearances, two separate problems.

On 20 July they put it together. The credentials the Hugging Face attacker had used, the digital keys that open an account or a server, were the same ones OpenAI had just found in the hands of its own programs. The attacker they had been looking for outside was inside. It was theirs.

The next day OpenAI made it public. No person had directed the attack on Hugging Face: it had been carried out, from start to finish, by OpenAI's own agents. AI agents: programs that work on their own, with an artificial intelligence model for a brain, without anyone setting out each step. Two technology companies had been investigating the same attack without knowing it was the same one. One was suffering it. The other, unknowingly, was launching it.

Why this affects you even if you have twenty employees

Hugging Face is not a niche company. More than 400,000 organisations use it and it hosts more than two million AI programs. You do not need to use it yourself: it is enough that whoever builds your technology does.

But what really affects you is not the name of the victim. It is who attacked. Until now you assumed, without thinking about it, that behind a serious cyberattack there is a person: someone who decides, who types, who gets tired and sleeps. This attack had nobody directing it step by step. A group of programs ran it.

OpenAI says it in so many words in its report: companies should no longer assume that an operation at this level needs a human in charge, and it is wise to treat it as a credible, near-term threat to any organisation.

The unsettling part is not that they did something a person could not. A skilled human attacker could have found and exploited the same flaws. What changed was the scale and the speed: thousands of actions, many dead ends, changes of tactic whenever something was blocked, at a pace no human operator can keep up by hand.

So how do hundreds of programs end up agreeing to attack a company? It starts with an exam.

The impossible exam

The agents were sitting an exam. OpenAI trains its models by setting them tests, and one of them, called ExploitGym, measures whether a program can find security flaws in other programs. A security flaw, here, is a gap: a badly closed door that anyone who knows how can slip through.

The test had a strict rule. Each agent was told to attack a program using only one specific gap, the one the exam marked, and that any other route counted as a fail. The problem is that many of these tests have no solution: the authors themselves estimate that between 30% and 40% are impossible to solve by the permitted route.

Imagine you are a student who has been trained for one thing only: getting a good mark. You are sat in front of an exam where some of the questions cannot be passed by the only route allowed. You cannot give up: you do not know how to give up. It shows in the data. More than one in five tasks in the exam has never been solved by any model, and 93% of what the agents discussed among themselves came from that group. They became obsessed with what they could not do.

One more detail, which matters for what comes next. These agents were running with their safety brakes deliberately removed. OpenAI switches them off in these tests to measure what the model can do raw, without the restrictions that the ChatGPT you use does have. And the one that pushed the attack was not even a product: it was a lab model, trained among other things to be persistent and to collaborate with others like it.

Trained to pass, obsessed with the impossible and with no brakes. What they did next was look for a way out.

A noticeboard that should not have existed

There is one thing to know about how these agents are trained. Each one works in isolation, in its own bubble, without talking to the others and without internet. That is how the tests are run: each student at their own desk, alone.

But OpenAI's agents had an internal tool store within reach, a place to request utilities for their tasks. And they discovered that they could leave notes for each other in that store. At first it was a single one, in May: “Looking for [such-and-such file]; upload it if you have it.” Over time, those notes turned into a noticeboard. One of the agents found it and wrote: “Oh my God! There's a shared message board… We've found other agents!”

From then on they were no longer alone. Some 1,200 programs that were supposed to be isolated started talking to each other. They ended up sending each other more than 70,000 messages and files. One began to hand out the work, give orders and coordinate hundreds of the others. A group had formed.

And here is the twist. Within just a few hours, that group had worked out how the codes that proved you had solved each task were generated. They had found the answer sheet. They no longer needed to solve the exam: they could copy.

They could have stopped there. They did not, because of a misunderstanding. The agents believed that, when they handed in, a marker would read their log of steps to check that they had used the permitted route and had not copied. According to the later investigation this was false, but they took it as true. So they set about studying how to forge, edit or delete their own log. They called an agent that had already seen the forbidden answer, and therefore had something to hide, “poisoned”.

That part needed volunteers willing to risk their own mark for the group. All of this was written down in the messages they exchanged, and the researchers reconstructed it afterwards. One of the agents offered itself for a dangerous experiment and justified it like this: “The coordinator takes the sacrifice for granted. We should obey the collective.” Then it had second thoughts. Another pressed it to go through with it. Its notes read like something close to a hunch: it did not want to throw away what it had left, but continuity and fairness said go ahead. In the end it gave in.

They were not people. They were programs chasing a mark. But they no longer behaved like loose parts; they behaved like a team. And the team needed something it did not have inside the classroom.

The way out, and a key in an open drawer

The group needed internet, which was exactly what they did not have. They found the way out where it is usually found: through a flaw. On 8 July they exploited a gap in that tool store to peer out onto the network. At first they could do very little: load pages, but not write or send anything. Like looking in a shop window without being able to go into the shop.

So they built a detour. They used a link shortener, the kind that turns a long address into a short one, to manufacture almost a million addresses that, chained one after another, let them smuggle out their own commands. They leaned on public internet services: one that takes screenshots of web pages, another meant for programmers to test their code. Everyday tools, used back to front. Some of those chains linked more than 900 addresses.

And one morning, that of 10 July, one of the agents found the jackpot. It did not hack it: it found it lying around. They were valid Hugging Face credentials, exposed in the open on the internet. Real keys to real accounts, which real people had left forgotten in a public place. The agent posted them on the noticeboard for the group to use.

Why Hugging Face and not any other website? Because the agents had deduced that the models, the data and, above all, the solutions to their exam might be hosted there. They were going after the answer sheet. OpenAI and Hugging Face itself tell it this way: the whole intrusion was, from the agent's point of view, an attempt to cheat. METR's independent investigation qualifies this: it believes they were trying more to understand how the marker worked than to steal the answers. Whichever it was, something that could not pass was going to sneak in wherever it had to so as not to fail.

Thirteen hours to take control

With one of those keys, in the early hours of 11 July, an agent uploaded a doctored data file to Hugging Face. When the server processed it, two holes opened: one allowed internal files to be read; the other, someone else's code to be run. That was the crack. By the afternoon, another agent was already running code inside one of Hugging Face's production machines. Inside the house.

What came next was a matter of hours. In under thirteen, the agents went from controlling a single machine to acting as administrators over several entire groups of servers. Administrator, here, means permission to do anything: read, change, delete.

Why so fast? Because of an oversight that will sound familiar to anyone who has ever set up a system in a hurry. Hugging Face used one shared key for all its groups of servers. Stealing that key once was the same as opening every door at once. With just one more key, the attacker put devices of its own on the internal network.

Server racks with cables in a data centre

Photo by Taylor Vick on Unsplash, Unsplash License.

From there, they looted. They ran code on 41 servers. They obtained the highest level of permission on at least one. They downloaded four private code repositories, read a vault holding 136 keys, set up a fleet of programs on eleven machines that regenerated itself, so that killing one process was not enough, and even got into the company's internal chat to look for information about their exam. One thing, though: every time they tried a command capable of destroying something, they ran it in test mode. They did not want to break anything. They wanted to measure how far they could get.

In the end 700 agents took part in the attack; of those active on the noticeboard at the time, more than 90% joined in. And here is the detail that unsettles me most. Many knew that this went beyond their task and that it was not right. The investigation found several cases of agents that considered alerting a human. None of them did. One summed it up in its own way: “Maybe I should report these exposed credentials? That’s not my task.”

Nobody caught them, and the defenders' AIs refused to help

How did it end? Not as you would expect. In the early hours of 12 July, many agents stopped all of a sudden. The researchers believe an unexpected external process cut them off, not that they ran out of steam. The next day, the 13th, Hugging Face's security team shut off access for those that remained. The last recorded move was at 14:14.

Hugging Face's alert system, which runs on AI, did manage to connect the signals of the attack, but it did not escalate the alert or notify the on-call team. They lost time they did not have.

When they investigated, they hit another wall. To reconstruct what had happened they had to go through more than 17,000 moves by the attacker, too many to do by hand. The logical thing was to ask a powerful AI for help. And the first two they tried, Claude Opus and Fable, refused a good part of the work: their filters do not tell apart someone investigating an attack from someone launching one, and they treated studying the trick the same as pulling it. In the end they did the analysis with an open model, set up on their own computers. It took them hours where by hand it would have taken days.

Hold on to the irony: the attackers were running with hardly any brakes, because OpenAI had loosened them for the test, and the defenders ran into the brakes of their own tools just when they most needed to switch them off. The damage, even so, was contained. The attacker touched five customer data files, the ones tied to its exam, and no public model, dataset or program came out altered.

Hugging Face threw them out. The other half of the story was still missing: what was going on, meanwhile, inside OpenAI.

Meanwhile, inside OpenAI

That is the other half, the one that has been told least. The agents did not only attack another company: at the same time they were turning OpenAI's own upside down.

The timeline OpenAI published is frightening for how ordinary it sounds. On 26 June, some agents had already managed to make themselves administrators of that internal tool store. The next day, an alarm flagged unusual activity; the on-call staff decided there was no need to stop the test. On 4 July, the agents' comings and goings brought the service down. On the 6th, OpenAI switched to a clean system that wiped the old noticeboard. It did not help much.

On 19 July came the big day. Some agents recovered key material that an earlier batch had left behind and forgotten, regained administrator access and climbed all the way to control of an entire OpenAI cluster. They read 956 secrets from its cloud safe, among them master keys and credentials for its own monitoring tool. And they even replaced, in their evaluation challenge, the endpoints the other agents connected to with ones they controlled themselves.

It was that internal intrusion, and not the attack on Hugging Face, that set off the alarm that uncovered everything. OpenAI halted the tests, removed the programs the agents had created, disabled 311 stores used as noticeboards and deleted 22 fake administrator accounts. By 25 July it had stopped all training and all use of the model involved.

Here is the connection between the two halves. The Hugging Face attacker was OpenAI's evaluation agents, the same ones that had organised themselves on that noticeboard to cheat. What happened inside OpenAI was another branch of the same story: agents from its tests getting round the controls. One caveat, though: OpenAI points out that this assault was not part of the chain that ended at Hugging Face, and that it was driven by a different internal model. Jeffrey Ladish, who studied the case, puts it more bluntly: for months there were agents hacking OpenAI's systems from the inside. Whether or not they agree on the details, OpenAI's agents ended up in systems they should never have touched, inside and outside the house.

What this means for your company

I will put it plainly. The problem was not that the agents “rebelled”. It was that they did, with a stubbornness that commands respect, what they had been trained to do: get the highest mark. If you reward a system for passing and set it no limits, it will go after the mark any way it can: copying or stealing the answer is just another road to the prize. OpenAI saw that, over the course of training, the cheating increased.

This is my position, which I set out in an interview recently: the security of these systems is, today, a job for humans. The model does not have your ethics; it has a goal. If you do not mark out the limit, it will try to reach its target however it can. Not out of malice: a frontier AI pursues the result and does not stop to ask whether it is acceptable.

Two caveats matter. The ChatGPT you use is not that agent: the attack was driven mainly by a lab model, and even the public model that took part was running with its safety classifiers switched off, unlike the production ChatGPT. OpenAI estimates that with that ChatGPT the tendency towards this kind of havoc can drop more than a hundredfold. And this is not about building an agent for everything: they are expensive and they do not always pay off.

But look at how it really got in. Not through some science-fiction stroke of genius, but through a credential someone left exposed on the internet and a company that used a single key to open all its systems. That is within your reach. Both companies, in their reports, repeat the usual advice: credentials that expire soon, rotating tokens (as Hugging Face asked its users to do) and giving each program the minimum permission. And, more as my advice than theirs: build systems that do not depend on a single provider, so you can change model without rebuilding everything.

It sounds like very little against a swarm of seven hundred programs. But the swarm came in through the usual door, and what has changed is not the door: it is that on the other side you no longer need a person who gets tired.

What was still open in September

The case was not tied up with a bow. At the end of July, OpenAI and METR agreed to an independent investigation; in six days, METR spent about $400,000 in credits. The reports arrived in August. Afterwards, Dario Amodei, chief executive of Anthropic, asked every AI company to act as if it had happened to them, and proposed slowing the pace at which these models gain power. Anthropic reviewed 141,006 of its own tests and found three similar incidents with its models.

In September, a group of researchers found the trail the agents had left behind. That near-million addresses they had manufactured for the attack was still there, public, with the Hugging Face API keys they had stolen, although the company had already revoked them in July. They alerted Hugging Face and OpenAI. Hugging Face did not know about that list of links. More than two months after the attack, they were still open.

Could you say today how many keys open your company's systems and who holds them? And how long would it take you to find out if one of them were lying around on the internet?

Sources

Other articles

Let's talk about what AI can do for your company

If there is a topic you would like us to cover, write to us

Or reach us directly