A sandbox without network boundaries is only half a solution

microVM isolates running code from accessing the host or other workloads, but it does not prevent data exfiltration, internal service discovery, or attacks on external systems. Without controlling network egress, the process may be isolated, but its outcomes remain uncontrolled.

In environments where AI agents read files, execute commands, and generate code, prompt injections can be hidden in issues, logs, dependencies, and source files. Code instructed by malicious prompts can transmit readable data to external servers or attack internal networks and authenticated APIs without escaping the microVM.

Network boundaries include not only simple VM and container isolation but also DNS, proxies, identity services, internal networks, and all allowed destinations. Even in disconnected environments, DNS resolvers, malfunctioning allowlists, hostname resolution discrepancies, and trusted package services can serve as bypass routes.

Since completely blocking the network reduces practicality, sandboxes should selectively allow only the connections necessary for the task.

• Allow only specific AI providers and block other public destinations
• Allow only specific object storage buckets instead of the entire cloud network
• Allow access to only one private service and block the rest of the private address space
• Install dependencies in a trusted setup, then remove registry access before executing generated code
• Do not place API keys in the sandbox; authenticate only API requests

A practical policy model must support full openness, full isolation, and granular selective connectivity, with non-matching traffic denied by default.