How Secure Is the AI Sandbox for Executing Code?

An AI sandbox is designed to limit the blast radius of code execution — through process, container, or microVM isolation — but the actual security posture depends on how the platform configures filesystem scope, network egress, secrets injection, audit logging, and lifecycle controls around that boundary. No sandbox is completely secure by design; all reasonable claims come qualified. What a well-designed sandbox can offer is a controlled, observable environment where generated code is less likely to escape, exfiltrate data, or compromise host infrastructure — and where the evidence trail is good enough to understand what happened when something goes wrong.

What “secure” actually means for a sandbox

Security evaluation questions for an AI sandbox are different from questions about a traditional web application. The surface area shifts. The sandbox is not protecting one application from external attackers — it is protecting the host environment, neighboring workloads, and downstream systems from code that the AI model itself generates and executes.

That changes how you frame the evaluation. The key questions are:

• What can code running inside the sandbox do to the host OS, filesystem, or network?
• Can code inside the sandbox reach internal services, credentials, or other tenants’ data?
• If the generated code behaves badly — installs something malicious, exfiltrates a file, or exhausts resources — can you detect it and reconstruct what happened?
• What remains controllable by a human reviewer before execution reaches external or sensitive systems?

The answer to each question depends not on a single technology label but on the full configuration: the isolation layer, plus the policies and controls layered around it.

Isolation models: container, gVisor, and microVM

The isolation boundary is the foundational choice. Each model offers a different tradeoff between startup speed, compatibility, and separation from the host.

Process/container isolation uses Linux namespaces, cgroups, and seccomp profiles to limit what a process can access. Containers start fast and are well-supported, but all containers on a host share the kernel. A syscall that bypasses the seccomp filter, a container escape via a kernel vulnerability, or a misconfigured capability set can reduce the effective boundary significantly.

Intended security properties:

• Filesystem and network namespace isolation per container
• cgroup-enforced CPU, memory, and I/O limits
• Seccomp filtering of dangerous syscalls

What this does not protect against:

• Kernel-level exploits (all containers share the host kernel)
• Privileged containers or mounted host sockets that reduce the boundary to near-zero
• Misconfigurations: host-network mode, host PID namespace, broad capability grants

gVisor interposes a user-space kernel between the container and the host kernel. Guest syscalls are handled by gVisor’s kernel emulation layer, and only a narrower set of syscalls reach the real host kernel. This reduces the syscall attack surface significantly compared to a normal container.

Intended security properties:

• Most guest syscalls are intercepted and handled in user space
• Smaller host kernel attack surface
• Compatible with container tooling (Docker, Kubernetes)

What this does not protect against:

• gVisor’s own user-space kernel is a complex trust boundary; vulnerabilities in it can affect the host
• Higher per-syscall overhead can affect performance-sensitive workloads
• Compatibility gaps: not every syscall is emulated, which can break some programs

MicroVM isolation (Firecracker-style) runs each workload inside a lightweight virtual machine backed by KVM, with its own guest kernel, virtual devices, and a hypervisor boundary. A kernel exploit in the guest does not directly affect the host kernel or sibling workloads.

Intended security properties:

• Hardware-backed VM boundary (KVM)
• Each task can get a separate guest kernel
• Minimal device model reduces host attack surface
• Supports seccomp, cgroups, namespaces, and jailer within the guest

What this does not protect against:

• Hypervisor vulnerabilities (KVM, Firecracker itself) are still a real but smaller risk
• The VM boundary is only as strong as the policies around it: network egress, filesystem mounts, secrets, and egress logging are all separate decisions
• Compatibility and startup overhead: a complex agent workload may need a heavier image than expected

The isolation model sets the floor. What happens above it — filesystem permissions, network rules, secrets handling — determines the actual ceiling.

Filesystem and workspace controls

The filesystem is where most practical sandbox breaches happen. Even with strong process isolation, an agent that can read credentials from mounted volumes, write outside its workspace, or enumerate the host filesystem is not safely contained.

A well-designed sandbox filesystem policy separates the workspace into zones with explicit access rules:

Zone	Recommended access	Risk if misconfigured
Input files (source code, user uploads)	Read-only when possible	Agent modifies inputs, corrupts source, or reads adjacent tenants’ files
Working directory	Read-write, scoped to task	State leaks across sessions; generated code persists after cleanup
Package and build cache	Read-write, controlled by registry policy	Install scripts execute arbitrary code; poisoned packages enter the workspace
Output artifacts	Export gated by review or policy check	Sensitive data in generated files leaves the sandbox without inspection
Secrets and credentials	No file mounts; injected by reference	Credentials visible to generated code, logged in stdout, or left on disk

What to verify when evaluating a sandbox:

• Is the workspace scoped per task and per tenant, or shared across sessions?
• Can generated code traverse outside its assigned directory?
• Are input files writable by default, or does the platform require explicit opt-in?
• Is the root filesystem read-only outside the designated working directory?
• What happens to workspace files after the session ends?

A sandbox that mounts the host filesystem broadly, or that reuses the same directory across tenants without a reset, undermines whatever isolation the kernel boundary provides.

Network egress and supply chain considerations

Network access is the most common source of post-execution risk in AI sandboxes. Default-open egress allows generated code to exfiltrate data, reach internal services, download malicious payloads, or call arbitrary third-party APIs — all without triggering the isolation boundary.

Egress controls to evaluate:

Control point	Intended protection	Common gap
Default egress policy	Limits unexpected outbound connections	Many sandboxes default to open; only close on explicit request
DNS resolution	Prevents resolving internal hostnames from inside the sandbox	Internal metadata endpoints or service discovery often use DNS
Allowlisted destinations	Restricts external calls to approved domains or IP ranges	Overly broad allowlists include CDNs or clouds that could proxy further
Package registry controls	Limits which registries pip, npm, cargo, etc. can use	Open registries allow typosquatting and supply chain attacks
Inbound listener policy	Prevents the sandbox from opening ports that accept connections	A rogue listener can bridge the sandbox to the host network

Supply chain considerations deserve special attention for AI sandboxes because models frequently generate pip install, npm install, or apt-get install commands. Each install is effectively untrusted code entering the execution environment. A hardened sandbox uses:

• Allowlisted registries or pull-through mirrors
• Hash-pinned or lockfile-governed dependencies when the task allows it
• Size limits and timeout controls on install operations
• Logging of all fetched package names, versions, and origins
• Approval gates for packages that deviate from policy

If the sandbox allows arbitrary registry access with no logging, supply-chain poisoning from generated code is a real and practical risk — not a theoretical one.

Secrets injection and environment variable exposure

Secrets are the highest-stakes part of sandbox configuration. If a credential is visible to generated code — even briefly — it can be exfiltrated through a network call, written to a file, or leaked through stdout before any cleanup happens.

What creates exposure:

• Broad environment variable blocks that include credentials the current task does not need
• Mounting credential files (.aws/credentials, .npmrc, service account keys) into the workspace
• Logging tool calls, prompts, or model output that contains secrets in plaintext
• Long-lived or over-scoped credentials that remain valid long after the session ends

Intended safer patterns:

• Inject credentials by reference (a credential ID or short-lived token) rather than by value
• Scope each credential to the specific action the task needs (read-only S3 access for this session, not admin access to the account)
• Rotate or revoke credentials at session end
• Redact known secret patterns from stdout, stderr, trace logs, and screenshots before they reach model-visible tool responses

The risk here is not just a malicious model. A model that is behaving normally can still inadvertently log a secret in a debug message, write it to a file, or include it in a generated code comment. Defense-in-depth means reducing the credential’s scope, visibility, and validity window — not relying on the model to handle it safely.

State persistence and cleanup

How a sandbox handles state between sessions affects both security and correctness. State persistence decisions are often made for developer convenience (“keep my workspace warm”), but they carry security tradeoffs.

Fresh starts — booting a clean environment for each task — are the easiest to reason about. Each session begins from a known, policy-controlled baseline. No residual files, credentials, installed packages, or shell history from a prior session affect the current one. The tradeoff is startup overhead.

Persistent workspaces carry risks that compound over time:

• Installed packages accumulate, including any that were fetched from untrusted sources
• Generated files may contain sensitive content from earlier agent runs
• Shell history, browser caches, and background processes can persist state across task boundaries
• Credentials from an earlier session may still exist in memory, environment, or on disk

What to verify:

• After a session ends, are all writable directories wiped, all processes killed, and all network connections closed?
• If a workspace is reused, is it reset to a known-good snapshot, or does it accumulate state incrementally?
• Are snapshots versioned, audited, and owned by a specific user/tenant, or shared across contexts?
• What is the retention policy for generated artifacts and logs?

Cleanup is not glamorous, but a sandbox that leaks state is a sandbox that loses the isolation properties its boundary was designed to provide.

Audit logs and observability

Audit logs are what turn “designed to be isolated” into “we can verify what happened.” Without good observability, a sandbox breach or data leak may not be detectable until well after the fact.

What useful sandbox audit logs should capture:

Event type	What to record	What NOT to log by default
Command execution	Command, working directory, start time, exit code, duration	Full stdout/stderr for commands that may contain secrets
Filesystem operations	Files read/written/deleted, paths, sizes	Raw file contents (especially user uploads)
Network calls	Destination domain/IP, method, response code, bytes	Request/response bodies unless specifically needed for audit
Package installs	Package name, version, registry origin, install duration	Binary content or lockfile full text
Process spawning	Parent PID, child command, user	Memory dump or full argv when secrets may be present
Session lifecycle	Start, end, cleanup result, resource usage	Credential values, model prompts, user data

Logs should be:

• Tamper-evident and stored outside the sandbox (a log written inside the sandbox can be deleted by code running there)
• Accessible to security teams without exposing customer data unnecessarily
• Structured (machine-readable) rather than free-text dumps
• Retained long enough to support incident investigation

The goal is to reconstruct what happened from evidence the sandbox itself captured, without relying on the model’s summary of its own actions.

Security properties table

A clear summary of what a well-configured AI sandbox is designed to protect against, and where the limits lie:

Security property	Designed to protect against	Requires additional controls
Process/container isolation	Code accessing host OS filesystem, devices, other processes	Kernel exploits still possible; seccomp and capability tuning required
MicroVM isolation	Host kernel compromise from guest code	Hypervisor vulnerabilities; egress, filesystem, and secrets still separate decisions
Filesystem scoping	Code reading adjacent tenant data or host credentials	Must explicitly define mounts; shared caches or volumes can bridge tenants
Network egress control	Exfiltration, reaching internal services, C2 callbacks	Default-open configurations require explicit lockdown; DNS must also be controlled
Registry allowlisting	Supply-chain attacks via package installs	Open registries and unlogged installs leave this risk open
Short-lived scoped credentials	Persistent credential compromise after session	Broad env vars or file-mounted credentials still expose secrets to generated code
Session cleanup	State leakage between tenants or sessions	Persistent workspaces without reset carry prior-session risk
Audit logging	Post-incident reconstruction	Logs inside the sandbox can be deleted; must be exported to tamper-evident storage

No row in this table represents a complete guarantee. Each represents an intended protection that depends on correct configuration.

Scenario-based risk assessment

Running untrusted user code in a multi-tenant product

Risk level: High. This is the scenario where sandbox security matters most. Users submit code that the product executes on their behalf — often with access to user-owned data, API credentials, or a persistent workspace.

Key controls to verify:

• Is there a separate isolation boundary per user or per task, or is isolation shared across tenants?
• Can user A’s code reach user B’s workspace, credentials, or output files?
• If user code installs packages, are those installs logged and registry-controlled?
• Is there a rate limiter and resource quota so one user cannot exhaust shared infrastructure?
• Are credentials per-user and per-session, not shared service accounts?

What to ask a vendor: Describe how tenant A’s data and credentials are separated from tenant B’s, what happens if tenant A’s code tries to read /proc, /etc, or environment variables from sibling processes, and where audit logs are stored.

Internal automation agents with access to production systems

Risk level: Medium to high, depends on credential scope. A coding agent, data pipeline agent, or DevOps agent with access to production databases, cloud resources, or CI/CD systems carries risk proportional to those credentials.

Key controls to verify:

• Are production credentials injected with the minimum required scope?
• Is there a human review gate before actions that mutate production state?
• Are all external API calls logged with enough detail to reconstruct the action?
• What happens if the agent generates a destructive command (drop table, delete bucket)?

What to ask: What is the approval gate for high-impact tool calls? Can the agent be halted mid-run, and is its state reconstructable after an unexpected stop?

Evaluation and RL runs with many parallel tasks

Risk level: Medium. Large-scale evaluation jobs may run hundreds of parallel sandboxes across user-supplied prompts and environments. The risk is less about a single breach and more about accumulated exposure: a dataset that leaks labels, a reward model that can be queried to reverse-engineer training data, or a sandbox that runs too long and consumes unexpected resources.

Key controls to verify:

• Is each evaluation task in a separate sandbox with a clean state?
• Are resource quotas enforced per task to prevent runaway compute?
• Can task inputs or outputs be inspected without the evaluation infrastructure seeing the full dataset?
• Is there a timeout and automatic cleanup for stuck tasks?

Low-risk internal code interpretation

Risk level: Low to medium. Trusted code, internal data transformation, deterministic operations, or read-only analysis tasks have a much smaller attack surface.

A container-level boundary with good filesystem scoping and no network egress may be sufficient. A microVM boundary adds cost and startup overhead that may not be justified by the actual risk.

Where Novita Agent Sandbox fits

Novita Agent Sandbox is designed for agent workloads that need an isolated runtime for code execution, file operations, subprocess control, and longer-running sessions. It is intended to provide a managed execution boundary so generated code runs in a contained environment rather than directly on application servers, developer machines, or shared runners.

For teams building on Novita AI’s model APIs — accessing LLMs for coding agents, data analysis tools, or browser automation — the Agent Sandbox can be the execution layer where model-generated actions run. That separation is the practical goal: the model plans and proposes; the sandbox is designed to contain execution.

When evaluating Novita Agent Sandbox (or any sandbox) for a security-sensitive use case, apply the same framework in this article: verify the isolation boundary, ask how filesystem mounts are scoped, confirm what the egress policy is and whether it is default-deny, ask how credentials are injected and revoked, and confirm what audit log data is available and where it is stored. Documentation gaps are worth noting explicitly — if a security property is not documented, do not assume it is implemented.

The current Novita Agent Sandbox documentation covers API, lifecycle, and integration patterns at novita.ai/docs. Security-specific documentation on isolation model, network controls, and audit log access is an area worth verifying directly with the team for compliance-sensitive deployments.

FAQ

Is an AI sandbox completely secure for running untrusted code?

No sandbox is completely secure. All reasonable security claims should be qualified. A well-configured sandbox is designed to limit the blast radius of code execution — it is not a guarantee against all possible exploits or misconfigurations. The effective security posture depends on the isolation model, filesystem policy, network controls, secrets handling, and audit logging in combination.

What is the difference between a container sandbox and a microVM sandbox for AI agents?

Containers share the host kernel; microVMs have their own guest kernel backed by a hypervisor (e.g., KVM with Firecracker). A microVM boundary is designed to be harder to escape via kernel vulnerabilities, but it does not automatically provide better network, filesystem, or secrets controls — those are separate configuration decisions in both models.

Can AI-generated code exfiltrate data from inside a sandbox?

It depends entirely on the network egress policy. If outbound connections are unrestricted, generated code can attempt to exfiltrate data through HTTP calls, DNS lookups, or package registry interactions. A sandbox with default-deny egress and an explicit allowlist is designed to prevent this; an open-egress sandbox is not.

How should credentials be passed to code running in an AI sandbox?

Prefer short-lived, narrowly scoped credentials injected by reference rather than broad environment variable blocks or file-mounted credential stores. Revoke or rotate credentials at session end. Redact known secret patterns from logs and model-visible tool responses. Do not pass production admin credentials to a sandbox that may run user-submitted or AI-generated code.

What audit logs should I expect from a secure AI sandbox?

At minimum: session start/end, command execution with exit codes, filesystem writes and deletes, outbound network destinations, and package installs with registry origin. Logs should be stored outside the sandbox in tamper-evident storage. Raw file contents, credential values, and full model prompts should generally not be logged by default.

Does the sandbox protect against supply chain attacks from package installs?

Only if the platform enforces registry allowlisting, logs all install operations, and optionally uses hash-pinned or lockfile-governed installs. An open registry policy with no logging leaves the supply-chain risk largely unmitigated, regardless of the isolation model.

What should I ask a sandbox vendor about security?

Ask: What is the isolation model and what is each tenant’s boundary? Is egress default-deny or open? How are credentials injected and revoked? What audit logs are available and where are they stored? How is state cleaned up between sessions? Are there documented security properties — and where are the gaps?

Recommended articles

• Firecracker for AI Agent Sandboxes: Benefits, Limits, and Evaluation Questions
• MCP Server Sandbox: Isolated MCP Servers with Filesystem, Secrets, and Network Controls
• AI-Generated Code Sandbox: Requirements for Production Apps