Sandbox isolation for AI agents is not a single technology decision. It is a set of design choices along several axes: process boundary, network boundary, filesystem boundary, and credential boundary. Each axis has several implementation approaches, each with a different tradeoff between isolation strength, operational overhead, and performance impact. Getting the combination right for a particular deployment requires understanding what each mechanism actually prevents.
The context where this gets practically important is when your agent has credentials for a sensitive API: a payment processor, a medical records system, an internal RBAC-controlled data warehouse. In those contexts, the question is not "should we isolate the agent?" but "what does the isolation boundary actually need to include, and what does it exclude?"
Process Isolation: The Foundational Boundary
The basic unit of isolation on any modern OS is the process. Separate processes have separate virtual address spaces. One process cannot read or write another process's memory directly without explicit inter-process communication mechanisms. This is the property that makes process isolation useful as a containment boundary for untrusted code.
For an AI agent, process isolation means the agent runs in a child process separate from the host application that invoked it. The agent's execution environment is isolated from the host's memory space. Any code the agent generates and executes during a tool call cannot directly access the host application's in-memory credentials, session state, or other running processes.
What process isolation does not provide, on its own: filesystem isolation (the child process inherits filesystem access from the parent unless explicitly restricted), network isolation (the child process inherits network access unless namespace-separated), and IPC channel restriction (the child process can communicate through any shared IPC channel the parent left open). Process isolation is necessary but not sufficient for strong containment.
Linux Namespaces for Network and Filesystem Isolation
Linux namespaces allow the kernel to present different views of system resources to different processes. A process in a network namespace sees only the network interfaces created specifically for that namespace, not the host's full interface list. A process in a mount namespace sees only the filesystem mounts made in that namespace, not the host's full filesystem tree. Both are available without requiring containerization: you can create a new namespace for a single process using clone(2) with the appropriate flags.
Network namespaces are the right mechanism for egress allowlist enforcement at the OS level. The agent process runs in a network namespace where the only outbound routing goes through a proxy process that enforces the egress policy. The agent cannot make direct connections to the outside world; all traffic is mediated by the proxy. This works correctly for all network library calls the agent might make, regardless of whether they go through a Python requests call or a lower-level socket API, because the isolation is at the kernel level.
Mount namespaces provide filesystem isolation. The agent sees a restricted filesystem view: a read-only root with specific write targets (a designated scratch directory, for example), no access to the host's secrets directory, no access to other agents' working directories. This is implemented using OverlayFS to present a writable view of a read-only base image, with the copy-on-write layer stored in a per-run scratch space.
Container-Level Isolation vs Namespace-Level Isolation
Containers (Docker or equivalent) bundle namespace separation, cgroup resource limits, and filesystem isolation into a single abstraction with a familiar operational model. They are a reasonable choice when the platform already operates container infrastructure and the overhead of container lifecycle management is acceptable.
The tradeoff is startup latency. A cold-start container for a Python agent with a full dependency set can take 2-8 seconds depending on image size and I/O speed. For interactive agents handling user queries in a latency-sensitive context, that startup time is visible to the user. For batch processing agents, it is generally acceptable.
Namespace-based isolation without full containerization has lower startup overhead: creating a new set of namespaces for a process adds milliseconds, not seconds. The tradeoff is that the operational tooling is less mature. Container images provide a versioned, reproducible execution environment with clear lifecycle semantics. Namespace-level isolation requires more custom infrastructure to achieve the same reproducibility properties.
For platform teams running agents in production at scale, the choice often comes down to whether the agent's workload pattern is latency-sensitive or throughput-oriented. Latency-sensitive workloads benefit from pre-warmed container pools or namespace-level isolation with faster startup. Throughput-oriented workloads can tolerate container cold starts.
Credential Isolation and Short-Lived Tokens
Process and filesystem isolation create a bounded execution environment. The credential model determines what the agent inside that environment can do. An agent with long-lived API credentials that never expire provides a larger blast radius than an agent with short-lived tokens scoped to specific operations.
The right pattern for sensitive API credentials is to issue a short-lived, scoped token at the start of each agent run rather than mounting long-lived credentials into the sandbox. The token is valid for the duration of the run, allows only the operations the agent needs for this specific task, and expires when the run completes. If the sandbox is compromised mid-run, the attacker holds a token that expires shortly and has limited scope. If an audit log analysis after the fact shows the agent made unexpected API calls, the run-scoped token means the blast radius was bounded to that run.
Credential isolation also applies to the credentials used by the sandbox infrastructure itself: the proxy process that enforces egress policy should not share credentials with the agent process. If the agent code is manipulated, it should not be able to escalate to the network enforcer's credentials through some mechanism.
Filesystem Overlays for Ephemeral Working State
Agents that generate intermediate files, cache tool outputs, or write partial results during a run need a working filesystem. If the working filesystem persists across runs, it creates a cross-run information channel: a previous run's cached output is visible to a subsequent run, which can be a data leakage vector if different users are served by the same agent pool.
Ephemeral working state using OverlayFS solves this. The base image layer is read-only and shared across agent instances. Each run gets its own write layer, allocated at run start and destroyed at run completion. The run's working state is private to that run and does not persist. The cost is that any caching benefit from previous runs is lost, which is the correct tradeoff for agents handling sensitive data from different users.
For agents where caching legitimate intermediate results across runs would provide meaningful performance benefits, the right approach is a separate, access-controlled cache layer that is explicitly part of the trust model, with cache reads logged in the audit trail like any other data access. Implicit filesystem persistence is the dangerous form; explicit, logged cache access with defined access controls is a reasonable design.
Where Each Strategy Breaks Down
Process isolation does not prevent side-channel attacks using shared resources like CPU caches or memory bus bandwidth. These are real attack vectors for co-hosted processes, particularly in cloud environments with noisy neighbors. For most AI agent deployments, these are not the relevant threat model; for cryptographic operations inside an agent, they are.
Namespace isolation depends on the correctness of the kernel's namespace implementation. Namespace escape vulnerabilities exist, though they tend to require significant attacker capability to exploit. Container runtimes have mitigations (seccomp profiles, AppArmor/SELinux policies) that reduce the exploitable attack surface even if a namespace boundary is partially compromised.
Short-lived credentials only help if the token issuance system is reliable and the scope definition is accurate. An agent issued a "scoped" token with effectively unlimited permissions because the scope definition was too broad defeats the purpose. Getting credential scoping right requires understanding exactly what operations the agent needs for each task type, which is a design-time requirement, not an infrastructure requirement.
None of these mechanisms substitutes for the others. A well-isolated filesystem with no network restriction still allows data exfiltration over the network. Strong credential scoping with no process isolation allows credential theft through shared memory. The practical isolation posture is a combination of all relevant mechanisms at each boundary, layered to ensure that failure at one layer does not give an attacker full access.