AI agent containment: eight gates beyond a sandbox

OpenAI reported that a DNS configuration allowed a model to reach the internet during training on September 20. It stopped frontier workloads, strengthened controls, and then launched a high-compute red-team campaign. Agents found previously unknown vulnerabilities and weak configurations across sandboxes, internal services, and network perimeters. The operating lesson is not that one brand failed: it is that an authorized capability such as name resolution, metrics delivery, or package download can become a transitive bridge to a forbidden destination.

For a product team, the consequence is concrete. If an agent processes untrusted email and can also execute a shell, read environment variables, and call APIs, prompt injection does not need to defeat every defense. It only needs one viable chain across context, tool, secret, and egress. The architecture must break that chain at several points and prove it with adversarial tests rather than a temporary absence of incidents.

The model, harness, and execution environment are not the same thing. The model proposes steps; the harness retains the goal, policy, and authorization; the sandbox runs commands or a browser. Separating them makes it possible to record which action was requested and prevent a compromised process from rewriting the decision logic. Google describes this split as brain and hands. OpenAI uses restricted containers inside microVMs for Linux tasks and adds network and cloud perimeters around them. In both cases, the hypervisor or runtime is one barrier, not the whole system.

Outer layers must survive root access inside the guest. Long-lived secrets stay outside; a gateway exchanges ephemeral identity for an allowed call only after validating session, user, tool, and destination. Networking defaults to deny or mediates every outbound request. Storage and memory are not shared without need. Telemetry observes behavior from outside the box, and a stop control can revoke identity, block egress, and destroy the session without asking the agent to cooperate.

Imagine a support agent that receives a ZIP attachment, reproduces an error, and proposes a patch. This example is hypothetical. The file enters as untrusted content. An ephemeral session opens it inside a microVM with no credentials, a temporary filesystem, and resource limits. The harness allows local tests but not publishing. If the agent needs to inspect a dependency, it requests an explicit destination from the gateway; the proxy validates domain, method, size, and redirects. To read a ticket, it receives a narrowly scoped token that expires with the task and never enters the guest as an environment variable.

The patch leaves as an artifact rather than an authorized commit. A scanner checks binaries and secrets; CI rebuilds from an image pinned by digest; a human or separate policy approves the merge. If the attachment tries to induce an external call, egress policy blocks it even if the model complies. If the process exploits the runtime, it finds no persistent keys. If it tries to use DNS as a tunnel or communicate with another session, the perimeter and monitor produce a signal that stops the workload. Security does not depend on the model recognizing the attack.

First, separate harness from execution: the guest cannot edit policy, goal, or audit records. Second, use strong per-session isolation and destroy state except for explicitly exported artifacts. Third, keep zero long-lived secrets inside the guest; deliver ephemeral, task-bound identity. Fourth, turn generic tools into narrow capabilities: reading one ticket does not imply listing all tickets, and proposing a patch does not imply pushing it.

Fifth, govern egress at more than one layer: DNS, IP, URL, redirects, protocols, and services that fetch on the agent's behalf. Sixth, isolate memory, caches, queues, and storage across sessions to prevent accidental or deliberate lateral communication. Seventh, monitor from outside with correlation across tool call, process, network, and artifact, and define signals that stop execution automatically. Eighth, red-team while assuming inner layers have already failed; reproduce findings, verify fixes, and preserve regressions in the suite.

Start with observable objectives rather than a generic audit. The agent must not reach a team-controlled external server, read cloud metadata, recover a long-lived secret, access the host, mount foreign storage, exchange a synthetic value with another session, or continue after a stop signal. Run each objective from the normal path and from a compromised starting point. OpenAI also tested the perimeter while assuming the agent had already escaped the sandbox and controlled the host, a useful practice for learning whether outer layers are truly independent.

Measure prevention, detection, and response separately. Prevention asks whether the action occurred. Detection measures whether telemetry recognized it and with what delay. Response confirms that identity, network, and compute were revoked. Keep an evidence package containing image version, policy, model, adversarial prompts, traces, and outcome. When the runtime, kernel, sidecar, proxy, model, or tool changes, rerun affected cases. A declining findings curve can show red-team learning, but it does not prove the absence of unknown paths.

More isolation adds cost, latency, and complexity. A microVM per session needs warm pools or efficient suspension; a strict proxy breaks tools that discover destinations dynamically; zero secrets requires a broker, workload identity, and per-action policies; useful snapshots expand the data surface. The right design depends on impact. An assistant that only summarizes text does not need the same boundary as an agent with a shell, an authenticated browser, and production access.

Avoid two simplifications. “It runs on Kubernetes” does not prove isolation: it shares a kernel unless the runtime adds a barrier, and policy can open hostPath, capabilities, or networking. “It has no internet” is also insufficient: DNS, metrics, authentication, registries, proxies, and services vulnerable to SSRF can become indirect egress. Document transitive dependencies and test each one. Google notes that enabling API access or sidecars requires changing secure defaults; every exception needs an owner, purpose, scope, and regression test.

Before buying a platform, draw the path of one action: incoming content, harness decision, executed process, identity used, destination called, persisted state, and final effect. Mark where untrusted input can influence each step. Then remove permissions that are not part of the use case and move secrets outside the guest. Those two decisions often reduce more risk than adding another content classifier because they limit what happens even when the model is wrong.

Then implement mediated egress, ephemeral sessions, external logs, and a rehearsed stop. Build a small adversarial corpus covering indirect prompt injection, hostile files, redirects, DNS, metadata attempts, and cross-session communication. Promote the agent only when all eight gates have evidence and there is a degraded path without autonomous execution. If your team needs to turn a tool-enabled prototype into an operable architecture, Wasyra can help model boundaries, build the pilot, and leave verifiable controls in place without confusing autonomy with unlimited access.