Agents now write and run code faster than anyone can read it. As of September 2026, coding agents initiated more than half of Vercel deployments. An agent sandbox is an isolated environment for running untrusted code. You control access to production databases, host credentials, network destinations, and other agents’ files through the permissions you configure.
Copy link to headingAgent sandboxes vs. development environments
A development environment gives you somewhere to build and test software. A secure sandbox restricts what the untrusted code can do. The following table compares their intended roles. Actual isolation and access depend on the platform and configuration.
In either environment, scope production credentials to the resources and operations required by the task.
Copy link to headingWhy agents need explicit execution limits
An agent can generate and run a command before you review it. Reviewing the final code may miss an earlier command that copied a secret or deleted data.
Files, issues, web pages, and logs can contain prompt injections. If the agent follows an attacker’s instructions, it may run commands unrelated to your task.
Those commands can read any files the agent’s permissions allow, including tokens left by earlier tasks. Agents running under one user may also be able to open each other’s checkouts and cached credentials.
A prompt that forbids deletion doesn’t revoke filesystem or API permissions. Enforce those restrictions in the runtime. Sandbox restrictions apply only to work you route through the sandbox, so tools that run elsewhere need their own authorization checks. Keep the coordinating application’s credentials separate from generated-code execution.
Copy link to headingSet four core isolation controls
Copy link to headingKernel and process isolation
Conventional Linux containers share the host kernel. Namespaces separate resources, while control groups manage resource usage. Docker also uses capabilities and system call filtering, and its security depends on the runtime configuration.
A micro virtual machine (microVM) has its own guest kernel. Code inside it makes system calls to that kernel. Security still depends on the virtualization software and host configuration.
Firecracker emulates fewer devices than a general-purpose virtual machine to reduce the virtualization software exposed to guest code.
An exploitable container kernel or runtime flaw can compromise the host and threaten other workloads. CVE-2019-5736, also documented by Red Hat, allowed attackers under specified conditions to overwrite the host’s runc binary and obtain host root access.
Copy link to headingFilesystem isolation
Filesystem isolation controls which files code can read and change.
A private filesystem separates a workspace from host files, but anything you mount or copy into it becomes available to sandbox code with the required permissions. Copying a home directory may expose Secure Shell (SSH) keys and cloud credentials.
Mount or copy only the files the task requires. Review shared directories before exposing them.
For multi-agent work, decide what agents may share. Separate, unprivileged Linux users can restrict file access. Use separate sandboxes when agents also need independent kernels.
Copy link to headingNetwork isolation
Network rules control which services code can reach. The same outbound connection that lets code download dependencies or call APIs can let it send private data to an attacker.
Allow the destinations your task requires. Broad provider domains and wildcard entries expose more endpoints. Even an allowed service may offer attacker-controlled accounts or writable destinations.
On shared infrastructure, an allowed hostname may still route a request to another application. Use request-level authorization or a trusted proxy where hostname filtering is insufficient, as described in Vercel’s sandbox firewall guidance.
Copy link to headingCredential isolation
Code inside a microVM can delete a production database if you give it a token with deletion permissions and access to the API.
Keep raw credentials out of generated code where possible. If code needs direct access, use the narrowest permissions and shortest lifetime the service supports.
Removing credentials doesn’t remove sensitive files or information already in the agent’s context. Restrict access to that data, too.
Simon Willison’s “lethal trifecta” combines private-data access, untrusted content, and external communication. A messaging tool or API can provide that communication channel without unrestricted internet access.
Set resource limits and timeouts. Log execution, check dependencies, and plan how to recover from destructive actions.
Copy link to headingChoose controls for what the agent can do
Run generated scripts and arbitrary shell commands in a sandbox configured for the files and services they need.
An agent limited to predefined tools may not need a separate microVM per task. Its tools still need authorization, scoped credentials, input validation, and restrictions on sensitive actions.
A Slack tool can disclose data to the wrong recipient. A parameterized query can prevent SQL injection while returning records that the agent shouldn’t access. Your application must authorize the action, even when the input matches the tool’s schema.
The Open Worldwide Application Security Project (OWASP) distinguishes tool misuse from ASI05 Unexpected Code Execution.
Check each tool’s implementation and permissions. A tool with a limited interface can still execute generated SQL or call an API with broad credentials.
Copy link to headingKeep policy outside the untrusted code’s control
Firewall administration requires specific Linux capabilities. If untrusted code has administrative privileges inside a guest, enforce network restrictions outside that guest.
Keep infrastructure credentials and policy-management tools under the coordinating application’s control.
The AI SDK supports tool approval through needsApproval. Your application shows the proposed action to a person and sends their approval decision before the tool runs.
Approving a command doesn’t restrict what happens after it starts. A tool that executes arbitrary code may need both approval and sandbox restrictions.
In April 2026, The Register reported that a coding agent deleted production data in 9 seconds using a token it found on disk. The token had been created for custom-domain work but granted broader permissions. The agent used an authenticated API request without a kernel escape.
Copy link to headingAccount for sandbox latency and usage costs
When you choose a sandbox, measure how long it takes to prepare a usable workspace and what each run costs.
Firecracker specifies a cold-boot time of 125 ms or less under documented test conditions. The measurement covers the interval between the instance-start API call and the first guest user-space process. It uses a minimal kernel and root filesystem on specified hardware, so it doesn’t represent a working development environment.
For resumed tasks, filesystem restore time also matters. Vercel reduced its 75th percentile snapshot restore time from over 40 seconds to under one second through parallelization and local caching. Benchmark your own repository through the first useful command, including any dependency installation or filesystem restoration.
Vercel Sandbox meters sandbox creations, active CPU time, and provisioned memory, among other resources. Creating a fresh sandbox for every task adds creation usage each time. Active CPU excludes time spent waiting for model responses and network requests, but memory remains metered while the sandbox runs. Saved snapshots incur separate storage usage. Compare fresh starts with snapshot restores using representative tasks and the current pricing metrics.
Copy link to headingHow Vercel Sandbox implements these controls
Copy link to headingDedicated microVMs and private filesystems
Vercel Sandbox runs each sandbox in a Firecracker microVM with a dedicated kernel and private filesystem.
You can run privileged workloads inside the microVM:
Docker and other container runtimes
Virtual private network (VPN) clients
Filesystem in Userspace (FUSE) mounts
Run these workloads with sudo. Keep privileged execution under trusted application control, especially when agents share an environment.
The sandbox doesn’t automatically inherit your application’s environment variables. Values you supply through the Sandbox SDK’s env option are available to code inside it. That code can connect to external resources if your network configuration and credentials allow it.
Copy link to headingNetwork policies and credential brokering
Your application can set and update the sandbox’s network policy. Vercel supports allow-all, deny-all, and user-defined policies. The default is allow-all, so restricted outbound access requires explicit configuration.
The firewall can inject credentials into outbound HTTP requests so code doesn’t receive the raw secret values. The code can still use those credentials through the firewall, so restrict the permissions and operations they allow.
Notion Workers uses credential injection so that the generated code can authenticate to external services without directly receiving API keys.
Copy link to headingPersistence and forking
Persistence is enabled by default. When a session stops, Vercel snapshots its filesystem and restores it when the sandbox resumes. Pass persistent: false for a disposable workload.
Each resumed session starts a fresh microVM from the saved filesystem. Files left by a compromised session can survive into the next one. Review them before reusing the sandbox for a different task or trust level.
Sandbox.fork() creates a new sandbox from an existing sandbox’s current snapshot. It copies the source configuration, including environment variables, unless overridden. Without a current snapshot, the fork starts fresh with the source image and configuration.
Forks let parallel agents start with the same saved files. Check the files and credentials a fork inherits before assigning it to another agent.
Copy link to headingSeparate Linux users for agents
Vercel Sandbox’s multi-agent APIs let you create a Linux user for each agent, with a private home directory. Commands running as those unprivileged users can’t list another user’s home directory or read or write files inside it. Use Linux groups to grant agents access to shared directories.
This API is available through the JavaScript SDK (@vercel/sandbox). The agents share one microVM and kernel. Privileged execution can bypass ordinary file permissions, so use separate sandboxes when agents need independent kernels.
You can start a new project or browse templates for an agent setup to build from.
Copy link to headingFrequently asked questions
Copy link to headingIs a Docker container enough for an agent?
A conventional Linux container shares the host kernel. Whether that provides enough isolation depends on the code, its privileges, and the surrounding infrastructure. MicroVMs add a separate guest kernel. Both need filesystem, network, and credential controls.
Copy link to headingDoes every AI agent need a sandbox?
Agents that execute arbitrary code need an appropriate execution boundary. Agents limited to predefined tools may not need a separate microVM per task. Those tools still need authorization, scoped credentials, input validation, and restrictions on sensitive actions.
Copy link to headingHow much latency does sandboxing add?
Measure your workload through the first useful command after creation or resume. Include repository setup, dependency installation, and filesystem restoration. A published virtual machine boot time won’t include all of that work.
Copy link to headingDoes sandboxing replace credential controls?
No. Isolated code can use any permissions you grant it. Scope credentials narrowly, limit their lifetime, and authorize sensitive operations separately. Credential brokering keeps raw secrets outside the execution environment, but the permissions available through the broker still need restrictions.