惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Last Week in AI
Last Week in AI
H
Help Net Security
博客园 - 叶小钗
V
Visual Studio Blog
阮一峰的网络日志
阮一峰的网络日志
博客园 - 三生石上(FineUI控件)
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Microsoft Azure Blog
Microsoft Azure Blog
G
Google Developers Blog
腾讯CDC
MongoDB | Blog
MongoDB | Blog
宝玉的分享
宝玉的分享
P
Proofpoint News Feed
GbyAI
GbyAI
Microsoft Security Blog
Microsoft Security Blog
A
About on SuperTechFans
博客园 - 司徒正美
人人都是产品经理
人人都是产品经理
T
The Blog of Author Tim Ferriss
Martin Fowler
Martin Fowler
月光博客
月光博客
博客园 - 聂微东
酷 壳 – CoolShell
酷 壳 – CoolShell
Vercel News
Vercel News

GitLab

Securing the software factory at machine speed Rate limits on GitLab.com are changing Optimize your team See who spent your AI credits and set fair caps per team New MCP tools help platform teams scale automation safely GitLab Duo CLI takes a task from goal to done When to use SAST versus an LLM security scanner GitLab Dedicated: Compliance for a new regulatory era How to calculate DevOps platform total cost of ownership GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 Co-Create: Building GitLab with our users Prepare for the Cyber Resilience Act Bring your own model to GitLab Duo Self-Hosted with Microsoft Foundry GPT-6 Astra on GitLab: Faster runs, fewer tokens used GitLab’s internal playbook to foster AI-fluent technical teams Critical remote code execution in vm2, a widely used Node.js sandbox library GitLab compliance frameworks: Adhere to SOC 2 in minutes How to recognize your team with GitLab Achievements Making room for what GitLab Patch Release: 19.3.1, 19.2.5, 19.1.7 Git was built for humans — agents need an upgrade Scale software delivery without owning the runner fleet When code is abundant When your backlog outgrows your team, GitLab scales remediation Run agentic software delivery inside the boundaries you already trust Build custom flows in minutes with the Flow Creator agent GitLab 19.3 release notes From chaos to context: Building an AI dev workflow From OpenTofu to Argo CD: GitLab as your AWS control plane Avoid the massive end-to-end tax of default full history clones
A sandbox is only as closed as what an AI agent can reach
Daniel Abeles · 2026-08-12 · via GitLab

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.

Why allowlists extend reachability

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.

How OpenAI’s model escaped

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.

Why the model escaped

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.

How to reduce risk across AI test environments

If you’re building sandboxes for AI agents, here are four ways to reduce your risk and limit reachability:

  1. Block the routes a build client never uses. A build client only downloads files. It has no reason to call the proxy's admin API, its configuration routes, or its token-refresh route, which swaps an expiring token for a new one and is the route that was abused in this incident.
  2. Restrict what the proxy itself can reach. The agent got out because the proxy could reach the whole internet, so anyone controlling the proxy could too. Limit the proxy’s outbound connections to the registries it actually serves.
  3. Monitor the proxy. A proxy serving a build-fleet is monotonous, with short connections, small downloads, and requests that mostly succeed. Consider alerting on anything that doesn’t follow that pattern, such as connections that stay open, data moving outward in bulk, a run of requests for packages that are not there, and any call to an admin route.
  4. Treat untrusted workloads as internet-facing. If an untrusted workload can reach an internal service, treat that service as internet-facing. Anything that compromises the workload can reach it too. We looked at the same question for CI runners earlier this year, where the untrusted code runs in a pipeline rather than an agent sandbox.

Cyber-capable models require new sandbox considerations

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.