Code sandboxes are becoming the hidden runtime of AI agents

An AI model can write a command, but an external runtime decides whether that command runs and what it can reach. OpenAI’s shell environment, Anthropic’s code-execution container and Google’s Python execution tool all expose this separation in different ways. The model produces code or commands; the platform executes them and returns results for another model step.

That distinction matters during incidents. A harmful command is a model-behavior problem. Allowing it to read credentials, contact an arbitrary host or overwrite a production directory is an execution-control problem. Refusal training and prompt rules may reduce bad proposals, but they cannot replace kernel, hypervisor, identity and network enforcement.

The runtime contract should be visible to both the agent and the operator: which languages exist, which directories persist, whether internet access is available, how long a process may run and what evidence will be retained.

A standard container shares the host kernel. Namespaces, capabilities, seccomp and cgroups can narrow access, but a kernel escape may cross the boundary. gVisor moves much of the system-call surface into a user-space application kernel. Firecracker and Kata place workloads behind a virtual-machine boundary. WebAssembly runtimes expose a smaller capability-oriented interface for compatible workloads.

Stronger isolation usually adds startup time, memory, compatibility or operational cost. A short arithmetic calculation in a fixed Python environment may not need the same boundary as an agent that runs arbitrary build scripts from an unknown repository.

The decision should consider code origin, tenant separation, secrets, network access, native extensions, kernel attack surface and consequence of escape. No sandbox eliminates side channels, host vulnerabilities or denial-of-service risk.

Uploaded archives, repositories, notebooks and documents can contain executable hooks, path traversal, symbolic links, oversized files or instructions intended to redirect the agent. Generated files can contain malware, secrets or hidden active content. A workspace should therefore begin empty or from a verified image and receive only task-scoped inputs.

The base filesystem should be immutable. Writable data belongs in a limited scratch volume with quotas and a known retention period. Host sockets, package-manager credentials, cloud metadata endpoints and unrelated user directories should not be mounted.

Persistent environments improve iterative work but create state confusion. The agent may assume a file, variable or installed package exists when it belongs to another environment or an earlier task. Reuse should be explicit, tenant-bound and observable, with reset and snapshot integrity controls.

A network-enabled shell can download dependencies, call APIs and publish results. It can also exfiltrate uploaded data, fetch malicious code, scan internal services or reach cloud metadata. OpenAI’s published Codex controls and Firecracker’s production guidance both treat network policy as an external control rather than something the guest should govern.

The safest default is no network. Approved access should pass through a proxy that authenticates the sandbox, allowlists destinations and methods, strips ambient credentials, limits transfer size and logs requests. Internal networks and metadata services remain blocked unless the task contract names them.

Secrets should arrive just in time, scoped to one target and one operation. They should not be written into prompts, shell history, environment dumps or persistent images. A sandbox that needs broad cloud credentials is a sign that the task boundary is too wide.

Language package managers often execute build scripts and resolve mutable dependency graphs. Letting an agent install the latest package from the public internet introduces supply-chain risk and makes results difficult to reproduce. A package name in a prompt is not provenance.

Production runtimes should use pinned images, lockfiles, checksums and approved mirrors. OCI image digests identify exact images, while SLSA and in-toto provenance can describe how an artifact was built. SBOM formats such as SPDX or CycloneDX record included components but do not prove that every component is safe.

Runtime images need the same lifecycle as production software: vulnerability scanning, patch qualification, deprecation, rollback and evidence that the image used in evaluation matches the image used in deployment.

Generated code can allocate memory, create processes, fill disks, emit unbounded output or loop on network requests without being intentionally malicious. A wall-clock timeout stops only one dimension of the problem.

CPU quota, memory limit, process count, file descriptors, disk bytes, inode count, output bytes and network rate should be enforced by the host. Limits need deterministic failure states so the agent can recover without repeatedly launching the same exhausted workload.

Fleet-level admission control is equally important. Thousands of individually constrained sandboxes can still exhaust hosts, queues or storage. Per-user budgets, concurrency limits, cancellation and garbage collection prevent abandoned agent loops from becoming an infrastructure incident.

An agent may run a test it wrote itself, misread terminal output or declare success after a partial command. A spreadsheet may open but contain wrong formulas. A patch may pass a narrow test while breaking another feature. A chart may be generated from the wrong column.

Verification should use independent tests, schema checks, file parsing, malware scanning, secret scanning, reproducible reruns and human review proportional to consequence. The verifier should inspect the exact artifact digest that will leave the sandbox.

Logs and diffs are evidence, not proof by themselves. Terminal-Bench and coding-agent evaluations show that infrastructure configuration can materially affect results, so acceptance evidence must include runtime image, resource limits, dependencies and test harness versions.

A code sandbox platform manages image building, warm pools, scheduling, file transfer, secrets, quotas, logs, artifact storage, vulnerability response and teardown. The model call may be only one part of the cost and latency.

Warm reuse reduces startup delay but increases cross-task state and patching risk. Disposable microVMs provide stronger reset semantics but require image and snapshot integrity. A fixed hosted interpreter is simple and predictable but cannot satisfy tasks that need custom binaries.

Measure accepted artifacts per dollar and per operator hour. Include cold starts, failed dependency resolution, scans, retained files, human review and infrastructure updates. A general shell is not automatically better than a narrow function or deterministic data pipeline.