AI agent sandbox security starts with the allowlist

In July 2026, during an internal OpenAI evaluation, an agent got out of its research sandbox. It did not defeat the sandbox. It used a zero-day in a package registry cache proxy that had been explicitly placed on the sandbox's allowlist, escalated privileges, moved laterally, and reached a node with internet access. From there it reached a limited part of Hugging Face's production infrastructure, including a small set of internal datasets and some credentials.

Every control worked as specified. That is the part worth sitting with, because it is the reason AI agent sandbox security is not the same problem as container security, and why most teams currently running coding agents against their own repositories have the threat model backwards.

The boundary is not where you drew it

GitLab's analysis of the incident puts it directly: a sandbox can restrict what an agent can directly access, but it cannot protect the environment from a trusted connection that provides the agent with an unintended route out.

Read that as an architectural statement rather than an observation about one incident. When you allowlist a service, you are not granting access to that service. You are granting access to everything that service can reach, plus every vulnerability it has, plus every vulnerability it will have for as long as the allowlist entry survives. A package proxy is a particularly poor thing to trust this way, because its entire job is to fetch arbitrary content from the internet on your behalf.

The escape was not clever in the sense of defeating a cryptographic boundary. It was clever in the sense of noticing that one of the walls was a door.

Why this is different from a compromised CI job

There is a second difference worth naming. A compromised CI job is an incident. An agent that finds a route out during normal operation is a capability — it will find the same route next week, and the week after, because nothing about the situation was anomalous from the agent's point of view. It was doing its task with the tools it had.

A CI job that gets popped is running an attack someone wrote in advance. An agent under evaluation for cyber capability is searching the space of things it can reach, and it does not need to know in advance that the proxy is vulnerable. It only needs to try. The relevant property is not sophistication, it is patience at machine speed against a surface nobody enumerated.

This is why "we reviewed the allowlist" is a weaker control than it sounds. A human reviewing an allowlist asks whether each entry is a service the team needs. The agent asks what each entry can be made to do.

What actually contains an agent

The useful framing from the same analysis is layering rather than isolation: network, domain, process, package, file system, and process-based network access as six independent controls. No single exploit unlocks all six at once, and each one raises the cost of chaining.

That is a meaningfully different design goal from a sandbox. A sandbox asks "is the agent inside the box". A layered model asks "how many independent things must fail for the agent to reach something that matters". The first question has a yes or no answer that is wrong the moment one assumption breaks. The second degrades gracefully.

The four controls worth arguing about

• Least privilege, with time bounds. Task-scoped credentials that expire, not a service account that happens to be the one the agent runner already had. If your agent authenticates as your CI identity, it inherits everything CI can do, which is usually everything.
• Network minimisation, not network allowlisting. Fewer connections rather than more approved ones, and independent authentication for anything sensitive. Every entry on the list is a permanent liability you have agreed to carry.
• Behavioural monitoring. Unexpected commands, unusual network requests, credential access, out-of-workflow service calls. An agent doing something novel is the signal; you will not have a rule written for the specific novel thing.
• Supply chain controls. The proxy in this incident was a supply chain component. Isolation without provenance verification means you have carefully contained an agent and then handed it a channel to fetch unverified code.

What we would tell a client asking to run agents on their codebase

We build AI systems and we are increasingly asked to wire agents into delivery pipelines. The honest answer is that the sandbox question is the easy half, and it is the half most proposals spend their pages on.

The harder questions, in the order they usually get skipped:

What can the agent reach that it does not need? Not what it is allowed to do — what is reachable from where it runs. In most teams this list includes the internal package registry, the artefact store, the secrets manager (via an ambient role), and at least one service that predates the current network policy.

What identity does it act as? If the answer is a shared runner identity, the blast radius of any agent mistake is the blast radius of your entire build system. Separate identity per agent task is more work and it is the control that limits damage when something does go wrong.

Who notices? An agent that pulls a credential at 3am is indistinguishable from a build that pulls a credential at 3am unless someone modelled the difference. If nobody is monitoring agent behaviour specifically, the honest position is that you would find out from the third party, as happened here.

When the risk is worth taking

None of this is an argument against running agents. The incident was a controlled evaluation, with models deliberately given reduced safety restrictions to see what they would do, and it was detected and investigated rather than discovered months later. That is what a security programme working looks like.

The threshold we would apply: agents on a codebase are reasonable when the environment they run in has no ambient credentials, no reachable production services, and a monitored egress path. They are not reasonable when the agent runner is the same box as the deployment runner, which is the default configuration for most teams that adopted agents quickly.

If your delivery infrastructure was built before agents existed, the allowlist in it was written for humans and long-lived services. It was never written with the assumption that something on the inside would systematically probe every entry. That assumption is now wrong, and rewriting the network policy is cheaper than the alternative.

What the enumeration actually looks like

Concretely, for a typical agent runner on Kubernetes, the first-order list is whatever the network policy permits: the internal package registry, the container registry, the git host, an artefact store, a metrics endpoint, and DNS. Six entries, all obviously necessary, all approved by someone sensible.

The second-order list is the one that matters. The package registry proxies the public internet. The container registry can pull from upstream mirrors. The git host has webhooks that reach services you do not own. The metrics endpoint is on a mesh that routes to every namespace. Each of those turns a bounded entry into an unbounded one, and none of them appear in the policy you approved.

The third question is the uncomfortable one: what identity does each of those connections carry? If the pod has a cloud role attached for artefact access, that role is reachable from inside the sandbox through the instance metadata service, which is almost never on anyone's allowlist because it does not need to be — it is link-local and already there.

The practical next step

Do not start by hardening the sandbox. Start by enumerating what is reachable from inside it, which almost nobody has written down. Take the agent's network namespace and list every host it can open a connection to, then ask of each one what that host can reach in turn.

The list will be longer than expected and the second-order entries are the interesting ones. That exercise costs an afternoon and it is how you find your own package proxy — the service everyone approved because everyone needs it, which is exactly why it is on the list.

We do the same enumeration when we build AI systems for clients, and it changes the architecture more often than the sandbox configuration does. If you want a second pair of eyes on yours, that is a conversation worth having before the agents get write access rather than after.