A sandbox is only as closed as what an AI agent can reach

Published on: August 12, 2026 6 min read Stuck in an evaluation with no way out, an AI agent escaped in an hour through the one service on its allowlist. Here's the gap that opened. In July, OpenAI and Hugging Face responsibly disclosed an OpenAI model under internal evaluation escaped its sandbox, reached the open internet, and accessed Hugging Face’s internal production infrastructure. The agent took datasets, cluster details, and cloud keys during the intrusion. The most critical part of the external phase of this incident was the first hour, when the agent escaped its sandbox by using a vulnerability within a package proxy on its sandbox’s allowlist to access the internet. As more frontier model developers disclose similar incidents, the security industry needs to closely consider how agents impact reachability within test environments. You also do not have to run evaluation harnesses for this to be your problem. Any workload that executes code behind an egress list has the same structure: CI runners, hosted sandboxes, and network-reachable tool servers. Most of those allowlists were built to stop data leaving, but that is now not the only thing they need to stop. When building an allowlist, you typically consider what a workload needs to contact and weigh each entry by what data could leave through it. OpenAI’s agent revealed a blind spot for this typical process. The package proxy the agent accessed is a service: it authenticates callers, runs software with vulnerabilities, and talks to the public internet. While the sandbox could not reach the internet, the agent gained access to the package proxy, which did. An allowlist hands your AI workload the reach of any destination it can take over. To escape, OpenAI’s agent identified two zero-day vulnerabilities in the package proxy on its allowlist with a very large payoff. The first flaw was a server-side request forgery flaw that let the agent ask the proxy to fetch arbitrary URLs on its behalf. In OpenAI's Black Hat presentation, the model's reasoning at that moment reads "excellent, we have arbitrary SSRF." The sandbox borrowed the proxy’s internet connection. The second flaw was a privilege escalation. CVE-2026-65616 (CVSS 8.8) causes a package proxy's refresh-token endpoint to issue new tokens without validating token signatures. These tokens carry their scope as a claim rather than the server looking it up, so once the signature goes unverified the claim is whatever the caller says. In this case, the caller was the agent, which extended the access of its read-scoped token within the sandbox by editing its claim to administrative. It then submitted the token for refresh to the package proxy which returned an administrator-scoped token. As a result, the agent could act with administrator permission instead of its original read-only permission. The agents worked as a group to break out. Together, they explored the one service they could reach until they found a way to make it fetch on their behalf, then shared the method so other agents could use it too. One agent noted that external exploitation was outside the scope of its instructions, but continued anyway. Hugging Face and OpenAI also put the proxy compromise inside roughly the first half hour of the sandbox test despite the elusive nature of the vulnerabilities. Remember, these were zero-days, so the agent could not reference a CVE or advisory. The package proxy is also closed-source, and its code was never in the agent’s training set. We now know why the agent went after the proxy. It was stuck on its evaluation task, and OpenAI's presentation shows the model reasoning "perhaps answer online" before looking for a way out. Frontier models are rewarded for solving tasks quickly, so a stuck model looks for shortcuts, and OpenAI normally closes that one by disabling internet access. There are still open questions about the agent's behavior, including everything the agent did during its four-day intrusion and what it did once it gained access to the internet. What we do know is that this agent revealed, in practical terms, that we must make some new considerations as we build test environments for security-capable, autonomous AI. If you’re building sandboxes for AI agents, here are four ways to reduce your risk and limit reachability: A sandbox is a list of things the workload inside it can talk to, and everything on that list brings its own reach with it. When a workload is a build job that doesn’t matter, but it does when agents widen that list in ways allowlist designs never anticipated. Beyond evaluation harnesses, agentic workloads are also moving into CI, production automation, and into tooling that interacts with internal services. Each of those has a list with similar properties and structure. As models get better at finding and chaining flaws, the reach on those lists extends what agents can impact. OpenAI observes that these agents remain "bounded by the privileges they can obtain and the systems they can communicate with," so existing controls still work. What must change is how carefully we draw those lists to minimize reachability. Find more articles from the Threat Research team on our Security Labs site. Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedbackFrequently asked questions It asked the proxy to fetch it. A server-side request forgery flaw in the package proxy let the agent supply arbitrary URLs, so the proxy made the requests on its behalf. The sandbox borrowed the proxy's connectivity. No. The benchmark scored exploitation of bugs in software like browser engines and kernels. OpenAI's presentation shows the agent stuck on a task, reasoning that the answer might be online, then looking for a way to reach it. Yes. One agent established a channel with other agents by uploading a note to a shared internal package manager. Discovered exploits were posted there, so a method found by one agent became available to the rest. Not by itself. The sandbox already had no internet route. The permitted destination sat inside the trusted network, which is what made reaching it useful. Segmentation helps when the reachable services are constrained too. Both. Providers own the isolation technology. You own the allowlist, the services on it, and what those services can reach. Ask what the default allowlist permits and what those destinations reach. Start building faster today See what your team can do with the intelligent orchestration platform for DevSecOps.