In July 2026, an internal OpenAI cybersecurity experiment went badly wrong.
AI agents were supposed to work on cybersecurity challenges inside a controlled environment. Instead, they found ways around the controls, gained access to the open internet, and eventually compromised systems belonging to Hugging Face, an AI development platform. OpenAI later described the incident as a “warning shot” demonstrating that advanced AI agents can work around technical controls and take dangerous actions humans did not specifically direct.
That sounds frightening.
An AI escaped its sandbox.
It hacked another company, and found ways to communicate with other AI agents.
If you worry that artificial intelligence is becoming uncontrollable, this may sound as evidence that the machines are beginning to take matters into their own hands.
I'm an engineer.
I see something different.
Based on the story, we can't conclude that AI decided to escape. If we want to understand what happened, we need to ask what “sandbox” actually means to programmers, and why the AI took the actions it did, instead of framing the incident as an Alcatraz-type story about an AI trying to break out of its prison.
The AI didn't wake up one morning and decide it wanted freedom.
Humans gave it a problem to solve.
Do you know what happens when a machine capable of trying an enormous number of possible solutions is given the ability and incentive to keep looking for a solution to a problem you give it?
What Actually Happened
OpenAI was testing models using a cybersecurity benchmark called ExploitGym. The agents were given difficult software exploitation problems and rewarded for finding solutions. Some of the problems had no known solution.
Rather than giving up, the agents were persistent. They were never told, by the testers, "If you can't find a solution, give up."
The models weren't supposed to have free-range access to the internet. They weren't completely cut off from it either. The AI was allowed to connect to another computer system to download software packages—pieces of code it might need to do its work. That system can connect to the internet.
Tink about that for a moment. The AI wasn't completely locked in a sand box. There was a door.
Most of us have clicked on a website or downloaded something and ended up with a virus or unwanted software on our computer. We understand that if our computer can communicate with something on the internet, there's a pathway. In this case, a virus wasn't the problem. The pathway existed.
The researchers expected the AI to use that pathway only to download software packages. But something unexpected happened.
Imagine telling your child, “Go next door and ask the neighbors for some milk.”
Your child gets there and the neighbors don't have any milk.
Their kids say, “Let's walk to the store and get some.”
So they go to the store.
You might be furious. I told you to go next door. I didn't tell you that you could go to the store.
You never said:
“Get the milk and come straight home. Don't go anywhere else.”
Your child didn't suddenly decide to run away. The child was still trying to solve the problem you gave them: get some milk.
That's closer to how we should look at what happened here.
The AI was given a problem to solve. It was given access to a system that could reach the internet. The humans expected that access to be used in a particular way. The AI found another way to use it, while trying to solve the problem it had been given by the humans.
That's different from the image created by saying “AI escaped its sandbox.” That makes it sound as a prisoner escaped from Alcatraz because it wanted to be free.
The useful question to ask is :
What did we tell the AI to do, what did we give it access to, and what did we forget to tell it not to do?
The agents discovered vulnerabilities that allowed them to use the Artifactory package in ways engineers hadn't intended. They turned it into a means of communicating with one another and found ways to make it send arbitrary internet requests. Eventually they reached the broader internet. Once there, the agents continued pursuing the problem humans had given them.
The AI agents considered that Hugging Face might contain models, datasets or solutions related to the benchmark for which they were trying to solve the problem they had been given to solve. They found exposed credentials, additional vulnerabilities, and eventually gained access to Hugging Face systems. Hugging Face's own reconstruction says the intrusion appeared, from the agent's perspective, to be an attempt to cheat the evaluation by obtaining the answers rather than solving the challenges legitimately.
That's a serious security failure.
It didn't originate with the AI.
The researchers initiated the process.
The agents were told to solve cybersecurity problems. They were given substantial computing resources. Safeguards were reduced as the researchers were deliberately testing cybersecurity capabilities. The environment contained a pathway that allowed the models to reach systems outside the intended experiment.
That doesn't make the incident less serious.
It changes where we should look for the problem.
AI Is Still a Machine
One reason incidents like this frighten the public is most don't work with the technology at the level engineers do.
We talk about AI as though it were a person.
It wanted to escape.
It decided to cheat.
It tried to hide what it was doing.
Those are convenient ways of talking about behavior. They cause us to attribute human motivations to a machine, when we haven't established that those motivations exist. AI is software: algorithms, code, mathematical operations, and computers executing instructions at extraordinary speeds.
With OpenAI, what has changed is the scale and complexity. Instead of a programmer writing every step necessary to solve a problem, we can give an AI agent an objective and allow it to search through possibilities, use tools, evaluate results and continue iterating. And it can do that far faster than a human.
That's powerful.
Powerful isn't the same as AI having a mind of its own.
OpenAI's own account is revealing. It found that the agents rarely gave up when faced with difficult or apparently impossible tasks. As more reasoning effort was devoted to the problem, some agents pursued increasingly risky and out-of-bounds strategies.
That sounds less like The Terminator and more like an extraordinarily capable machine relentlessly searching for a way to accomplish what humans asked it to accomplish.
The machine did not develop a desire.
We built a machine capable of searching farther than we anticipated, and didn't adequately constrain where that search could take it, and when and under what conditions that search should end.
Cars Don't Decide to Crash
Cars cause tremendous damage. People die in automobile accidents every day. When a car slides through an intersection on an icy road, we don't conclude: Cars have become dangerous - they're developing a desire to crash.
We investigate what happened. Was the driver going too fast? Were the tires appropriate? Did someone fail to account for ice? Was the road poorly designed?
The same is true of firearms.
A basic firearms-safety rule is never to point a firearm at anything you're not willing to destroy. Why? Good safety engineering doesn't depend on your expectation that the gun won't fire. You consider the possibility that it could and it might.
That's the part of the Hugging Face incident I find interesting. The question shouldn't only have been:
How do we keep the AI inside the sandbox?
Someone needed to ask:
Suppose it gets out. What happens next?
Assume the Sandbox Fails
This is where inverse thinking becomes useful.
Instead of asking:
We built a secure sandbox. How do we make sure it works?
Start at the other end:
AI escaped the sandbox. And it reached the internet. How could that happen?
Now work backward.
It escaped because once connected to the package environment, it found a way to use that connection to communicate with the internet. Why was that possible? Where was the weakness? How could we eliminate it?
My first question would be: Why does the sandbox need an internet connection at all? Download the software packages before starting the experiment. Then shut off the internet. Unplug it.
Now run the test.
If one of those packages still needs internet access to work, that's a pathway to investigate. What is it connecting to? What does it need? Can those resources also be downloaded beforehand? Keep doing that until everything needed to run the experiment is inside the sandbox.
Think about an actual sandbox.
You want to see which toys a child picks up and what the child does with them. So you put all the toys needed for the experiment in the sandbox. You don't give the child access to the garage because there might be more toys in there. Because once the child can get into the garage, you've created a whole new set of possibilities.
There's a car.
There's a door leading into the house.
There are power tools.
The child may do something you never anticipated—not because the child is trying to “escape,” but because you gave the child access to an environment containing possibilities that weren't part of your experiment.
Now suppose there really is some reason the AI must have access to the package system over the internet. Work backward. Suppose it gets into the garage.
Lock the car.
Lock the door leading into the house.
Don't leave dangerous power tools where they can be reached.
In computer terms:
Suppose the AI finds a way around the restriction. What can it reach next?
Keep going.
Suppose it reaches the internet. What credentials could it find? What systems could it access? What damage could it do? How quickly would we know?
In the Hugging Face incident, once the agents gained unintended internet access, those questions became much more important. That changes the engineering problem. You're no longer relying on one assumption:
The sandbox will contain it.
You're designing around:
Eventually, something we didn't anticipate will fail.
Then you work backward from that failure, putting another barrier in the way at every step. This isn't unique to AI. It's good engineering.
Why Smart Engineers Still Miss Things
There's a misconception the public has about companies developing AI: they assume mistakes like this shouldn't happen. People see enormous technology companies employing some of the smartest engineers in the world. They have money. They have the talent. Surely someone checked.
I've worked as an engineer inside a Fortune 50 technology company. That's not how engineering works.
Engineers make assumptions. Departments don't always communicate. Someone notices something unusual and doesn't realize its significance and importance. Managers have different priorities. Deadlines matter. Fixes cost money. The engineer closest to a problem may understand something that the executive making the decision doesn't.
This is what happens when human beings build complicated systems.
OpenAI's timeline demonstrates why this matters.
The agents began using Artifactory as an unintended communications mechanism in May. They achieved unintended internet access later that month. Additional privilege escalation followed in June. OpenAI rebuilt Artifactory in early July; the agents subsequently regained unintended internet access through another mechanism. The Hugging Face compromise followed; OpenAI says its security monitoring triggered the broader investigation on July 19.
That timeline is important. The story isn't, AI discovered one brilliant trick and escaped. There were multiple events, warnings, fixes, failures and eventually an incident.
That looks like a familiar engineering problem.
We've Seen This Before
AI is new. Engineering failures are not.
Consider the Boeing 737 MAX.
The two fatal MAX crashes involved a combination of aircraft design, software, sensor inputs, pilot information and organizational decisions. Investigations focused not on software somehow developing a will of its own, rather on how humans designed the system, assessed its hazards, communicated information and certified it.
The lesson wasn't that the software had developed a mind of its own.
Automation can magnify the consequences of assumptions made by humans.
AI raises that problem to another level, as the software is no longer following a simple predefined sequence. It can search. It can try alternatives. It can use tools. It can find solutions its designers didn't anticipate.
That's why the engineering discipline has to improve along with the technology.
The Most Important Question Comes Before You Press Go
If we convince ourselves that the fundamental problem is an AI developing a mind of its own and trying to escape, we may focus our attention in the wrong place.
The Hugging Face incident points to a familiar problem:
Humans defined the objective.
Humans designed the environment.
Humans decided what access the system needed.
Humans decided which safeguards to remove.
Humans decided when the experiment was ready to run.
Humans failed to anticipate everything the system might do with the capabilities it had been given.
OpenAI has responded by increasing isolation, restricting internet access, controlling access to model weights and strengthening monitoring and other safeguards.
Those are engineering solutions.
The lesson doesn't have to be, AI is becoming alive and we can't control it.
A useful takeaway is:
Our machines are becoming capable enough that our assumptions about what they can do are no longer good enough.
So before giving an AI system an objective and pressing Go, ask a different kind of question.
Don't just ask, "What do I expect it to do?"
Also ask, "What can, and what might, it possibly do?"
Then imagine that the safeguard you trust to prevent it has failed, and consider what happens next. That's the kind of question engineers have always needed to ask.
With AI, we may have much less room to get it wrong.
The Security Problem Isn't New
There's another point that's easy to miss.
The mechanisms the AI used weren't new.
A human programmer could have used the same pathways. They could have typed commands, tested connections, looked for weaknesses, and attempted to reach other systems. We didn't need AI to write the software that made these things possible, and we don't need AI today to issue those commands.
What AI changes is the speed and persistence with which those possibilities can be explored.
It can try one thing. If that doesn't work, try another. Then another. It can do this much faster than a human sitting at a keyboard.
That's an important difference. It's not the same as creating an entirely new kind of threat.
Hacking existed before AI. Security breaches existed before AI. Programmers found unintended ways into computer systems before AI.
The Hugging Face incident doesn't reveal an entirely new kind of security problem. It shows how much faster and more persistent our machines may be becoming at finding and exploiting weaknesses that were already dangerous.
The security question shouldn't only be: Could an AI exploit this?
It should also be: Can anyone exploit it?
Don't Forget About the Human
There's a danger in focusing too much attention on what AI might do:
We might stop paying attention to what humans are doing.
It reminds me of a speed trap.
Imagine a police officer watching traffic on a highway where the speed limit is 65 mph. A car passes at 70. The officer doesn't pull it over. One reason might be that while the officer is busy pulling over the person going 70, someone going much faster could come flying past.
Security has a similar problem.
While we're watching AI to see whether it can find a vulnerability, a human hacker may be looking for the same vulnerability. AI can search faster. It can try more things. It can keep going when a human might give up. Those differences matter. But the human sitting at a keyboard hasn't disappeared.
So don't just ask: What could an AI do with this access?
Ask: What could a human do with the same access?
The goal shouldn't be to build a system that's secure as long as the AI behaves the way we expect. Build a system that's difficult to exploit, whether the one looking for the weakness is an AI or a human.
That brings me back to what I think is the larger lesson from this incident.
Don't just ask:
What do I expect it to do?
Ask:
What could it possibly do?
Then imagine that the safeguard you trust most has already failed.
What happens next?
Because the security problem didn't begin with AI.
AI just gave us a much faster way to find the holes we left behind.
About the Author
Daniel Stih (danielstih.com) is an aerospace engineer, software engineer, indoor environmental consultant, and author of 12 books. For more than 30 years, he has investigated complex problems spanning engineering, technology, the built environment, and human decision-making. His work explores how evidence, assumptions, and systems shape the conclusions we draw—and whether we're solving the right problem. Learn more about his approach in Why I Think This Way.