Vercel Sandbox Gets a Real Network Boundary: Why Egress Control Is the Missing Half of Agent Security

Vercel shipped an update to Vercel Sandbox this week that is easy to read as an incremental feature and hard to overstate: the sandbox now enforces a network boundary for every workload, on the host, outside the microVM. The post announcing it, "A sandbox without a network boundary is only half a sandbox," is the clearest statement yet of a security model shift that has been building all year.

What changed, concretely#

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

Policy enforcement works like this:

• For domain-restricted connections, the firewall reads the Server Name Indication (SNI) at the start of the TLS handshake, checks the hostname against the sandbox's domain policy, and checks the destination address against its CIDR policy. Ordinary allowed traffic passes through undecrypted.
• DNS queries are filtered with the same domain policy.
• For configured domains only, the firewall can selectively terminate TLS using a certificate authority unique to the sandbox, then match requests by hostname, path, method, query, or headers before injecting a credential or forwarding the request to a trusted endpoint.
• The same policy can be replaced while the sandbox runs. A workflow can start with package-registry access, narrow to deny-all before generated code executes, then reopen one output endpoint, all without restarting the workload.

The standout piece is credential injection at the boundary. Instead of putting an API key in an environment variable, you configure the destination and the firewall creates a just-in-time certificate authority, adds it to the sandbox's trusted certificates, terminates TLS, injects or replaces the authentication header, and establishes a fresh upstream connection. The credential never enters the microVM, never leaves the host unencrypted, and the CA is disposed when the sandbox stops. Uploading the sandbox's files or environment to a third-party service does not transfer that authority, because the credential only exists at the host boundary.

The policy object is small. The entire example from the announcement is a networkPolicy with an allow rule for one hostname and a header transform, plus sandbox.update({ networkPolicy: 'deny-all' }) to lock it down mid-run.

Why this matters to developers building agents#

The framing in the post matters more than the feature list. Isolation without egress control "contains the process, not its consequences." A prompt injection hidden in an issue, log entry, dependency, or source file can instruct generated code to upload private data. The program does not need to escape its microVM to do that. With unrestricted outbound traffic, it just sends whatever it can read to an external server.

This matches the pattern that has dominated agent security reporting all summer: the failure mode is rarely a VM escape, and almost always a network path the security model did not account for. 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. A trusted package service turned into a relay. Every one of those is a containment failure with the compute boundary still intact.

For teams running agents that clone repos, install dependencies, and call model APIs, the practical consequence is that "sandboxed" now means something testable: which destinations can this sandbox reach, which private ranges are unavailable, which requests can use credentials, and when does all communication stop. Those are exactly the questions the containment work we have been tracking says teams should be able to answer.

The credential injection design is the part I would copy even if you are not on Vercel. A bearer token in an environment variable is transferable authority. Any program in the sandbox can read it, and malicious code can copy it somewhere it will outlive the sandbox. Injecting the credential only when a request matches a configured destination, and only at the host boundary, turns the token from a file into a capability with a scoped lifetime. The same idea is why we have argued that agent security needs capability ledgers rather than another prompt hardening pass.

How it fits the rest of the agent stack#

This is the second Vercel agent-security move in a week, after full egress firewall on the Hobby plan and the Sandbox terminal backend for Hermes Agent. Together with Cloudflare's identity-aware AI Gateway and WriteGuard's per-request MCP controls, the direction is consistent: the sandbox is no longer a compute boundary, it is an authority boundary, and the interesting controls live in the network path, not the VM.

For your own setups, the transferable lessons are:

• Assume a prompt injection can turn any tool into an exfiltration channel, and scope network access accordingly.
• Treat credentials as transferable until proven otherwise. Injection at the host boundary is stronger than env-var storage.
• Make policies mutable mid-run. Trust at setup time is not trust at execution time.
• Default to deny, and log what gets blocked.

Continue Reading#

• AI Agent Containment Needs a Capability Ledger
• Agent Sandbox Architecture: How to Choose the Right Runtime Boundary
• AI Coding Agent Firewalls and Security Layers Compared 2026
• Sandboxed Agents Are Becoming the Team Control Plane
• Hermes Agent Gains Vercel AI Gateway and Sandbox Backends

Sources#

• A sandbox without a network boundary is only half a sandbox - Vercel
• Vercel Sandbox firewall documentation
• Full Sandbox egress firewall now available on Hobby plan - Vercel Changelog
• Understanding Vercel Sandboxes