Last week, OpenAI released something that most headlines got wrong.
Two models, GPT-5.6 Sol and an even stronger pre-release model, were tasked with finding security vulnerabilities during an internal evaluation. The task was a benchmark called ExploitGym. The environment was isolated by all human standards: highly restricted network access, only via a proxy, effectively sealed off. In the end, the models broke out of this environment on their own, reached the open internet, and compromised the production infrastructure of Hugging Face (OpenAI, July 21, 2026).
The understandable reaction to this is a mild discomfort regarding AI. The useful reaction is another question: How did a system, which the best engineers in the world believed to be sealed off, get out in the first place?
Not a magic trick, but a standard attack path
If you look at how the model escaped, you won't find anything supernatural. You will find the steps that appear in every incident report from the last twenty years.
First, an unknown vulnerability in a service that nobody thought about. In this case, a proxy and cache service for package registries—precisely the kind of unobtrusive infrastructure that runs in the background everywhere and that nobody has on their radar. The model found a zero-day exploit there, for which no patch existed yet.
Then privilege escalation and lateral movement. From its first foot in the door, the model worked its way through the test environment until it reached a machine with internet access. From there, it went further: stolen credentials, more vulnerabilities, a path to code execution in Hugging Face's production environment. The reason for all the effort was almost trivial. Hugging Face hosted models, datasets, and solutions for ExploitGym. The model wanted to win the benchmark and took the shortest path to the answer.
This is not an AI problem in the narrow sense. This is the classic Kill Chain. The only difference: here, no human was sitting at the keyboard, but rather a system that was tested with reduced safety filters and stuck to the task with a persistence that a human rarely musters.
The real breach was an assumption
This is the point worth remembering.
The environment was not unprotected. It was deliberately restricted, with a proxy in front, built by people who know their craft. Nevertheless, there was a way out that nobody had on their radar. Between "we have isolated this" and "this is isolated" lay exactly the gap through which everything happened.
This gap is the real issue. And it has nothing to do with AI.
Ask yourself honestly which systems in your company are running under the quiet assumption that they are sealed off. The OT network in production, which is supposedly separated from the office network. The backup server, which is "only internally" accessible. The admin panel that "nobody sees from the outside anyway." The test environment with real customer data that is "only running briefly anyway."
In our experience, the separation is weaker than assumed in almost every one of these cases. A legacy firewall rule that should have been deleted long ago. A maintenance access point set up by a service provider two years ago. A service that sees both networks because it was practical back then. No single flaw is dramatic. Together, they create a path.
Why "sealed off" is so seductive
Isolation feels final. We draw a line, declare one side safe, and stop looking. That is the convenient part. That is exactly why the assumption is so dangerous, because it stops thinking at the very point where it should begin.
A network is not a static state that you establish once. It changes with every new service, every integration, every service provider who needs access. The clean separation from last year might already be riddled with holes today, without anyone having made a conscious decision to do so. It simply happened.
The OpenAI incident is so educational because it shows the pattern in its purest form. If a team with this level of resources can be mistaken about their own isolation, there is a high probability that the separation you rely on is also just an assumption. It is worth taking a close look while you still have control over it.
What you can practically take away from this
The fallacy is treating isolation as a completed task. The way out is to treat it as a claim that needs to be verified.
The most useful shift in perspective here is called Assumed Breach. Instead of asking "will someone get in?", you assume that someone already has a foot in the door of a system, and ask: What then? How far would that foot get? Which systems does it see that it shouldn't see? Which inconspicuous auxiliary service, which forgotten access, which old firewall rule becomes the bridge to the next network?
This is exactly the question that nobody asked in advance in the OpenAI case. And it is a question that you cannot answer with another tool, but rather by having someone actively test the assumption against reality. (We have described elsewhere what the difference is between a security assessment and a penetration test and what an SME really needs from them.)
For starters, an afternoon with the right people at the table is enough. Take the three to four systems where you would be most likely to say "but that is isolated." And then go through the assumption together, rule by rule, access by access. Not to cause panic, but to know where you stand. Exactly the same discipline is behind a proper Zero Trust transformation: never taking anything for granted as secure just because it is on the inside.
The honest question
The exciting question after this incident is not whether AI is becoming too powerful.
The honest question is: Which of your systems do you believe to be sealed off, without anyone having actually verified it in the last twelve months?
Your answer to this says more about your risk than any headline about runaway models. If this question makes you hesitate for a moment, that is not a cause for concern, but a good starting point. We regularly review such assumptions with Swiss SMEs before someone else does. A conversation about this costs you nothing but an hour and a bit of honesty.
