AI systems / security / runtime isolation · 2026-10-22

AI agent sandboxes: isolate the code, not just the prompt

An agent that can execute generated code is not merely a language model producing text. It is an untrusted program runner whose input may be adversarial, whose behavior can be nondeterministic, and whose tools may carry real authority. Prompt rules can guide behavior; they do not enforce operating-system boundaries. Safe design starts by treating every generated command as hostile.

Three boundaries, three different controls

Instruction boundary: system prompts and tool policy shape intended behavior, but prompt injection can alter what the model tries.
Capability boundary: an explicit allowlist constrains which tools and identities the agent can invoke.
Execution boundary: a sandbox limits what the executed process can read, change, or reach even if its code is malicious.

These controls are not interchangeable. A container with a mounted home directory still exposes that directory. A read-only filesystem does not stop a process from exfiltrating data over an allowed network path. A tool allowlist does not constrain a shell command launched by an allowed coding tool.

Build the sandbox as a resource and authority budget

Start with a disposable workspace, a non-root identity, no host credentials, and no sensitive mounts. Add CPU, memory, process-count, and wall-clock limits so a loop or fork bomb cannot consume the host. Disable network access by default; where dependencies require egress, use a narrow proxy or destination allowlist and block metadata endpoints. Destroy the workspace after each task unless persistence is explicitly needed.

trusted controller
   ├── gives task-scoped input only
   ├── starts isolated worker (no host secrets)
   ├── enforces time / memory / process limits
   └── validates output before promotion

untrusted generated code ──X── host filesystem, credentials, metadata

A container is a useful packaging and namespace mechanism, but it shares the host kernel. For higher-risk workloads, use a stronger boundary such as a microVM or a dedicated disposable worker. The choice depends on the threat model, kernel attack surface, workload compatibility, and operational cost—not on a label like “sandboxed.”

Secrets and network are the common escape routes

Do not place long-lived cloud keys, SSH agents, browser profiles, or package-publishing tokens in the worker environment. Prefer a controller that performs narrowly scoped operations on behalf of the worker and returns only the result. If a secret must be used, mint it just in time, scope it to one resource and operation, and revoke it after use.

Network egress deserves the same scrutiny as filesystem access. A worker can encode files into DNS queries or send them to an allowed web endpoint. A useful default is no outbound access, with dependencies preloaded or fetched by a separate trusted step. If network is needed, log destinations and bytes, and test whether private address ranges, cloud metadata, and local control-plane services are unreachable.

Reproducible containment lab

On a disposable local machine, create a temporary sandbox using the isolation mechanism you intend to deploy. Do not mount your home directory or pass real credentials. Run harmless probes: attempt to read a deliberately unmounted path, connect to loopback and a private test address, spawn children until the process limit, allocate memory until the configured cap, and sleep past the task deadline. The expected outcome is a denied access or controlled termination in each case. Record the exact runtime, policy, and result.

# Illustrative container shape; confirm flags for your runtime
podman run --rm --network=none --read-only \
  --user=65532:65532 --memory=256m --pids-limit=64 \
  --cap-drop=all --security-opt=no-new-privileges \
  --tmpfs /tmp:rw,noexec,nosuid,size=32m \
  IMAGE task-command

This is not a universal hardened command: runtime defaults and platform protections differ. Verify effective settings from inside and outside the worker, and test the actual deployed runtime. Do not test escape techniques against shared or production infrastructure.

Promote outputs, never the worker's authority

Treat worker output as untrusted data. Validate schemas, scan generated artifacts, require review for consequential changes, and copy only explicitly approved files into a trusted workspace. Keep the controller outside the sandbox and make it responsible for policy, audit logs, and cleanup. An agent should not be able to approve its own output or expand its own privileges.