Running untrusted code safely requires more than separating it from the host. You also have to control what that code can reach.
This matters more as AI agents gain the ability to read files, execute commands, install packages, and generate programs of their own. A microVM can prevent that code from accessing the host or another workload. By itself, it cannot stop the code from exfiltrating data, probing internal services, attacking systems elsewhere on the internet, or using credentials available inside the environment.
Isolation without egress control contains the process, not its consequences.
A complete sandbox therefore needs both compute isolation and control over the authority available through its network: where code can connect, which credentials it can use, and how those permissions change throughout the workload’s lifecycle. These controls are part of the security boundary, not protections to bolt on later.
Compute isolation answers one important question: what can this program access on the machine where it runs? Network isolation answers another: what can it access, or attack, through the network?
Consider an agent that reads a repository and runs generated code. A prompt injection hidden in an issue, log entry, dependency, or source file might instruct it to upload private data. The generated program does not need to escape its microVM. With unrestricted outbound traffic, it can simply send anything it can read to an external server.
The same access can be used to scan internal networks, exfiltrate data and credentials, or call an authenticated API. From the attacker’s perspective, crossing the VM boundary may be unnecessary. Without a network boundary, it is only half a sandbox.
Recent security research has made one pattern clear: untrusted code does not need to cross a VM boundary to escape containment. It only needs one network path that the security model failed to account for.
That path might be a DNS resolver left available in an otherwise disconnected environment, an empty allowlist that fails open, a hostname interpreted differently by a policy engine and a proxy, or a trusted package service turned into a relay. Any one of them can give untrusted code a channel to exfiltrate data, receive instructions, or move toward more sensitive infrastructure.
These are not compute escapes. The kernel, VM, or container boundary may continue working exactly as designed while containment still fails. The practical security boundary also includes DNS, proxies, identity services, internal networks, and every intentionally permitted destination.
Whether we call the result an escape or a bypass, the requirement is the same: a sandbox must account for every path by which untrusted code can communicate.
Completely disconnecting a sandbox closes the network path, but it also makes many workloads impractical. An agent may need to clone a repository, install a dependency, call an AI model, query a database, or upload its result.
Unrestricted internet access is not the only alternative. A useful sandbox should grant only the connectivity a workload requires:
Allow an AI provider, but no other public destination.
Allow one object storage bucket, rather than an entire cloud network.
Reach a private service, while blocking the rest of the private address space.
Install dependencies during trusted setup, then remove registry access before generated code runs.
Authenticate an API request without placing the API key inside the sandbox.
A practical policy model should support fully open access, complete network isolation, and granular policies that deny unmatched traffic by default. Those policies should be able to combine domain rules with allowed and denied address ranges.
Domains and CIDRs solve different problems. Domain policies are precise enough for modern services whose IP addresses change or serve many unrelated hostnames. CIDR policies work across protocols and provide control over fixed infrastructure and private networks.
Connectivity should also be temporary. A workflow can begin with access to a package registry, narrow access before untrusted execution, briefly permit an output destination, and finish with no outbound access, all without restarting the workload.
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. Workloads do not need to configure a proxy, and the firewall retains each connection’s original destination.
For domain-restricted connections, the firewall inspects the beginning of the TLS handshake and extracts the Server Name Indication, or SNI. This identifies the requested hostname before the firewall opens an upstream connection. It checks that hostname against the sandbox’s domain policy and also checks the destination address against its CIDR policy. Ordinary allowed TLS connections pass through without decryption. The firewall reads only the unencrypted handshake information required to enforce the policy, then connects the workload directly to its destination.
Some policies need to inspect or modify the HTTP request itself. For those configured domains only, header injection and request forwarding selectively terminate TLS using a certificate authority unique to the sandbox. The firewall can then match requests by hostname, path, method, query, or headers before injecting a credential or forwarding the request to an endpoint that you trust.
DNS traffic is filtered using the same domain policy. Together, these layers control both where a sandbox can connect and what authority a particular connection receives.
An agent often needs to call an authenticated service, but a credential stored in an environment variable or file is a transferable bearer credential. Every program inside the sandbox can read it. Malicious code can copy it to a third-party service, where it can be retained and used long after the sandbox stops.
Vercel Sandbox instead injects credentials at the host network boundary. The firewall creates a dedicated certificate authority just in time for the sandbox and adds it to the sandbox’s trusted certificates. For a configured destination, it selectively terminates TLS, adds or replaces the authentication header, then establishes a new TLS connection to the upstream service.
The credential never enters the microVM. It never leaves the host unencrypted. The certificate authority is unique to the sandbox and is disposed when the sandbox stops.
Injection also limits where the credential can be used. The firewall sends it only to its configured destination, so up the sandbox’s files or environment to another service does not transfer that authority. Matchers can restrict it further by path, method, query, or request headers. Generated code might receive permission to submit results to one endpoint without receiving permission to read other resources from the same API.
Injected credentials should still follow the principle of least privilege, with access limited to the specific operations the workload requires.
Static allowlists cannot express every security requirement. Some workloads need to inspect payloads, enforce business rules, record an audit trail, or make an authorization decision using context only you have. Request forwarding sends selected HTTPS requests through a proxy that you control. The proxy receives the original request along with a Vercel-issued OIDC token identifying the team, project, and sandbox that originated it.
That proxy becomes a programmable policy layer. It 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 artifacts that fail organizational policy.
Record requests and responses for compliance workflows.
Exchange a sandbox identity for a narrowly scoped credential.
Reject an operation that does not match organizational policy.
The policy and its secrets remain outside the sandbox, even when the code being governed has full root access inside its microVM. You can read more about request proxying in the Sandbox documentation.
We believe a sandbox should not require a payment method before it can safely handle untrusted code.
Every Vercel Sandbox includes both compute isolation and a complete firewall for defining what code inside it can communicate with.
The goal is not to make every sandbox completely offline. It is to make authority explicit:
Which destinations can this sandbox reach?
Which private address ranges are unavailable?
Which requests can use credentials?
Which operations must pass through additional policy?
When should all communication stop?
These are fundamental properties of the execution environment, not security controls to add after a workload reaches production. We believe so strongly in this that we have made our full egress firewall capabilities available to all Sandboxes.
The following policy allows outbound connections to one API and injects a credential only for one operation. Other destinations are denied by default, and the credential remains outside the sandbox.
The same policy can be replaced while the sandbox runs:
A sandbox is not defined only by where its code runs. It is defined by what that code can reach, what authority it receives, and which boundaries still hold when the code itself is hostile.
The network is part of the sandbox.