A microVM stops untrusted code from touching the host. It does nothing to stop that same code from exfiltrating data through an open network connection.
Vercel’s argument is direct: isolation without egress control contains the process, not its consequences. As AI agents gain the ability to read files, execute commands, install packages, and generate programs, the gap between “sandboxed” and “safe” widens.
What a microVM alone cannot prevent:
- Data exfiltration — outbound connections stay open, credentials and files can leave
- Internal service probing — anything reachable from the sandbox network is a target
- Credential abuse — tokens and secrets inside the environment are usable
- Lateral attacks — systems elsewhere on the internet can be probed
A complete sandbox needs three network controls that most setups skip:
| Control | What it restricts |
|---|---|
| Egress filtering | Where code can connect |
| Credential scoping | Which tokens the code can use |
| Lifecycle permissions | How permissions change during execution |
These are part of the security boundary, not protections to bolt on later.
NOTE
Windows Sandbox ships with networking enabled by default. Microsoft’s own docs warn this “can expose untrusted applications to the internal network.” Disabling it requires a custom .wsb launch file.
The stakes are higher now. An AI agent that can install packages and execute commands inside a microVM is one curl away from sending environment variables to an external endpoint — and the microVM won’t stop it.
If your sandbox config has no explicit egress policy, you’re running half a sandbox.