AI Agent Sandbox: Isolation Controls for Agent Runtime Risk
An AI agent sandbox confines the local process, file paths, network destinations plus credentials, and temporary state available to an agent runtime. This guide maps isolation choices through OS process controls into microVMs, explains the evidence each boundary produces, and separates runtime containment from policy enforcement on routed LLM requests.
An agent process with the parent application's filesystem mounts plus cloud credentials and unrestricted egress inherits the application's authority before it calls its first tool. An AI agent sandbox replaces that ambient authority with explicit mounts, destination allowlists, credentials plus resource limits, and temporary state. That containment is what a reader needs after a prompt redirect reaches local execution: a written policy for exactly what the runtime can touch, plus evidence when it attempts a boundary crossing.
The ambient authority the agent runtime inherits is the attack surface a sandbox subtracts. The gVisor architecture and Firecracker security model describe two different isolation designs that help make that choice concrete.
TL;DR
Use a sandbox when an agent can execute local code, read or write files, and hold workload credentials or connect to external services. Define the runtime boundary first. Choose an isolation layer that fits the workload and log denied attempts. An LLM gateway governs routed HTTP model traffic; it does not replace local runtime containment.
Sandbox properties
Five properties define an AI agent sandbox useful for blast radius containment.
Filesystem confinement. The sandbox restricts filesystem access to a defined directory or set of paths. Attempts to read or write outside the confined area are denied at the sandbox boundary. Confinement is stricter than the calling application's own filesystem permissions because the sandbox draws the boundary at the point of the agent runtime, not at the process's uid.
Network egress confinement. The sandbox restricts outbound network access to a defined allowlist of endpoints. The agent's tool calls to allowed endpoints (the LLM provider, a specific internal API, a whitelisted external service) pass through. Attempts to reach any other endpoint are denied. The ai agent egress control piece covers the egress side in depth.
Credential isolation. The sandbox does not inherit the calling application's credentials. Credentials the agent needs (a database service account, an API key for an internal service, a signed identity claim) enter the sandbox explicitly through a controlled interface. When the sandbox terminates, the credentials it held are unreachable.
Resource bounds. CPU and memory limits, plus a wall-clock deadline, confine the agent's resource consumption. A runaway agent, whether from prompt injection or from a benign infinite loop, exhausts its bounds and terminates rather than exhausting the host.
Ephemeral state. The sandbox instance is per-session or per-request. When the session terminates, the sandbox and any state it held (temporary files, in-memory caches, cached retrieval hits) are destroyed. Long-running state that has to survive between sessions lives outside the sandbox in an explicitly-shared store.
Process, container, VM
Three implementation levels produce different trade-offs. The right selection follows the permitted actions and isolation requirement, rather than an assumed hierarchy of product names.
Process-level isolation can use a seccomp policy or gVisor. The sandbox restricts the agent process's syscall surface plus its namespace and capability access. Boundary strength depends on the kernel and the configuration. gVisor adds a user-space kernel that narrows the host-kernel interface.
Container-level isolation can use Docker or Kata. The sandbox runs the agent inside a container with a defined image plus network and mount set. Containers still share the host kernel, so the runtime configuration, user namespace, mounts, and egress policy determine the useful boundary. Kata Containers adds a VM boundary while retaining a container interface.
VM-level isolation uses Firecracker, QEMU, or a WebAssembly runtime. A lightweight VM places a kernel boundary around the agent. WebAssembly runtimes expose a different capability model and need explicit host-function permissions. Both approaches add operational work, including image maintenance, patching, observability, and capacity planning.
The choice depends on session concurrency, latency budget, and the sensitivity of what the agent handles. Deployments running thousands of concurrent agent sessions with sub-second latency budgets typically pick process or container level. Deployments running fewer, higher-stakes sessions pick VM level.
Where the sandbox sits relative to the AI request boundary
The sandbox contains local agent activity. A separate AI request boundary controls routed HTTP calls to LLM endpoints, so each layer has a distinct enforcement responsibility.
Prompt injection that succeeds against the model produces a set of tool calls. The tool calls that stay inside the sandbox (filesystem reads/writes to the confined area, in-sandbox scripting) are contained by the sandbox. Requests that leave the sandbox need controls at their own destinations. Routed HTTP calls to an LLM provider can pass through the AI request boundary; internal APIs and other services need their own authorization checks. The proxy evaluates identity, approved model route, data classification, and policy on each LLM request it receives.
The AI request authorization model describes the routed-LLM boundary. Tool authorization runs at the tool endpoint or its own gateway.
Audit signal at each boundary
Each sandbox boundary crossing produces an audit signal. The signals feed both operational observability and incident review.
- Filesystem access: every read and write outside the confined area, whether denied or (for read-only monitoring paths) permitted.
- Network egress: every outbound connection attempt with destination and outcome.
- Credential access: every retrieval from the credential interface.
- Resource limit approach: approaching CPU, memory, or wall-clock limits, with a distinct signal for termination.
- Session lifecycle: sandbox creation, session identity claim, and sandbox destruction.
The ai agent observability piece covers the OpenTelemetry pattern for these signals. Durable audit records need the relevant identity, event, timestamp, and outcome fields.
Runtime review evidence
Sandbox policy should be reviewable before an agent runs. Record the base image or snapshot, permitted mounts, outbound destination allowlist, credential source, resource limits, session identity, and termination reason. During an investigation, this record distinguishes a denied local file read from a permitted LLM request that crossed the HTTP proxy.
The NIST AI RMF supplies the governance context for documenting those controls. The sandbox event stream is one input to monitoring, rather than proof that the model itself made a safe decision.
Regulatory framing
Under EU AI Act Article 14, high-risk AI systems have to be designed and developed so natural persons can effectively oversee them. Sandboxing can support that oversight by keeping the agent runtime inside documented bounds.
Under NIST AI RMF's MANAGE function, runtime containment of AI system behavior is one of the controls the function anticipates. The audit signals from the sandbox feed the MANAGE evidence chain.
DeepInspect
DeepInspect operates at a separate boundary. It does not run the agent sandbox; Firecracker, Kata, gVisor, or a WebAssembly runtime own that local-runtime job. DeepInspect governs HTTP traffic between authenticated users or agents and LLM endpoints when those requests traverse its proxy. Tool authorization, database access, and other external-service calls remain with their own enforcement points.
Operations teams can reason about two layers independently. A sandbox contains local execution. The gateway records and evaluates routed LLM traffic. That separation makes ownership visible during a review.
Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Do we need a sandbox if we have an AI request boundary?
For agents that only call remote APIs (nothing local), the AI request boundary handles the containment. For agents that execute local code (running scripts, writing files, calling shell tools), the sandbox is the layer that contains the local operations the boundary never sees.
- Which sandbox technology should we pick?
For a process boundary, evaluate gVisor with a defined seccomp policy. A container boundary can use Kata Containers with a minimal image. Firecracker with per-session snapshots is a VM option. The ai agent runtime protection piece covers current options.
- What is the latency cost of running each agent session in a sandbox?
Measure startup latency with the image, policy, host capacity, and cold-start behavior your workload will use. A pre-warmed pool can change the operational result materially, but it also creates an image-refresh and capacity-management obligation.
- How does sandboxing interact with LangChain and AutoGen?
The frameworks run inside the sandbox. A local Python interpreter or filesystem read stays within that runtime boundary. HTTP tools and database clients leave it, so their destination controls decide access. Neither framework needs to implement the sandbox itself.
- What about MCP servers?
Model Context Protocol servers can run inside the sandbox as local processes or outside the sandbox with the agent reaching them through the request boundary. Local MCP servers give the agent lower-latency access at the cost of a larger sandbox trust surface. Remote MCP servers put the boundary check on every call. The MCP server authentication piece covers the identity binding.
- Can we skip the sandbox for read-only agents?
The read scope determines the answer. A read-only agent that queries a database is still a network egress path, and the network boundary still applies. A read-only agent that only reads files from a fixed, confined directory has a smaller attack surface and might tolerate a lighter sandbox. The threat model has to justify the choice.