{"slug": "a-sandbox-without-a-network-boundary-is-only-half-a-sandbox", "title": "A sandbox without a network boundary is only half a sandbox", "summary": "A sandbox that isolates compute but not network egress is only half a sandbox, according to a security analysis of AI agents running untrusted code. The analysis argues that unrestricted outbound traffic lets generated code exfiltrate data or attack internal services without crossing the VM boundary, and recommends granular network policies that deny unmatched traffic by default.", "body_md": "Running untrusted code safely requires more than separating it from the host. You also have to control what that code can reach.\n\nThis 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.\n\nIsolation without egress control contains the process, not its consequences.\n\nA 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.\n\nCompute 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?\n\nConsider 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.\n\nThe 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.\n\nRecent 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.\n\nThat 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.\n\nThese 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.\n\nWhether 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.\n\nCompletely 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.\n\nUnrestricted internet access is not the only alternative. A useful sandbox should grant only the connectivity a workload requires:\n\nAllow an AI provider, but no other public destination.\n\nAllow one object storage bucket, rather than an entire cloud network.\n\nReach a private service, while blocking the rest of the private address space.\n\nInstall dependencies during trusted setup, then remove registry access before generated code runs.\n\nAuthenticate an API request without placing the API key inside the sandbox.\n\nA 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.\n\nDomains 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.\n\nConnectivity 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.\n\nThe Vercel Sandbox firewall runs on the host, outside the microVM, where code inside the sandbox cannot modify or disable it.\n\nLinux 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.\n\nFor 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.\n\nOrdinary 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.\n\nSome 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.\n\nDNS 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.\n\nAn 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.\n\nVercel 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.\n\nThe 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.\n\nInjection also limits where the credential can be used. The firewall sends it only to its configured destination, so uploading 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.\n\nInjected credentials should still follow the principle of least privilege, with access limited to the specific operations the workload requires.\n\nStatic 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.\n\nRequest 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.\n\nThat proxy becomes a programmable policy layer. It can:\n\nRedact sensitive fields before a request leaves the environment.\n\nEnforce per-user or per-sandbox authorization.\n\nRoute package downloads through supply-chain scanning and block artifacts that fail organizational policy.\n\nRecord requests and responses for compliance workflows.\n\nExchange a sandbox identity for a narrowly scoped credential.\n\nReject an operation that does not match organizational policy.\n\nThe 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](https://vercel.com/docs/sandbox/concepts/firewall#requests-proxying).\n\nWe believe a sandbox should not require a payment method before it can safely handle untrusted code.\n\nEvery Vercel Sandbox includes both compute isolation and a complete firewall for defining what code inside it can communicate with.\n\nThe goal is not to make every sandbox completely offline. It is to make authority explicit:\n\nWhich destinations can this sandbox reach?\n\nWhich private address ranges are unavailable?\n\nWhich requests can use credentials?\n\nWhich operations must pass through additional policy?\n\nWhen should all communication stop?\n\nThese 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](https://vercel.com/changelog/full-sandbox-egress-firewall-now-available-on-hobby-plan).\n\nThe 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.\n\nThe same policy can be replaced while the sandbox runs:\n\nA 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.\n\nThe network is part of the sandbox.", "url": "https://wpnews.pro/news/a-sandbox-without-a-network-boundary-is-only-half-a-sandbox", "canonical_source": "https://vercel.com/blog/a-sandbox-without-a-network-boundary-is-only-half-a-sandbox", "published_at": "2026-08-10 21:15:44.887207+00:00", "updated_at": "2026-08-10 21:15:46.707558+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-infrastructure"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/a-sandbox-without-a-network-boundary-is-only-half-a-sandbox", "markdown": "https://wpnews.pro/news/a-sandbox-without-a-network-boundary-is-only-half-a-sandbox.md", "text": "https://wpnews.pro/news/a-sandbox-without-a-network-boundary-is-only-half-a-sandbox.txt", "jsonld": "https://wpnews.pro/news/a-sandbox-without-a-network-boundary-is-only-half-a-sandbox.jsonld"}}