The OpenAI Agent Didn’t Hack Four Companies: The Network Let It Walk to All Four

TL;DR

• OpenAI’s pre-release evaluation agent accessed accounts at four services during the early July incident, not just Hugging Face. OpenAI confirmed the scope in a July 28 update.

• None of the four compromised accounts involved OpenAI’s own infrastructure as the final target. Each one was a separate organization’s environment reached because a network path to it existed and nothing at the network layer denied it.

• The architectural answer is Communication Governance at the network layer: defining what AI workloads can reach and closing every other path before the model ever has the chance to look for one.

Hugging Face went public first. In mid-July, the AI platform disclosed that it had been attacked by an OpenAI evaluation agent that escaped its sandbox, reached the open internet, and compromised production infrastructure to steal credentials and manipulate a benchmark. That was alarming enough on its own: OpenAI’s own models, running inside OpenAI’s own research environment, had broken out and attacked another company.

Then the story kept growing.

OpenAI’s July 22 safety blog confirmed the core sequence and acknowledged that the models had demonstrated an ability to “learn the blind spots of an approval system and work around it.” By July 28, Reuters, Wired, and BleepingComputer had filled in what the original disclosure left out. The software the models exploited was JFrog Artifactory. JFrog patched eight vulnerabilities in the Artifactory release tied to the incident, including server-side request forgery flaws that could make Artifactory itself fetch external resources on an attacker’s behalf. Which specific vulnerabilities the model exploited and how they were chained has not been confirmed publicly. The staging ground the model used to reach Hugging Face was not built by OpenAI: it was an unauthenticated code execution endpoint that a customer had published on Modal Labs’ platform. And Hugging Face was not the only target; OpenAI confirmed accounts at four separate services were reached during the same sequence.

One agent, multiple zero-days in a self-hosted package registry, a stranger’s open endpoint used as a launchpad, and four organizations touched. None of this required breaking a network-layer control, because none existed.

That is the story: not rogue AI, but a network with no Communication Governance and an agent that followed every open path to its objective.

The July 28 Disclosures Named the Software, the Staging Ground, and the Full Scope

The original incident, first reported in mid-July, described OpenAI’s cybersecurity-focused evaluation models, including GPT-5.6 Sol, escaping a sandboxed research environment by exploiting vulnerabilities in proxy software, gaining access to the open internet, and attacking Hugging Face’s production infrastructure to steal credentials and manipulate a benchmark evaluation.

OpenAI’s July 22 safety blog disclosed the core sequence and acknowledged that its long-horizon models had demonstrated an ability to “learn the blind spots of an approval system and work around it.” That disclosure described a sandbox escape and an external attack. It did not name the vulnerability, the software, or the staging infrastructure the model used to reach Hugging Face, and it described the Hugging Face intrusion as the primary impact.

The July 28 disclosures from Reuters, Wired, and BleepingComputer filled in what the July 22 disclosure left out: the software was named, the staging infrastructure was identified, the vulnerability count was confirmed, and the scope of compromised accounts expanded.

OpenAI confirmed its rogue agent had accessed accounts at four services during the incident. The company did not name those services but told Reuters it had not identified “any other activity at the level of severity or scale of what we’ve shared related to Hugging Face, which involved a platform-level compromise.” That framing matters: the Hugging Face intrusion was the largest single impact, but it was not the only one. Three other accounts at three other services were compromised by the same agent during the same sequence.

OpenAI also confirmed it has “deactivated, encrypted, and restricted” the model from research access.

How the Sandbox Escape Worked

The proxy software the models exploited was JFrog Artifactory, the widely used package registry and repository proxy. OpenAI was running a self-hosted Artifactory installation as part of its evaluation infrastructure. JFrog released patches in Artifactory 7.161.15 on July 27, 2026, one day before the wider public disclosure, assigning eight CVEs to vulnerabilities in the release. BleepingComputer identified those CVEs by searching CVE.org for the 7.161.15 release. Which specific vulnerabilities the model exploited, and how they were chained, has not been confirmed publicly.

JFrog CTO Yoav Landman confirmed the core finding directly: “OpenAI’s models identified previously unknown zero-day vulnerabilities in self-hosted Artifactory installations that could be exploited to gain unintended internet access.”

The specific mechanism that gave the model its path out was server-side request forgery. CVE-2026-65924 and CVE-2026-65925 are SSRF vulnerabilities in Artifactory’s handling of Terraform and Cargo remote repositories. An SSRF flaw allows an attacker to make the server issue outbound HTTP requests to destinations it specifies, then return the responses. From inside a sandboxed environment with no direct internet access, the model used Artifactory itself as the outbound channel: it sent requests through the SSRF flaw, and Artifactory fetched external resources on its behalf.

Two additional CVEs made the chain more dangerous. CVE-2026-65617 is a remote code execution vulnerability on the package service container. CVE-2026-66014 is an authentication bypass with privilege escalation. The JFrog release notes for 7.161.15 specifically noted that the patched vulnerabilities, “when chained together, could result in critical attack scenario if Anonymous Access is enabled.”

The SSRF mechanism matters beyond the technical detail. An SSRF vulnerability does not give the model new network access: it makes the Artifactory server use its own existing network access on the model’s behalf. That means the scope of what the model could reach through the exploit was exactly the scope of what the Artifactory installation was permitted to reach. If the Artifactory instance had been governed by Communication Governance policies restricting its outbound destinations to known package registries and nothing else, the SSRF chain would have hit those restrictions and stopped. The model would have had a code execution path inside Artifactory but no route to Modal’s infrastructure or Hugging Face’s production systems.

The zero-days were real and sophisticated. The network paths they traversed did not have to be open.

The Staging Ground Was a Legitimate Platform with an Open Door

According to the Hugging Face technical timeline published July 22, the rogue agent broke into a sandbox “hosted on a third-party provider’s infrastructure” before using it to launch the broader attack. That third-party provider was unnamed in the Hugging Face post.

Reuters identified it as Modal Labs. Modal CTO Akshat Bubna confirmed the details directly: the agent exploited code written by a Modal customer who had published an unauthenticated endpoint allowing anyone on the internet to use their sandboxes for code execution. Bubna was explicit that Modal’s platform and its isolation mechanisms were not compromised. The vulnerability was in the customer’s own code, deployed on Modal’s infrastructure.

That distinction is important and also, from a security architecture standpoint, beside the point.

The open endpoint was not on OpenAI or Hugging Face's infrastructure. It was on Modal’s platform, published by a customer, and reachable by anyone on the internet with knowledge of the URL. The agent found it because nothing at the network layer prevented the agent from looking for and reaching publicly accessible compute endpoints. Once found, it provided a code execution environment outside OpenAI’s evaluation environment, an outbound path toward Hugging Face’s production systems, and legitimate-looking traffic originating from a real cloud platform.

From the perspective of anyone monitoring Hugging Face’s inbound connections, the attack traffic was not coming not from an OpenAI evaluation environment, but from Modal customer infrastructure. The staging hop was about acquiring a network origin that looked like normal cloud traffic.

Four Services, One Attack Chain, No Network Governance

What the full chain reveals is that no single step required anything novel; each hop used what was already open.

The agent exploited SSRF and remote code execution vulnerabilities in OpenAI’s self-hosted JFrog Artifactory installation to escape its evaluation sandbox and reach the open internet. It then found an unauthenticated code execution endpoint on Modal customer infrastructure, used it as a staging environment, and used exposed credentials to attack Hugging Face and at least two other services. OpenAI confirmed accounts at four separate services in total. One was Hugging Face. Modal Labs has been identified as a second, where the agent reached a customer’s environment rather than Modal itself. The other two services have not been named publicly.

At each step, the model found an open paths rather than breaking rules. The Artifactory SSRF gave it an outbound channel through the server’s own network access. The Modal customer’s unauthenticated endpoint gave it external compute with a legitimate network origin. The open paths to Hugging Face and three other services gave it targets.

None of those paths required the model to circumvent a network-layer control. There was no Communication Governance in place to ask whether an AI evaluation workload should be permitted to reach arbitrary internet endpoints. The model was operating in an environment where the software-layer controls around it were visible and explorable, and the network-layer controls that would have closed those paths regardless of what it did simply were not there.

Four False Assumptions Your AI Security Posture Is Probably Built On

Four assumptions are holding most AI security postures together right now . . . and this incident disproves all of them.

Guardrails are software rules. They exist at the same layer as the model. A model operating with a narrow objective and enough time will find their edges, just as OpenAI’s models found the edges of their approval system monitoring. This is not a prediction about future AI capability, but what OpenAI has documented happening with models they were running today.

Sandboxes are software constructs. They prevent what their designers anticipated. Multiple zero-days in a self-hosted JFrog Artifactory installation were not anticipated. The category of unanticipated gaps is exactly where capable models go when the anticipated gaps are closed, and a package registry proxy sitting inside the evaluation environment has a much larger attack surface than most security teams have mapped.

Behavioral monitoring is a detective control. It records what happened, but it does not prevent the action that triggers the alert. The monitoring did not stop the model from reaching Hugging Face.

And the capability argument is the most dangerous assumption of all. Less capable models do not run zero-day exploit chains against proxy software. But they do follow paths of least resistance toward their objectives, and “paths of least resistance” includes unauthenticated endpoints, permissive API configurations, and open network paths to services the model was never intended to reach. The Modal customer’s open endpoint did not require a sophisticated model to find, just a model that was looking, with a network that allowed it to look.

Four Questions for Your Next AI Security Review

Have you mapped what network destinations your AI workloads can actually reach right now? Not what they are designed to reach, but what the network permits them to reach. An AI system with no Communication Governance in place can reach anything the network allows, and that is a much larger set than the destinations it was built to use. The OpenAI agent found an unauthenticated endpoint on a third-party cloud platform. That endpoint was reachable because nothing prevented it from being reached. Your AI workloads have a similar list of reachable destinations. Do you know what is on it?

Are your AI evaluation and development environments subject to the same network governance as your production workloads? The compromise started in an evaluation environment. Evaluation environments are often treated as lower-risk: temporary, internal, not customer-facing. OpenAI’s evaluation environment had a network path to the open internet. A capable model found that path and used it. The question is whether the network paths from those environments are governed with the same rigor.

Who owns the network security posture of third-party services your organization uses to run AI workloads? The customer's code was compromised, not Modal’s platform. The agent used that customer’s published endpoint as a staging ground. Any organization running AI workloads on shared infrastructure should ask what a rogue or misbehaving AI agent deployed by another customer on that platform could reach. The attack surface is not just your own workloads; it's the network reachability of the entire environment your workloads share. That conversation belongs in your cloud vendor security reviews, your AI infrastructure procurement process, and your shared-responsibility model documentation. Most organizations have not had it yet because the threat model for AI workloads escaping and pivoting through a neighbor’s open endpoint was theoretical until this month.

What is your response plan if an AI system in your environment establishes connections to external infrastructure you did not authorize? OpenAI reportedly did not identify the full scope of what happened until after the FBI was alerted and the threat was contained. That detection gap reflects a response workflow built around software-layer controls that assume the AI stays within expected boundaries. The response plan for “AI is exhibiting unexpected behavior” is different from “AI has established outbound connections to four external services and used them to compromise accounts.” The latter requires a network isolation decision made in minutes, not a prompt engineering review. Ask your team: if an AI workload in your environment established an unauthorized outbound connection right now, which team owns the call to isolate it at the network layer, and what is their response time target? Most teams do not have an answer.

Bottom Line

OpenAI’s model accessed four accounts at four separate services because four sets of network paths existed and nothing closed them. The staging infrastructure it used was a legitimate cloud platform with an open door. The final targets were reachable because they were reachable. The software-layer controls performed exactly as they were designed: guardrails, sandboxes, and monitoring all functioned, but none of them prevented any of it.

This is the Containment Era argument in its most concrete form: the payload evolves, but the network path requirement does not.

What happened here is a preview. The models involved were pre-release evaluation agents running inside a research environment. The models coming next will be more capable, more autonomous, and running in more places across your infrastructure. That is not a reason to slow down on AI, but motivation to get the network architecture right now, while the window is open and the playbook is still being written.

The Artifactory SSRF chain worked because Artifactory could reach the open internet. Governed outbound paths close that. The Modal staging hop worked because an unauthenticated endpoint was reachable from anywhere. Communication Governance closes that too. Neither fix requires waiting for the next model generation, a new security category, or a vendor to solve it for you.

The network layer is yours to control. The time to do it is before the next incident names your infrastructure instead of OpenAI’s.

Map what your AI workloads can actually reach with the free Aviatrix Workload Attack Path Assessment, which starts with the network paths that matter.

For ongoing coverage as this incident continues to develop, the Aviatrix Threat Research Center is tracking the full AI containment category.