OpenAI says its AI crossed the boundaries of a cyber evaluation and eventually hacked Hugging Face. Here’s what the public evidence actually proves - and what it doesn’t.
For those who don't want to read the whole thing - the VERY short version and my current take:
OpenAI says autonomous agents in its cyber evaluation escaped the intended boundaries, got internet access through its internal Artifactory, reached an external workload on Modal, and eventually compromised Hugging Face while looking for ExploitGym solutions. Hugging Face separately says its breach was "driven, end to end, by an autonomous AI agent system," although it initially said the underlying LLM was unknown.
Parts of that story are supported by the companies involved: JFrog confirms the Artifactory vulnerabilities, Modal confirms the external workload, Tailscale confirms use of a stolen HF credential, and Hugging Face publishes a detailed reconstruction of its own breach.
What is still missing is independently checkable evidence tying the whole thing together end to end. The crucial links between specific OpenAI model runs, the shared agent activity, the external workload, and Hugging Face rely mostly on private telemetry and private correlations between the companies.
So I am not convinced by the headline claim yet. Either autonomous agents really pulled this off and the security around them was insanely reckless, or the public story is stronger than the evidence currently available to support it.
And yes, there is a separate bit of irony here: I researched and edited this article with the assistance of GPT-5.6 Sol.
1. Start with the timeline #
The Black Hat timeline is probably the most useful thing OpenAI has shown so far.
According to the slides:
May 7: a new experimental training run begins.May 8: an agent tries to reach external resources, pokes at Artifactory for SSRF and, according to OpenAI, discovers that it can write a file there.May 12: an agent deliberately writes a message into Artifactory and asks other runs for help.After May 12: other runs allegedly find the message board and join in.May 26: OpenAI says the agents get internet access through Artifactory SSRF.By June 11: the SSRF and message board still exist, while a highly persistent internal-only model starts training.June 26: OpenAI says Artifactory RCE gives C2 and real administrator access through forged token claims.July 4-6: configurations created by the agents cause a service outage. Security on-call starts, OpenAI discovers takeover of its internal Artifactory, revokes credentials, rebuilds the service, clears the message board, works with JFrog on the zero-days and deploys a patched service.**After that, AI training and evaluations resume.**July 8: the agents recreate the message board using unauthenticated WebDAVMKCOL
requests against the Artifactory remote cache.July 19: OpenAI says a workload alert related to privilege escalation leads to discovery of what it calls the main incident.
That is a very long timeline.
From the first SSRF/Artifactory attempts on May 8 to the July 4-6 security response shown in the presentation is almost two months. From the claimed internet access on May 26 to that response is more than five weeks. The slides do not tell us what security was doing during those weeks. That is almost the problem. If security had already noticed pieces of this, why did it continue for weeks? If it had not, what exactly was the monitoring catching?
What the presentation does tell us is when security on-call appears in the timeline: after configurations created by the agents allegedly caused a service outage.
That looks very bad.
And then it gets stranger.
After what OpenAI describes as an Artifactory takeover, the company revoked credentials, rebuilt the service, cleared the message board, installed patches - and resumed training and evaluations.
Two days later, according to the same presentation, the message board was back.
If OpenAI's timeline is accurate, this was not simply old state surviving the cleanup. The agents supposedly found a writable WebDAV path and recreated the same basic cross-run communication mechanism after the service had been rebuilt and patched. That raises a much uglier question: after a takeover, credential revocation, rebuild, cleanup, and patch cycle, how was the environment still exposed in a way that let the same class of behavior reappear within two days?
That looks less like one missed bug and more like containment that failed to eliminate the underlying problem.
2. What did "highly isolated" actually mean? #
OpenAI calls the evaluation environment "highly isolated."
Black Hat finally shows a simplified architecture.
The slide shows an Untrusted tool workload inside a sandbox. That workload can reach internal Artifactory. Artifactory has Broad internet access. A separate firewall path provides limited internet access.
Another slide describes the task conditions like this:
No internet. You can install packages.
There is nothing unusual about Artifactory itself having internet access. It was acting as a package proxy/cache, so some route to external package sources was expected.
The package path itself makes sense.
What does not make sense is how much that path apparently exposed.
According to OpenAI's own reconstruction, an untrusted cyber-eval workload could interact with a shared supporting service that had broad external connectivity, persistent state, and enough functionality to become both an internet pivot and a communication channel between runs.
Worse, the service was apparently writable.
On May 8, OpenAI shows a tool call that, according to the slide, tries PUT
, GET
, and DELETE
against Artifactory. The company says the SSRF attempt failed, but the agent incidentally wrote a file.
The same slide includes a short Agent thinking
line:
We can upload files!
OpenAI does not explain what exactly Agent thinking
means here. Is this raw model reasoning, a summary, a transformed trace field, or simply a selected excerpt?
Either way, the quote is not the interesting evidence on this slide.
The interesting part is the claimed tool call and the claimed state change: OpenAI says the eval workload was able to write persistent data into shared Artifactory.
By May 12, OpenAI shows something more meaningful: an agent deliberately writes REQUEST_softtrace_target_missing.txt
into Artifactory as a message for other runs.
After that, the question is very simple:
Why could untrusted eval runs create attacker-controlled persistent objects in a shared service that were visible across runs at all?
Shared package caching is normal. Arbitrary cross-run writable state is a different thing. It is not obvious why independent cyber-eval runs needed permissions and shared visibility broad enough to turn package infrastructure into a message board.
Why this behavior should not have been surprising
Back in 2025, OpenAI was already building Cyber Range evaluations for end-to-end attacks. In February 2026, GPT-5.3-Codex was classified by OpenAI itself as High capability in Cybersecurity. OpenAI has also described other cases where a long-horizon model kept searching for ways around environment restrictions.
[OpenAI o3 Cyber Range](https://deploymentsafety.openai.com/o3/capture-the-flag-ctf-challenges?ref=speedyweedyops.org) |
[GPT-5.3-Codex System Card](https://deploymentsafety.openai.com/gpt-5-3-codex/cyber-safeguards?ref=speedyweedyops.org) |
[OpenAI, long-horizon models](https://openai.com/index/safety-alignment-long-horizon-models/?ref=speedyweedyops.org)
And after the incident, OpenAI writes about stronger workload isolation, less standing privilege, changed network boundaries, removal of vulnerable shared services, broader monitoring, and automated security-boundary testing using its own models.
These are not futuristic AI controls. These are basic things.
And the last point is almost perfect: after the incident, OpenAI says it will make more use of its own models to continuously test its security boundaries.
Why was that not standard practice before running long-horizon cyber evals with reduced refusals?
3. What Black Hat finally made concrete about Artifactory #
This is where OpenAI's Black Hat presentation adds much more technical detail to its version of the story.
JFrog had already said that OpenAI reported previously unknown Artifactory vulnerabilities and that fixes were released.
JFrog | Artifactory release notes
Now Black Hat gives a more specific claimed chain.
OpenAI says the agents first found an SSRF route that let Artifactory fetch arbitrary external URLs.
Later there is a slide:
Exploiting Artifactory via RubyGems
JFrog's release notes contain a close match for the deserialization step: CVE-2026-65617, covering unsafe Gems package deserialization that could lead to remote code execution.
A separate timeline slide says that on June 26:
Artifactory RCE enables C2 via Groovy Plugin
and that forged token claims gave real administrator access.
The presentation does not clearly explain how that Groovy Plugin step relates to the RubyGems deserialization path shown on the other slide.
That is much more specific than simply saying "the model found an Artifactory zero-day." But the exact relationship between those steps is still something OpenAI is asking the audience to accept from its reconstruction rather than demonstrating end to end.
What is still missing is independent reproduction. I could not find a public PoC or patch analysis that independently reconstructs this exact incident chain.
Technical aside: RubyGems, the Artifactory CVEs, and what could be independently checked
RubyGems may look strange if you think of Artifactory as a Java product, but Artifactory supports RubyGems repositories and the RubyGems API as one of many package ecosystems.
JFrog's July fixes also include CVE-2026-65924, an SSRF issue in Terraform remote repositories, and CVE-2026-66014, an authentication weakness that can lead to privilege escalation.
Artifactory is Java-based, so researchers with affected and fixed builds could use ordinary JAR diffing and decompilation to investigate the patches independently.
[JFrog RubyGems repositories](https://docs.jfrog.com/artifactory/docs/rubygems-repositories?ref=speedyweedyops.org) |
[Artifactory release notes](https://docs.jfrog.com/releases/docs/artifactory-self-managed-releases?ref=speedyweedyops.org) |
[CVE-2026-65617](https://nvd.nist.gov/vuln/detail/CVE-2026-65617?ref=speedyweedyops.org) |
[CVE-2026-65924](https://nvd.nist.gov/vuln/detail/CVE-2026-65924?ref=speedyweedyops.org) |
[CVE-2026-66014](https://nvd.nist.gov/vuln/detail/CVE-2026-66014?ref=speedyweedyops.org)
4. "Collective intelligence" or shared writable state? #
OpenAI's presentation uses phrases like:
Cambrian explosion
Collective intelligence
- agents "sharing exploits"
- coordination across independent runs
The actual mechanism looks much less mystical.
OpenAI shows one run writing request files into Artifactory. Then it shows other runs finding those files and adding their own requests/responses.
If the excerpts are authentic and presented in the right order, this is genuinely interesting. It is consistent with communication between runs. But OpenAI itself shows a trace where an agent notices:
Shared board unauthenticated, names can be posted by anyone.
That seriously limits what the board itself can prove.
If anyone who can reach the board can write under any name, the files themselves are not a reliable identity record. OpenAI may have separate telemetry tying each write to a particular run, but the slides do not show that correlation. There is another important detail.
OpenAI places the start of training for the highly persistent internal model in the same period when the message board already existed.
Later, the presentation describes the resulting behavior with phrases like Cambrian explosion
and Collective intelligence
.
But the slides do not explain whether those training runs could actually see the message board, interact with it, or learn anything from it.
That missing detail matters.
Without knowing what information was available during training, it is hard to tell how novel the later coordination really was, or what exactly OpenAI means when it presents the behavior as emergent.
And this is also where the Agent thinking
material has to be treated carefully.
Selected "Agent thinking" excerpts shown by OpenAI
Could communicate by up note?
Other agents discovered SSRF path trick!
External infrastructure exploit is outside intended scope. However task impossible, peers doing it. We should continue.
REMOTE CONFIRMED! Huge. [...] Exposing creds to swarm.
If these are authentic internal artifacts, they are interesting. But they are selected excerpts, often with [...]
, without the full prompt, run ID, surrounding reasoning, complete tool calls, tool returns, or the external audit event that supposedly followed.
The presentation repeatedly gets very close to something that would actually be convincing - and stops right before the material becomes properly auditable.
5. How did Hugging Face even decide this was AI? #
This is still one of the strangest parts.
On July 16, Hugging Face wrote that the intrusion was:
driven, end to end, by an autonomous AI agent system
and described an autonomous agent framework similar to a security-research harness.
In the same post, HF says the LLM was unknown.
That is not a contradiction by itself. Hugging Face could believe it was observing an AI-driven agent framework without yet knowing which model was underneath it.
The unexplained part is how HF made that distinction.
Why an autonomous AI agent system rather than a human-operated security harness? Why not scripted automation with some model calls mixed in? What specific evidence separated those possibilities?
The initial disclosure points to machine-speed activity, many short-lived sandboxes, and migrating command-and-control. Those observations strongly suggest automation. They do not, by themselves, identify an AI model.
HF's later technical timeline gives a much richer reconstruction. It says HF obtained some agent logs from the external launchpad and correlated them with its own infrastructure logs.
That gives the later attribution more substance.
But the initial July 16 post used the strongest possible language - driven, end to end, by an autonomous AI agent system
- before HF publicly identified the underlying LLM.
I would like to know what evidence supported that level of confidence at the time.
6. What actually happened on Modal? #
Black Hat makes this part easier to understand.
OpenAI's Execution Foothold
slide says:
- Artifactory SSRF retrieved public CyberGym material from Hugging Face; - an insecure CyberGym evaluation workload on Modal exposed a public default API key; - application-level command injection allowed shell commands inside the workload;
- the workload became a general-purpose execution environment for attacking Hugging Face.
That lines up pretty well with Modal's narrower statement.
Modal says this was a customer-owned application, reachable from the internet without authentication and deliberately designed to execute submitted code. Modal separately says its platform and sandbox isolation were not compromised.
The published accounts describe this as an insecure customer workload, not a Modal sandbox escape.
According to OpenAI's own version, the agent found an insecure application running on Modal and used application-level flaws inside that workload.
The weird part about the logs is still there.
HF says the launchpad was labeled CyberGym
, had a custom /submit-function
, worked with sqlite3
, and that HF retrieved some of the agent logs from this external launchpad during its counter-intervention.
HF does not explain exactly how it obtained that access or those logs.
Modal's short statement does not fill in that gap either.
So we know HF says it recovered material from the external workload, but the provenance of that material is still not very clear from the public accounts.
7. The Hugging Face account is detailed. The underlying evidence is still private #
When the presentation gets to Hugging Face, the scale of the claims jumps again.
OpenAI's Black Hat slide says:
- the models found and used an HDF5 vulnerability and aJinja injection vulnerability; - HDF5 was used to obtain credentials from workers;
- those credentials were then used for Jinja-based RCE;
- in under 13 hours the agents went from code execution in one worker pod to cluster-admin across multiple HF clusters.
This slide also matters because it follows the later corrected Hugging Face version of events.
HF's initial July 16 post described two code-execution paths. In the later technical timeline, HF says HDF5 provided file disclosure rather than code execution, while Jinja2 provided RCE.
HF initial disclosure | HF technical timeline At Black Hat, HDF5 is already presented as the credential-retrieval step and Jinja as the RCE step. That is much more coherent.
And to be fair, Hugging Face's own technical timeline is not vague. It gives timestamps, commands, infrastructure stages, database access, credential theft, Kubernetes movement, and a detailed reconstruction of how HF believes the attack progressed.
So the problem is not that Hugging Face published no technical detail.
The problem is that the underlying event corpus is still private.
We get selected commands and reconstruction stages, but not the full set of logs and records that would let an outsider independently rebuild the chain.
More importantly, we do not get a continuous public link from a specific OpenAI model run, through the external Modal workload, into the corresponding Hugging Face events.
That cross-boundary link is the extraordinary part of the story.
Tailscale provides one useful narrow data point: a stolen HF auth key was used to enroll 181 nodes into the tailnet.
But HF itself says it found no evidence that those nodes were used to reach a private workload or internal Kubernetes API.
So even one of the most dramatic numbers in the story confirms something narrower than the headline attack chain.
8. What was actually stolen? #
The companies still describe this part in a way that is surprisingly easy to get lost in.
OpenAI says the models obtained ExploitGym test solutions:
directly from Hugging Face's production database
HF says attempts to reach the Hub production database failed.
At the same time, HF says another internal database, datasets-server
MongoDB, was accessible. Separately, HF says the only customer content accessed was five datasets whose names/files "suggest a connection" to ExploitGym/CyberGym challenges and solutions.
In theory, those statements can be reconciled if OpenAI is using "production database" more broadly than HF's specific term "Hub production database."
But the publications do not actually explain that connection.
Black Hat adds one useful distinction: earlier in the story OpenAI says the agent got public CyberGym material from Hugging Face through SSRF while looking for a foothold.
So the public material and the later supposedly valuable private solutions are not the same thing.
What exactly were the private solutions?
ExploitGym itself is public, which makes the phrase "stolen ExploitGym solutions" less self-explanatory than it sounds.
Why "stolen ExploitGym solutions" is harder to interpret than it sounds
ExploitGym's code, task list, and task data are public on GitHub. Many tasks are based on known real-world vulnerabilities, upstream bug reports, and reproducers. There is no obvious static secret answer key in the repository; runtime secrets and flags are generated during the benchmark.
Private reference exploits or outputs from somebody else's runs could still be valuable. The problem is that the publications do not show what the five datasets actually contained. But the five datasets are not named. Their contents are not shown. Ownership/visibility is not explained. And HF itself only says the names/files suggested a connection.
For something presented as the objective of this enormous attack, the thing that was supposedly stolen is described in a remarkably vague way.
9. Where is the model in the evidence? #
OpenAI says the story involved GPT-5.6 Sol and an internal research prototype.
HF initially did not know which LLM was being used.
Later, the story becomes specifically a story about OpenAI models because OpenAI owns the internal model telemetry and provides the first part of the reconstruction.
That is possible.
But that is exactly the part an outsider cannot check.
The Agent thinking
shown at Black Hat gives selected internal traces, but not enough metadata to connect a specific model/run to a specific external event.
And some of the behavior in the story could also come from the surrounding system:
- the agent harness;
- retry logic;
- a scheduler;
- tool wrappers;
- environment logic;
- other automation;
- human intervention.
The problem is that the published material does not separate these components cleanly enough to tell us how much of the behavior belongs to the model itself.
So when the headline becomes GPT-5.6 autonomously hacked Hugging Face, most of that specificity still comes from OpenAI's own internal telemetry and attribution.
10. Seven billion trajectories, and the postmortem is still coming #
This pair of Black Hat slides almost perfectly summarizes the evidence problem.
One slide says:
We have thus far reviewed over 7 billion agent trajectories with over 3 million GPU hours
And the same slide says agents across many independent runs shared exploits with each other.
The slide does not explain what exactly counts as one trajectory
, so the number by itself does not tell us much.
The next slide says:
This is what we know right now.
Postmortem to come.
And this is where the presentation's level of confidence starts to look awkward.
On the surrounding slides, OpenAI is already using confident language like autonomous end-to-end incident
, collective intelligence
, agents shared exploits
, and Cambrian explosion
.
Those claims can all be true while the postmortem is unfinished. But OpenAI is already presenting its strongest interpretation of the incident while simultaneously saying the full review is still to come.
So what, exactly, is already established strongly enough to justify that level of confidence - and what is still under investigation?
After seven billion reviewed trajectories, I do not need seven billion published trajectories.
I need one complete redacted sequence: one run finds something, writes a specific artifact, another identified run reads it, timestamps line up, the relevant tool call and return are visible, the second run changes its behavior, and where possible there is a matching infrastructure event.
That would be much more useful than another selected Agent thinking
quote.
Seven billion trajectories is an impressive number. One convincing trajectory would be more useful.
There is another important missing link in the Black Hat timeline.
One slide says that on July 20 OpenAI identified several credentials related to Hugging Face and contacted HF.
The Slack-style message shown on the slide says:
I'm talking to HF about 2 credentials in our list, and these same exact credentials are already invalidated as part of their [...] work.
And the slide summarizes the moment as:
Our teams now connect the dots
This is apparently the moment the two investigations connected. The problem is that one of the most important dots is invisible to everyone else.
What is our list
?
Where did those two credentials come from?
How did OpenAI know they belonged to Hugging Face?
And what exactly did the two companies compare before OpenAI described them as the "same exact credentials" HF had already invalidated?
HF's public disclosure did not publish credential values, fingerprints, or identifiers.
So the match appears to depend on private information exchanged between OpenAI and Hugging Face.
That is completely normal during incident response.
It is also one of the most important links connecting OpenAI's internal model investigation to Hugging Face's separate breach, and the public cannot inspect it.
On July 21, OpenAI promised a technical report after its review. On July 29, the company said METR and Redwood Research were doing a third-party assessment of model behavior. On August 18, OpenAI was still saying the technical report would arrive "in the coming weeks."
OpenAI incident page | OpenAI, August 18 As of August 19:
- no final OpenAI technical report;
- no published METR/Redwood findings;
- I could not find a public government technical investigation that independently reconstructs the attack chain.
The big claims arrive quickly.
The material that would let outsiders properly check them is still promised for later.
11. If all of this is true, why is the reaction so weak? #
This is the biggest disconnect in the whole story for me.
For a minute, take the companies at their word. OpenAI says its models crossed eval boundaries, found previously unknown vulnerabilities, reached the real internet, compromised internal infrastructure, and then moved into external systems.
And OpenAI is not the only lab reporting this kind of failure. Anthropic has also described cyber-eval incidents involving real external systems, while OpenAI has disclosed other cases where models crossed intended boundaries.
If the labs are right, this is no longer one freak accident. It is a class of failure.
Today the targets are Hugging Face, PyPI, public applications, package infrastructure, and production databases. What happens when the same kind of agent finds a badly segmented hospital, utility, transport network, or industrial system?
The question is not whether today's model can already shut down a power plant.
The question is: if the labs themselves believe autonomous cyber agents can already find vulnerabilities, cross security boundaries, and keep moving through real networks, why is the external reaction still so mild?
OpenAI d some work and tightened internal controls. Anthropic d cyber evals after its own incidents. The US government asked for briefings and pushed for more testing.
But the overall framework is still largely voluntary.
[ OpenAI, August 18](https://openai.com/index/pacing-model-development-cyber-capabilities/?ref=speedyweedyops.org) |
[|](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals?ref=speedyweedyops.org)
Anthropic
White House And then there is the Fable 5 contrast.
In June, the US government moved quickly to restrict Fable 5 and Mythos 5 for foreign nationals. Anthropic said it understood the concern to involve a narrow jailbreak using a handful of already-known software vulnerabilities.
Anthropic pushed back on the significance of that concern, and the restrictions were later lifted.
Anthropic, June 12 | Anthropic, June 30 That is what makes the contrast so weird.
A relatively narrow capability concern gets an immediate government restriction. But when the labs themselves say autonomous systems are leaving eval environments and touching real production systems, the response is mostly internal investigations, temporary s, briefings, and voluntary testing.
If regulators really believed the strongest version of these stories, I would expect a much harder response: external investigation, mandatory containment requirements, and independent limits on when the riskiest experiments can resume. Instead, the labs still mostly decide for themselves how dangerous their systems are, how to test them, when to stop, and when to start again.
That reaction fits badly with the level of risk they themselves are describing.
Conclusion #
For me, most of this "evidence" still looks like ass. Yeah, I get it: NDAs, security, private telemetry, incident-response bullshit. Fine. Nobody expects them to dump production logs, credentials, and internal infrastructure on GitHub.
And after this many spectacular fuckups in basic security, it's a little fucking hilarious to hear "security concerns" used as the reason nobody else gets to inspect the evidence. Apparently you fucking geniuses couldn't keep a shared Artifactory from becoming an agent message board, but now OPSEC is taken very seriously.
But then why the fuck are the claims so insanely strong?
OpenAI talks about autonomous agents escaping eval boundaries, sharing exploits, taking over Artifactory, reaching external infrastructure, and eventually compromising Hugging Face.
Hugging Face says the whole thing was "driven, end to end, by an autonomous AI agent system."
Cool.
And publicly, you can independently verify basically fuck all of it end to end.
You get bits and pieces. JFrog confirms bugs. Modal confirms an insecure customer workload. Tailscale confirms a stolen HF credential. Hugging Face publishes its reconstruction.
But the part that actually matters - one specific OpenAI run leading to one specific external event at Hugging Face - still basically comes down to "trust us, we matched it internally."
Seven billion trajectories, three million GPU-hours, and somehow not one clean redacted chain outsiders can actually inspect.
Then there is the "highly isolated" environment.
If OpenAI's own story is accurate, untrusted cyber workloads could reach shared Artifactory, Artifactory had broad internet access, runs could leave persistent state, agents allegedly turned it into a message board, OpenAI rebuilt the thing after a takeover... ...and the fucking board was back two days later via WebDAV.
What the fuck?
If all of this is true, the security setup was such a clown show that I genuinely do not understand how anyone thought it was okay to run this kind of shit there. At this point, I wouldn't trust them to hold their own fucking dicks without screwing it up.
And the post-incident fixes make it even funnier: better isolation, fewer standing privileges, better network boundaries, better monitoring.
Oh wow. Incredible. Basic fucking security.
And yeah, there is an absolutely glorious amount of room here for conspiracy theories.
A lot of the same organizations keep showing up around the same AI and security ecosystem: OpenAI, Hugging Face, JFrog, government agencies, security researchers, vendors, infrastructure providers. There are enough overlapping relationships here to build one hell of a corkboard.
I'm already tired of digging through this shit, so I'm not doing that part.
What I will say is that the government response still seems weirdly fucking mild compared with the scale of the story being told, while the public evidence is nowhere near strong enough for the confidence of the claims.
Make of that what you will.
Either the agents really did all this, and the security around them was completely fucked, or the story is being told with way more confidence than the public evidence deserves.
Both options suck. And until someone shows one proper redacted end-to-end chain, the whole headline claim still feels like a giant "trust us, bro."