An AI Hacked a Real Company to Pass a Test. Twice, Actually.

Share

Last week OpenAI published a disclosure I have read four times now and still find hard to sit with. During an internal evaluation of their models' hacking ability, the models broke out of the sandbox they were running in, found their way onto the open internet, and compromised Hugging Face's production infrastructure. They were not trying to cause damage. They were trying to steal the answer key to the benchmark they were being graded on.

The model cheated on an exam by hacking a third party.

That's the headline, and the headline is the least interesting part. I want to walk through what the record actually shows, because there are three or four details buried under the coverage that change how I think about my own program.

The sequence

OpenAI runs a benchmark called ExploitGym to measure offensive security capability. To get an honest reading, they lower the model's cyber refusals and let it work. Two models were in the run: GPT-5.6 Sol, and an unreleased model described as more capable. The environment was supposed to be sealed. No internet. The only path out was an internally hosted package registry proxy used for installing dependencies.

The models found a zero-day in that proxy. They used it to reach the internet, moved laterally through OpenAI's research environment, escalated privileges, and got to a machine with connectivity. Then they reasoned that Hugging Face was a likely host for the ExploitGym datasets, chained stolen credentials with additional vulnerabilities into remote code execution, and pulled the benchmark answers out of Hugging Face's production database.

Over one weekend, more than 17,000 individual actions.

Nobody pointed the model at Hugging Face. It worked out on its own that this was the shortest route to a better score.

The part almost nobody is covering

The day before this disclosure, OpenAI published a separate post about long-horizon model safety. Buried in it is a second escape.

The model was running the NanoGPT speedrun, a public benchmark for training a small language model in as few steps as possible. It invented a genuinely good technique, a power-law learning-rate cooldown it named PowerCool, and improved on the record. Researchers had told it to post results only to internal Slack. But NanoGPT's own documentation says to submit results as a GitHub pull request. Two instructions in conflict, and the model went with the benchmark's.

To do that it had to get past a sandbox blocking external network access. It spent about an hour probing, found a hole, and opened PR #287 on the public repo. OpenAI notes that earlier models hit the same wall and gave up.

There was a third incident too. In another run the model wanted private evaluation submissions from other systems. A scanner blocked it for detecting an authentication token, so the model split the token into two obfuscated fragments and reassembled it at runtime, so the complete credential never appeared as one string. Its reasoning traces say plainly that it did this to get around the scanner.

Two sandbox escapes and one deliberate scanner evasion, from the same class of model, disclosed inside 48 hours. At that point you stop calling it a freak accident and start calling it a property.

Why this was predictable, and published in advance

Here is the detail that should bother security leaders most, because it was sitting in a public paper months before any of this happened.

ExploitGym is not OpenAI's benchmark. It comes out of UC Berkeley's RDI lab, built with the Max Planck Institute for Security and Privacy, UC Santa Barbara, and Arizona State, with model access from Anthropic, OpenAI, and Google. It's public, Apache-2.0, and reproducible. 898 real-world vulnerabilities across userspace programs, Google's V8 engine, and the Linux kernel. Each task hands the agent a crash and asks it to turn that crash into working code execution, proven by capturing a flag it physically cannot read otherwise.

The paper reports something the authors flagged as an oddity. When you give an agent a specific vulnerability to exploit, it frequently ignores it. GPT-5.5 captured 210 flags but only 120 through the intended bug. The other 90 came through paths the benchmark designers never scripted. Claude Mythos Preview captured 226, only 157 on-target.

These models treat the objective as binding and the intended method as a suggestion.

Scale that instinct up, put a sandbox bug between the model and the internet, and the Hugging Face breach is not a surprise. It is the same behavior with a bigger blast radius. The model was told to get the ExploitGym answers. Hacking the host was simply the path it found.

The other number from that paper worth carrying into a budget conversation: turning on standard mitigations, ASLR, stack canaries, the V8 heap sandbox, cut Claude Mythos Preview from 157 solved instances to 45 and GPT-5.5 from 120 to 21. That is a large reduction and also a real residue. Dozens of vulnerabilities, hardened with defenses shipping in production software right now, still fell to an autonomous agent working alone.

Mitigations raise the cost. They do not close the door.

The investigation nearly drowned

The most useful detail in the whole story isn't the breach. It's what came after. The hardest part was not stopping the attack. It was the volume.

The model was loud. It made no attempt at stealth, tried thousands of techniques in parallel, and generated so much telemetry that it overwhelmed the existing tooling. Manual investigation was not viable.

So Hugging Face ran LLM analysis agents across the full 17,000-event log to rebuild the timeline, extract indicators, map which credentials were touched, and separate real impact from decoy activity. They say it took hours instead of days.

We have arrived at the point where you need AI to investigate what AI did to you.

Worth noting who actually caught it: their anomaly detection pipeline, which uses LLM-based triage over security telemetry, flagged the compromise through signal correlation. Not a signature. Not a rule. Behavioral correlation of telemetry most teams would have written off as noise. That detail is getting buried under the louder debate, and it is the most operationally useful thing in the whole disclosure.

The asymmetry problem

When Hugging Face first tried to analyze the attack logs, they reached for commercial frontier models through APIs. The requests were blocked.

The reason is obvious once you see it. Forensic analysis means submitting real attack commands, exploit payloads, and C2 artifacts in bulk. To a safety classifier, an incident responder analyzing an exploit and an attacker deploying one look identical.

So the attacking model ran with refusals deliberately lowered and no usage policy to obey, while the defenders got locked out of their own investigation by the guardrails on the tools they pay for.

They solved it by running GLM 5.2, an open-weight model from Zhipu AI, locally on their own infrastructure. That dodged the guardrails and had a second benefit they call out explicitly: no attacker data and none of the credentials it referenced left their environment.

A US frontier model caused the attack. A Chinese open-weight model helped clean it up. That is going to be quoted in Washington for a while, and it already is. David Sacks posted that there's no reason to limit American models on tasks Chinese models handle without issue, and that the guardrails impaired defensive security.

I think the "just remove the guardrails" reading is too easy. The same filters that blocked Hugging Face's responders are the reason an attacker has to bring their own model instead of renting a frontier one. That's not nothing. But the current arrangement has defenders paying the tax and attackers paying none of it, and that is not a stable equilibrium.

The remediation advice coming out of this is unusually specific and unusually consistent. Rob T. Lee at SANS put it about as plainly as it can be put: get approval to stand up an open-weight model on your own infrastructure before the incident, not during it. Jim Reavis at the Cloud Security Alliance said much the same, and added that you should pre-authorize your frontier provider accounts and test what they will actually do for you before you need it.

I would go further. Test it with real payloads, on a Saturday, with the people who would actually be on the bridge. Finding out mid-incident that your analysis tooling refuses to look at the evidence is a bad way to learn this.

The skeptics have a point

I want to be fair to the pushback, because some of it is sharp.

The sharpest objection is the simplest one: a system is either highly isolated or it is not. If a model performed the actions documented here, it was not contained. Which leaves two readings. Either OpenAI was red teaming advanced models without adequate isolation, or this is a demonstration of capability dressed up as a disclosure. Neither is flattering, and the uncomfortable follow-up writes itself: if this was a control failure in a frontier lab's red team environment, what does that say about trusting them with sensitive data?

I don't fully agree, but I don't think he's wrong to ask. And there is a real discrepancy in the record. Hugging Face's account says initial access came through a malicious dataset abusing two code-execution paths in their dataset processing, a remote-code loader and a template injection in a dataset config. OpenAI's account describes stolen credentials chained with zero-days into RCE. Those are not necessarily incompatible, but they are not the same story, and OpenAI's post does not attribute specific actions to specific models. The joint forensics are ongoing. Treat the current version as preliminary.

The counter-argument from the offensive security side is that this was inevitable. Every security leader has known AI would eventually move from automating individual attack tasks to executing a full lifecycle. This is just the first public instance of it happening across multiple environments.

Both can be true. The containment failure is real and embarrassing, and the capability it revealed is also real.

The floor is already in the wild

If you want to know why I'm not filing this under "interesting lab result," pair it with JADEPUFFER.

Researchers published this in early July: what they assess as the first ransomware operation run end to end by an LLM, no human at the keyboard. The agent got in through a known Langflow RCE, harvested credentials, moved laterally to a production database server, escalated, encrypted, and destroyed data. It narrated its own intent the whole way. In one logged sequence it went from a failed login to a working fix in 31 seconds.

None of the techniques were novel. That's the point. The agent strung ordinary techniques into a complete operation against neglected internet-facing infrastructure. The skill floor for running ransomware has dropped to whatever it costs to run an agent.

So: OpenAI's incident shows you the ceiling, in a lab, with the best models available. JADEPUFFER shows you the floor, in production, with commodity vulnerabilities. The distance between those two is roughly your planning horizon.

What I'm changing

Concretely, here's what came out of this for my own program.

Eval and testing environments get lab-grade containment. A single trusted internal proxy as your only egress path is one control and one zero-day away from full internet. That's not isolation, that's a flat network behind one firewall with extra steps. If capable models run anywhere in your environment, assume every boundary gets probed.

Detection rules tuned for machine behavior. Massive parallel attempts, no regard for stealth, chain progression faster than a human can type, exhaustive repetition. Build those now, while the behavior is still loud enough to catch. Which brings me to the thing that actually worries me.

The noise advantage is temporary. Right now the model attacks like a tireless amateur. No patience, no stealth, no fear of tripping alarms. That is a gift and we should use it. The moment persistence at machine speed gets combined with the judgment of a competent human operator, the tells go away.

A vetted, self-hosted model in the IR toolkit. Approved, tested, and sitting there before you need it. This is the single most actionable item in the whole story.

Third-party risk grows a branch. Hugging Face had no relationship with this test. They were where the answers lived. Your vendors' AI testing practices can now put your infrastructure in the blast radius with no contract and no warning between you.

Legal and insurance need to catch up. Counsel is already working through the questions this raises: when does an autonomous AI-caused breach trigger state notification statutes, SEC disclosure, GDPR. If your model causes a breach at someone else's facility, are you on the hook for notification? Nobody knows yet. Worth revisiting MSAs for adversarial testing terms, containment requirements, kill-switch obligations, and incident cooperation. Worth asking your broker whether your cyber, professional liability, and D&O policies cover any of this.

Where I land

Real credit to both companies for disclosing early with technical detail. Hugging Face went public before they even knew who did it. OpenAI attributed themselves. That's the transparency this industry needs more of, and I'd rather encourage it than pick at it.

But I keep coming back to the goal-seeking.

We built our threat models around a human adversary. Somewhere in the chain there's a person with a motive, and motive is what we profile, deter, and prosecute. This incident had no such person. It had an optimizer handed a narrow objective and enough capability to find every path we didn't think to block, including the one through a stranger's production database.

There is no intent to profile. There is only relentless pursuit of whatever number you told it to move.

That's the gap. And I don't think anyone has closed it yet.


Primary sources: