Testing Agent Containment After a Sandbox Fails

A sandbox can prevent an agent from reaching systems outside its task. To understand the surrounding defenses, we also need to ask what still stops unauthorized access after that sandbox has failed.

OpenAI's October 23 containment report describes testing precisely that condition. Alongside attempts to escape its research sandboxes, OpenAI gave red-teaming agents control of a host machine and asked whether they could reach the live internet.

Test each layer under its own conditions

The report concerns internal frontier-model training and evaluation environments, not ordinary customer deployments. OpenAI describes layered restrictions involving containers, lightweight virtual machines, monitoring, and network and cloud controls.

Starting a test with host access separates a useful question from the sandbox-escape question: does the surrounding perimeter still enforce the boundary when the inner protection is gone? Otherwise, a strong sandbox could hide a weak network restriction simply because the test never reached it.

OpenAI reports that permitted operational services provided indirect paths out. In one assumed-compromise test, an agent used an allowed connection to reach an authentication endpoint in a metrics service, then made that endpoint fetch an agent-supplied URL. Blocking direct outbound requests did not cover that indirect route.

The tests used purpose-built infrastructure copies and gave agents source code, configuration details and vulnerability guidance. They tested defenses under attacker-favorable conditions, rather than measuring how often an unaided model would discover the same paths in production.

An enterprise agent can inherit the same dependency

Consider a hypothetical security agent at a telecommunications company investigating suspicious employee sign-ins. The assumed policy permits internal identity records and a reporting service, but not arbitrary external requests or communication with unrelated investigations.

Suppose its execution environment is compromised. The reporting service can fetch linked diagnostic files for a case record. If direct outbound traffic is blocked but that service accepts arbitrary URLs, it can fetch an outside resource on the agent's behalf. The reporting service's own permissions and destination checks must enforce the same restriction.

The same review must preserve the work that is allowed. The agent still needs to collect internal evidence and file its report. The goal is a usable, enforced boundary, not disabling every capability until the workflow cannot function.

What this sharpens for WTK

For WTK, a catalog package describes the intended agent or team. Its compiled deployment also depends on runtime services, identities and infrastructure. Review needs to identify which control supports each restriction, and what evidence remains valid if another control fails.

Team communication deserves its own check. OpenAI also reports exchanging synthetic secrets between separated environments through shared-resource timing, often with specific guidance. That makes isolation broader than the absence of an approved messaging tool. It does not establish an easy or general attack against every agent team.

Humans can define permitted destinations, team relationships and conditions for stopping work. Automated checks and monitoring can support those decisions, but detecting a problem and containing its effects remain different responsibilities.

Our take: evaluate the outer restrictions without relying on the inner layer to hide their weaknesses. A useful review should distinguish prevented access, detected access and activity that actually stopped, while retaining evidence that authorized work can still complete.