- Sandbox Isolation Models
- Sandbox Egress and Network Policy
- File Access and the Host Filesystem
- Session State and Persistence
- Package Installs and Runtime Dependencies
- Secrets and Credential Handling
- Audit Logs and Observability
- Compliance and Security Review
- Sandbox Pricing and Cost Drivers
- Self-Hosting vs. Managed AI Agent Sandbox
AI agent sandboxes isolate generated code from host systems, but the details — how isolation works, what network access agents have, where files go, how secrets are handled — vary significantly between implementations. This FAQ consolidates the most common questions into one reference, with pointers to the deeper articles in each area.
Sandbox Isolation Models
What does “isolation” mean in an AI agent sandbox?
Isolation means the agent’s code, files, processes, and network access are confined to a bounded environment that cannot affect the host system or other tenants. In practice, isolation is a spectrum: process-level isolation uses OS primitives (namespaces, cgroups, seccomp) to restrict syscalls and resource access; container isolation adds a filesystem and network namespace boundary; and microVM isolation wraps the workload in a lightweight virtual machine with its own guest kernel. Each step up the stack increases the boundary strength at the cost of some startup overhead and operational complexity. See Firecracker for AI Agent Sandboxes for a detailed evaluation framework.
Is Docker enough for running agent-generated code?
Containers give you repeatable images and good resource controls, but all containers on the same host share the host kernel. A kernel vulnerability, or a syscall that slips through the seccomp filter, can affect other workloads. For low-risk, short-lived tasks running trusted or near-trusted code, containers are often adequate when hardened correctly — no privileged mode, minimal capabilities, no Docker socket mounted, read-only root filesystem where possible. For untrusted AI-generated code that may install packages, spawn subprocesses, or call arbitrary shell commands, a stronger boundary is worth evaluating. The answer depends on your actual threat model. See AI-Generated Code Sandbox: Requirements for Production Apps for the verification checklist at each isolation level.
What is the difference between container and microVM isolation?
The key difference is the kernel boundary. Containers share the host kernel; microVMs each run a guest kernel inside a lightweight virtual machine, backed by hardware virtualization (KVM). A microVM-based sandbox using technology like Firecracker provides a VM-style boundary without the full overhead of a traditional VM: startup latency is designed to be fast, the device model is minimal to reduce attack surface, and the guest is isolated from the host kernel by design. The practical implication is that a kernel exploit in the guest does not automatically affect the host or other guests, whereas in a shared-kernel container model it might. See Firecracker for AI Agent Sandboxes for where the microVM boundary helps and where it does not solve the whole problem.
Does one sandbox exist per agent, per user, or per task?
That depends on the platform and how the application is designed. The safest pattern for multi-tenant apps is one isolated sandbox environment per agent run or per task — meaning each user’s session has its own process tree, filesystem, network namespace, and credential scope. Sharing a sandbox across users or across unrelated tasks is the most common source of state leakage in production agent apps. When evaluating a platform, verify that concurrent sessions are isolated at the filesystem, process, and network level, not just at the API routing level. See AI-Generated Code Sandbox: Requirements for Production Apps for the per-session isolation checklist.
Sandbox Egress and Network Policy
Can an AI agent make outbound network calls from a sandbox?
It depends on the sandbox’s egress policy. By default, many sandboxes allow outbound connections, which is convenient for web research, API calls, and package installs. For production workloads running untrusted code, default-open egress is a risk: a compromised or misbehaving agent can exfiltrate data, reach internal metadata services, or pull unexpected code from arbitrary URLs. A stronger production posture is default-deny egress with an explicit allowlist of permitted destinations. Whatever policy you choose, it should be explicit and logged. See Firecracker for AI Agent Sandboxes for how to evaluate network controls.
How is DNS controlled in a sandbox?
DNS is a common gap in egress policy: an allowlist for HTTP destinations does not automatically restrict DNS resolution. An agent that can resolve arbitrary domain names can infer network topology, probe internal names, or use DNS as a side channel even when HTTP is blocked. For a coherent egress policy, DNS resolution should be handled consistently — either pointing to an internal resolver that respects the allowlist, or restricting resolution to approved domains. Verify with your sandbox provider how DNS is scoped in relation to the broader egress policy.
How are package fetches controlled during network-restricted sessions?
Package installs are network operations. If egress is restricted to an allowlist, the allowlist must include the package registries the agent legitimately needs, or the sandbox should provide a pull-through cache within the trusted network. The pull-through cache has the added benefit of serving as an inspection point: you can see which packages are fetched, catch unexpected dependencies, and reduce redundant egress. Some teams use pre-baked sandbox templates for workloads where reproducibility matters more than flexibility, which eliminates runtime package fetches entirely. See the Package Installs section for more on governing runtime installs.
File Access and the Host Filesystem
What file access does a sandboxed agent have?
A sandboxed agent should have access only to the files explicitly mounted into its workspace. For a coding agent, that might be a checked-out repository and a working directory for generated artifacts. For a data analysis agent, that might be an uploaded CSV and an output folder. The agent should not be able to reach the host filesystem, other tenants’ workspaces, the application server’s secrets, or system directories outside its mounted paths. Good practice is to mount source material read-only and provide a separate read-write output directory for generated artifacts. See MCP Server Sandbox: Isolated MCP Servers with Filesystem, Secrets, and Network Controls for how to scope filesystem mounts per tool.
Is the host filesystem accessible from inside a sandbox?
It should not be. A correctly configured sandbox — container or microVM — restricts the agent’s view to its own guest filesystem. Accessing the host filesystem from inside a sandbox is a configuration failure, not an expected behavior. Common mistakes that break this boundary include mounting broad directories (such as a developer’s home directory or /), using privileged mode in containers, or mounting the Docker socket into the sandbox. When evaluating a platform or building your own, verify what is mounted, what the root filesystem permissions are, and whether symlink escapes or archive extraction tricks can reach paths outside the intended workspace.
What happens to files after a session ends?
For ephemeral sessions, the working directory and all generated files are destroyed when the session terminates. This is the right default for code completion, evaluation runs, and any task where reproducibility matters more than continuity. For persistent workspaces (long-running coding agents, iterative development sessions), files can survive across execution calls within a session and may be retained after the session ends if the platform supports workspace persistence or snapshots. The key questions to answer are: who owns a retained workspace, when is it cleaned up, and can one user’s workspace leak to another’s? See AI-Generated Code Sandbox: Requirements for Production Apps for the persistence model checklist.
Session State and Persistence
Is a sandbox session stateful or ephemeral?
Both patterns exist and serve different workloads. Ephemeral sessions start from a clean baseline for every task — no accumulated packages, files, or history. They are easier to reason about and ideal for evaluation runs or one-shot code execution. Stateful sessions preserve files, installed packages, shell history, and environment state across multiple execution calls, which is necessary for multi-step coding agents, interactive data analysis, and long-running workflows. Most production platforms support both. The tradeoff is that stateful sessions require explicit cleanup policies and more careful tenant isolation.
How long does state persist in a managed sandbox?
Session duration varies by platform and plan. Some providers set a default session timeout (commonly 60 minutes to 24 hours), after which the session is terminated and state is lost unless persisted to a snapshot or external storage. Long-running agent workflows — sessions that may pause between LLM calls for minutes or hours — need a platform that supports session pause and resume or autopause to avoid billing for idle time while preserving state. Verify the maximum session length and what happens to in-flight state when a timeout occurs. Novita Agent Sandbox supports sessions up to 24 hours and documents a Pause/Autoresume capability for managing idle time. See Novita Sandbox: A Cost-Effective Alternative to E2B Pro with Seamless Compatibility for a feature comparison.
Can sessions be paused and resumed?
Some platforms support pause and resume, where the session is suspended to disk and can be restarted later from the same state. This is useful for agents that wait on LLM responses between steps, for rate limiting expensive workloads, and for sessions that span multiple user interactions over time. The key things to verify are: how long a paused session can remain suspended, what happens to network connections held during a pause, and whether credentials injected at session start remain valid after resume or need to be refreshed.
Can sandbox state be snapshotted and reused?
Templates and snapshots are related but distinct. A template is a pre-built baseline environment — runtimes, tools, approved packages — that new sessions start from. A snapshot captures the current state of a running session and uses it as the starting point for future sessions. Templates reduce per-session startup overhead and ensure all agents start from a consistent, governed baseline. Snapshots are useful for preserving partial work or warm-starting iterative jobs. Both need governance: who can create them, who can read them, which tenant they belong to, and how they are versioned.
Package Installs and Runtime Dependencies
Can agents install packages at runtime?
Most sandbox environments permit runtime package installs (pip install, npm install, apt-get, etc.) by default because many agent workloads need them. The question is not whether installs are permitted, but whether each install is governed. Ungoverned package installs are one of the highest-risk operations in a sandbox: they pull external code into the execution environment at runtime, can include post-install scripts that execute arbitrary commands, and may introduce supply chain risk.
What policies govern runtime package installs?
A production package policy typically includes some combination of registry allowlisting (only fetch from approved package registries or mirrors), pull-through caches (inspect what enters before it executes), install logging (record the package name, version, source, and result for every install), and optional offline mode (pre-bake dependencies into the template and disallow runtime installs for evaluation pipelines where reproducibility matters). The right policy depends on the workload: a coding agent helping a developer debug code may need flexible package access; an automated evaluation pipeline should probably run from a frozen environment. See Build an AI Data Analyst with Sandboxed Python and Controlled Package Access for a practical implementation example.
Secrets and Credential Handling
How are secrets and credentials handled in a sandbox?
Secrets should be injected narrowly — only the credential a specific task needs, for the duration of that session. The common antipattern is mounting a broad environment file containing all API keys into every session; this means any session, if compromised, can access every credential in that file. Prefer short-lived tokens scoped to the task, and prefer injection mechanisms (environment variables or mounted files) over hardcoding. For the most sensitive credentials, a runtime secrets API that provides values only to an explicitly authorized process offers stronger isolation than a flat environment variable available to all processes.
Can the model see environment variables injected into the sandbox?
Yes, if the environment variable is injected into the process that the model’s code runs in. Environment variables are visible to all processes in the same session by default. The model cannot read them directly from its context window, but generated code that executes inside the sandbox can read them with os.environ, process.env, or equivalent. This is why narrow scope matters: only inject the credentials the task requires, and prefer short-lived tokens so a leaked credential has a limited window of usefulness. Redaction is an application responsibility: do not log full stdout by default if secrets may appear in error messages or print statements.
What happens to secrets when a session ends?
Environment variables and mounted secret files should be cleaned up as part of session teardown. If the platform preserves state across sessions (snapshots, persistent volumes), verify that credentials written to the filesystem or cached by a credential provider are also cleaned up or rotated. Stale credentials in a resumable snapshot are a risk — after session teardown, the snapshot should not retain tokens that were valid only for the original session duration.
Audit Logs and Observability
What events are logged in a sandbox?
Useful sandbox audit records include session creation and teardown (session ID, tenant, template version, resource allocation, duration), execution events (what code or command category ran, start/end time, exit status), package installs (name, version, source, result), outbound network contacts (domains, IPs, ports), files read or written from specific paths, and cleanup result. The goal is to make agent behavior reconstructable after the fact without turning the audit log into a second secrets store. Raw customer files, full command output, and complete prompts generally do not belong in audit logs unless your retention and access controls are specifically designed for that data.
Who can access audit logs?
Access controls on audit logs should be scoped to the operator and, where relevant, the tenant. In multi-tenant platforms, a tenant’s audit records should not be visible to other tenants. For compliance-sensitive deployments, the audit trail needs to be tamper-evident, retained for the required period, and accessible to authorized reviewers (security team, compliance officer) on demand. Ask your sandbox provider what log retention period is provided by default, whether logs can be exported to your own SIEM or storage, and what access controls protect the log data.
Compliance and Security Review
What compliance review is needed before using a sandbox in production?
The specific requirements depend on your industry and jurisdiction, but the standard questions for any production agent system include: what data enters the sandbox (and is that data subject to GDPR, HIPAA, SOC 2, or other frameworks), where is the sandbox hosted and does that satisfy data residency requirements, what is the isolation model and can you document it to an auditor, how are credentials managed and rotated, and what does the audit trail look like? Most security reviews will also ask whether generated code could reach production databases, internal admin surfaces, or customer data outside the intended scope. These are architectural controls, not just vendor certifications.
What questions should security teams ask when evaluating an AI agent sandbox?
A practical evaluation checklist for security review:
- Isolation: What is the boundary — process, container, or microVM? Is each agent session isolated at the filesystem, process, and network level?
- Egress: What is the default egress policy? Can outbound destinations be allowlisted? How is DNS controlled?
- Secrets: How are credentials injected? Are they scoped to the task? Are they cleaned up on session teardown?
- Audit: What events are logged? Who can access logs? What is the retention period?
- Data residency: Where are sandboxes hosted? Can the deployment be scoped to a specific cloud region or account?
- Compliance posture: Does the provider hold relevant certifications (SOC 2, ISO 27001)? What is their shared responsibility model?
- Network reach: Can a sandbox reach internal metadata services, private APIs, or other tenants’ resources? How is lateral movement prevented?
Frame these as questions to evaluate rather than requirements any single vendor automatically meets. Security and compliance claims in vendor documentation should be verified against current product docs, not taken at face value. For teams with regulatory or contractual requirements, have your security team complete the review before production deployment, not after.
When is BYOC (bring your own cloud) or VPC deployment relevant?
Data residency requirements, network security policies, or regulatory constraints that prohibit data leaving a specific cloud account are the primary reasons teams choose BYOC or VPC deployment over a shared managed service. Running sandboxes inside your own AWS or GCP VPC means the execution environment is within your network perimeter, your cloud account’s access controls apply, and egress from the sandbox can be governed by your existing network policies. The tradeoff is operational responsibility: you own the infrastructure management, patching, and scaling. Novita Agent Sandbox documents BYOC deployment into AWS or GCP accounts as a feature for teams with these requirements. Verify current availability and configuration options in the Novita Agent Sandbox documentation.
Sandbox Pricing and Cost Drivers
What drives sandbox costs?
Sandbox costs are typically a combination of compute time (vCPU and memory billed per second or per minute), session overhead (a per-session startup fee on some platforms), persistent storage above the included free tier, and outbound data transfer (egress). The relative weight of each depends on your workload: a short-session code interpreter is mostly compute; a browser automation agent that downloads large files may generate significant egress; a persistent coding workspace will accumulate storage. Idle time handling is a major differentiator — platforms with autopause stop billing when a sandbox is waiting on an LLM response, which can reduce costs significantly for interactive workflows. See AI Agent Sandbox Pricing Models: Per-Session, Compute, Storage, and Egress for a detailed breakdown of each pricing axis.
How do session time, compute, and egress interact in cost?
For most workloads, compute time dominates. A 10-minute coding session on 1 vCPU costs more than 1 GB of egress at typical rates. But the interaction matters for specific workloads: a data agent that downloads a large training dataset will generate egress charges that dwarf the compute cost. A browser agent that holds sessions open between LLM turns will accumulate idle compute if autopause is not enabled. The practical approach is to estimate each dimension against your actual workload profile before committing to a platform. Novita Agent Sandbox bills per second based on actual vCPU and memory usage with no per-session startup fee; as of mid-2026, 1 vCPU is priced at $0.0000098/s. (Source: Novita AI pricing page, verified in published documentation. Always verify current rates before budget planning.)
Self-Hosting vs. Managed AI Agent Sandbox
When should teams self-host rather than use a managed sandbox?
Self-hosting (running your own sandbox infrastructure, often on Firecracker or a comparable microVM layer) makes sense when: data residency or network policy requirements prohibit using a third-party managed service, the workload volume is high enough that the managed service cost exceeds the operational cost of running your own infrastructure, or the team has existing platform engineering capacity and wants full control over the isolation model, image governance, and network policy. Self-hosting is harder than it looks: managing kernels, root filesystems, images, snapshots, rate limiters, metrics, cleanup, and multi-tenant isolation is real work. See Firecracker for AI Agent Sandboxes for what the operational scope looks like.
When does a managed sandbox make more sense?
For most teams building coding agents, data analysis tools, browser automation workflows, or evaluation pipelines, a managed sandbox is the faster path to production. The platform handles infrastructure provisioning, security hardening, image updates, scaling, and lifecycle management. The team focuses on the agent architecture, not the sandbox internals. The cost comparison is not just cloud compute rates: factor in the engineering time to build and maintain the isolation layer, the compliance work to document it, and the incident response when something unexpected happens. For teams without dedicated platform engineering capacity, managed services typically reach production faster and maintain a lower total cost of ownership. See AI Agent Sandbox Pricing Models for a framework to compare managed vs. self-hosted total cost.
What questions should teams ask when evaluating managed sandbox providers?
Practical evaluation questions beyond headline pricing:
- What is the isolation model per session (microVM, container, process)?
- What is the default and configurable egress policy?
- What package install governance options exist?
- How are secrets injected and cleaned up?
- What audit log data is available and how is it accessed?
- What are the session length and concurrency limits at your required tier?
- Does the provider support BYOC or VPC deployment?
- What is the pause/resume behavior and how does it affect billing?
- How does startup latency behave at scale (warm pool, snapshot, cold boot)?
