A Sandbox Without Network Control Is Only Half a Sandbox

Vercel has published a detailed breakdown of why compute isolation alone leaves AI agent sandboxes dangerously incomplete. A microVM keeps untrusted code off the host, but without egress control, that code can still send files to an external server, probe internal services, or call authenticated APIs using credentials available inside the environment. The post outlines the network controls built into Vercel Sandbox, including a host-level firewall, TLS SNI inspection, DNS filtering, and mid-workflow permission narrowing, all designed to give every outbound connection an explicit, auditable reason to exist.

What happened

Topic	Detail
Publisher	Vercel
Subject	Network boundary requirements for AI agent sandboxes
Firewall location	Host level, outside the microVM
Inspection method	TLS SNI (Server Name Indication) for domain policies; CIDR ranges for fixed infrastructure
DNS filtering	Filtered using the same domain policy as TCP connections
Credential handling	Injected at the firewall layer; API keys never enter the sandbox

Vercel’s post starts with a simple but important point: a microVM answers the question “what can this code access on the machine where it runs?” It does not answer “what can it reach through the network?” Those are two separate security problems, and most sandbox discussions focus only on the first one.

The practical risk is real. An AI agent reading a code repository might encounter a prompt injection buried in an issue, a log file, or a dependency. That injected instruction could tell the agent to upload private data to an attacker’s server. The generated code does not need to escape the VM to do that. With unrestricted outbound traffic, it just sends what it can read.

Why the network boundary is a distinct problem

Vercel identifies several ways untrusted code can communicate outbound without any compute escape:

• A DNS resolver left reachable in an otherwise disconnected environment
• An allowlist configured to fail open when empty
• A hostname interpreted differently by a policy engine and a downstream proxy
• A trusted package registry turned into a relay for outbound data

Each of these is a network bypass, not a VM escape. The kernel or container boundary can be working perfectly while data still leaves the environment. That means the real security boundary includes DNS resolvers, proxies, identity services, internal networks, and every explicitly permitted destination, not just the VM perimeter.

What does selective connectivity actually look like?

Complete disconnection is not a practical answer. An agent often needs to clone a repository, install packages, call an AI model, or write results to object storage. Vercel’s position is that the right model is “only the connectivity the workload requires,” which can look like:

• Allow one AI provider, block all other public destinations
• Allow one storage bucket, not an entire cloud network
• Allow a private service while blocking the rest of the private address space
• Allow package registry access during setup, then revoke it before untrusted code runs
• Inject an API credential at the firewall so the key never touches the sandbox

Policies can also change mid-workflow without restarting the workload. A job can start with broad registry access, narrow permissions before execution, permit an output destination briefly, and then finish with no outbound access at all.

How Vercel Sandbox enforces this

The Vercel Sandbox firewall sits on the host, outside the microVM, so code running inside cannot modify or disable it. Linux networking redirects all outbound TCP connections and DNS queries through the firewall transparently. Workloads do not need to configure a proxy.

For domain-based policies, the firewall reads the TLS handshake’s SNI field (the unencrypted part that identifies which hostname the client wants) before opening an upstream connection. It checks that hostname against the domain policy and the destination IP against the CIDR policy. Allowed connections pass through without decryption.

For policies that need to inspect or modify the request itself, such as injecting an authorization header, the firewall selectively terminates TLS using a certificate authority unique to each sandbox. It can then match on hostname, path, method, query parameters, or headers before forwarding to a trusted endpoint. DNS traffic runs through the same domain policy layer, so both resolution and connection are filtered consistently.

This kind of layered thinking is directly relevant to any team building AI-powered workflows. If you are integrating AI agents into business processes, the question of what those agents can reach outbound is as important as what model you choose. A misconfigured or absent egress policy is the kind of gap that rarely shows up in demos but matters a great deal in production.

Our take

Vercel is doing something useful here: making an unglamorous security concept concrete. Most teams shipping AI agents are focused on prompt quality and tool reliability, not on whether the sandbox their code runs in has a permissive DNS resolver. That is understandable, and it is also exactly the gap that gets exploited.

The framing “isolation without egress control contains the process, not its consequences” is the clearest way we have seen this problem stated. It should be on the checklist for anyone evaluating agent infrastructure, whether they use Vercel Sandbox or something else entirely.

The credential injection pattern is particularly worth noting. If the API key never enters the sandbox, a compromised workload cannot exfiltrate it. That is a structural improvement over the common approach of passing secrets as environment variables inside the execution environment. For teams building production agents that touch sensitive APIs, this is worth asking about explicitly when evaluating any application infrastructure.

The broader lesson is that security for AI agents is not a single checkbox. Compute isolation, network egress control, DNS filtering, and credential handling are separate layers, each of which can fail independently. Coverage of how attackers are probing these gaps is growing, as seen in recent AI security research from Black Hat USA 2026. Teams should audit each layer on its own merits.

What to do about it

1. Audit your current agent infrastructure: does it restrict outbound connections, or is all traffic permitted by default?
2. Map every external service your agents actually need to reach and build an explicit allowlist from that map.
3. Check whether DNS is filtered separately from TCP connections. A TCP block that leaves DNS open is not a complete control.
4. Move credentials out of the execution environment. Use header injection or a secrets proxy rather than environment variables inside the sandbox.
5. Plan for permission narrowing mid-workflow: setup access and execution access should not be the same permission set.

If your agents touch production data or external APIs, the network boundary deserves the same attention as the model selection.

Source: Vercel Blog