A sandbox without a network boundary is only half a sandbox

Compute isolation is only half the problem

Running untrusted code safely means more than keeping it off the host. As AI agents take on tasks like reading files, running commands, and generating their own programs, the code they produce inherits real network access. A microVM can stop that code from touching the host or neighboring workloads, but it cannot stop the code from phoning home with data, probing internal services, attacking remote systems, or abusing credentials that live inside the environment.

Containment of the process is not containment of its consequences. A complete sandbox needs both compute isolation and explicit control over its network authority: where code can connect, which credentials it can use, and how those permissions evolve over the workload's lifecycle. These controls belong to the security boundary itself, not as an afterthought.

The second boundary: the network

Compute isolation answers one question: what can a program access on its own machine? Network isolation answers the other: what can it reach, or attack, beyond that machine? A prompt injection hidden in a repository issue, log entry, dependency, or source file might tell an agent to upload private data. The generated code doesn't need to escape its microVM to do damage—with unrestricted outbound traffic, it can simply send anything it reads to an external server.

Recent security research makes the pattern clear: untrusted code doesn't need to cross a VM boundary to escape. It just needs one network path the security model missed. That path may be a DNS resolver in an otherwise disconnected environment, an allowlist that fails open, a hostname the policy engine and proxy interpret differently, or a trusted package service used as a relay. The kernel and VM may keep working as designed while containment still fails, because the real security boundary includes DNS, proxies, identity services, internal subnets, and every intentionally permitted destination.

Selective connectivity over all-or-nothing

Full isolation closes the network path but makes many workloads impractical—agents often need to clone a repository, pull a dependency, call an AI model, query a database, or upload a result. Unrestricted internet is not the only alternative. A practical policy model should support:

• Access to a specific AI provider, but no other public destination.
• One object storage bucket, rather than an entire cloud network.
• A single private service, with the rest of the private address space blocked.
• Dependency access during trusted setup, removed before generated code executes.
• Authenticated API calls without placing the API key inside the sandbox.

Domain rules and CIDR ranges solve different problems. Domain policies handle services with shifting IPs or many unrelated hostnames on one address. CIDR policies work across protocols and give precise control over fixed infrastructure and private networks. Connectivity should also be temporary: a workflow might start with registry access, narrow before untrusted execution, briefly allow an output endpoint, and end with no outbound access—all without restarting the workload.

Enforcing the boundary on the host

The Vercel Sandbox firewall runs on the host, outside the microVM, where code inside the sandbox cannot modify or disable it. Linux networking transparently redirects outbound TCP connections and DNS queries through the firewall, so workloads need no proxy configuration, and the firewall retains each connection's original destination.

For domain-restricted connections, the firewall inspects the start of the TLS handshake and extracts the Server Name Indication (SNI) to identify the requested hostname before opening an upstream connection. It checks that hostname against the domain policy and the destination address against the CIDR policy. Allowed TLS connections pass through without decryption; the firewall reads only the unencrypted handshake fields needed for policy enforcement, then connects the workload directly to its destination.

For configured domains that require HTTP-level inspection, the firewall selectively terminates TLS with a sandbox-unique certificate authority, then matches requests by hostname, path, method, query, or headers. DNS traffic is filtered against the same domain policy, giving layered control over both where a sandbox connects and what authority a connection receives.

Credentials stay outside the sandbox

A credential stored in an environment variable or file becomes a transferable bearer token. Every program inside the sandbox can read it, and malicious code can copy it to a third-party service where it outlives the sandbox session. Instead of storing credentials in the environment, Vercel Sandbox injects them at the host network boundary. The firewall creates a dedicated certificate authority just in time, adds it to the sandbox's trusted certificates, and for a configured destination selectively terminates TLS, adds or replaces the authentication header, and opens a new TLS connection upstream.

The credential never enters the microVM. It never leaves the host unencrypted, and the certificate authority dies with the sandbox. Injection also confines the credential's use: the firewall sends it only to its configured destination, so leaking the sandbox's filesystem or environment transfers no authority. Matchers can restrict further by path, method, query, or headers—generated code might post results to one endpoint without reading other resources from the same API.

Put your own policy in the path

Static allowlists cannot express every requirement. Some workloads need payload inspection, business rules, audit trails, or authorization decisions based on context only you have. Request forwarding routes selected HTTPS requests through a proxy you control, which receives the original request along with a Vercel-issued OIDC token identifying the team, project, and sandbox. That proxy becomes a programmable policy point that can:

• Redact sensitive fields before a request leaves the environment.
• Enforce per-user or per-sandbox authorization.
• Route package downloads through supply-chain scanning and block non-compliant artifacts.
• Log requests and responses for compliance.
• Exchange a sandbox identity for a narrowly scoped credential.
• Reject operations that don't match organizational policy.

The policy and its secrets remain outside the sandbox, even when the code under governance has root inside its microVM.

Egress control in the base product

The security posture of a sandbox shouldn't depend on a paid plan. Every Vercel Sandbox includes compute isolation and a full egress firewall for defining communication boundaries, with no payment method required. The goal is not offline-by-default, but explicit authority: which destinations are reachable, which private ranges are off-limits, which requests can carry credentials, which operations must pass extra policy, and when communication stops entirely. These are properties of the execution environment, not controls to bolt on after a workload reaches production.

Sandbox policies can be replaced dynamically. A policy allowing outbound connections to one API with credential injection for a single operation can be swapped for another while the sandbox runs:

import { Sandbox } from '@vercel/sandbox';
const sandbox = await Sandbox.create({
  networkPolicy: {
    allow: {
      "ai-gateway.vercel.sh": [{
        transform: [{
          headers: {
            "Authorization": `Bearer ${process.env.AI_GATEWAY_TOKEN}`
          }
        }],
      }]
    }
  }
});

await sandbox.update({ networkPolicy: 'deny-all' });

A sandbox is defined by what its code can reach and what authority it receives, not just by where it runs. The network is part of the sandbox.