Networking Architecture for Isolated Agent VMs

A Firecracker micro-VM solves the problem of two untrusted workloads sharing a kernel. It does not solve the problem of what either workload can reach once it starts talking to the network. Intel VT-x and AMD-V enforce the VM boundary at the CPU level: a container escape hands an attacker root on the host, while escaping a micro-VM requires a hypervisor CVE, a vulnerability class that is rare and expensive to find. That boundary matters, and it stops lateral movement between tenants at the kernel level. But a micro-VM with an open network interface can still send data to an outside server, call an API the agent was never authorized to use, or hand its output to an attacker-controlled endpoint. The VM wall stops things from getting in. It does nothing to stop things from getting out. Platforms like Maritime isolate each agent inside its own Firecracker micro-VM with a dedicated kernel, so lateral movement is closed off at the CPU level, but that compute boundary only governs what crosses into the VM. What the agent can send out has to be handled as a separate layer, built with its own design and its own set of rules.

The four networking primitives every isolated agent VM must account for

Agent VM networking breaks down into four pieces, and each one covers a different kind of traffic, with its own failure mode if you skip it.

TAP interfaces and the host bridge are the standard way a Firecracker micro-VM gets wired into the host network: a TAP device on the host side connects to a virtual network card inside the guest, and this pairing is the only entry and exit point for guest traffic. It's also the first and most natural place to put policy, since every packet the guest sends or receives has to pass through it.

vsock, short for virtual sockets, is a channel between host and guest that skips the IP stack. Traffic over vsock never leaves the host machine, so it's the right tool for control-plane communication between an agent and its orchestrator. No other tenant can intercept it or reroute it, because it was never put on a network.

An egress proxy sits on the host and handles outbound HTTP and HTTPS traffic on the guest's behalf: it checks each destination against an allowlist and attaches credentials before the request goes out. The guest never holds a long-lived credential, and it never opens a socket straight to the internet.

Overlay networking covers the case where agents need to talk to each other, for distributed testing or multi-agent coordination. A private network between VMs, running under default-deny rules, lets that traffic move without exposing either VM to the open internet. Docker Sandboxes build this with a private Docker daemon inside each VM, isolated at the VM boundary, so any container an agent spins up inside its own sandbox stays contained there too.

Each of these primitives, TAP interfaces, vsock, egress proxies, overlay networks, isolates a different threat surface. None of them is optional if the goal is a networking layer that matches the strength of the compute isolation underneath it.

vsock and host-side proxying keep the guest off the open internet

The most defensible networking design for an isolated agent VM gives the guest no external network interface. Instead of a TAP device wired to the public internet, the guest's only way of reaching the outside world is vsock, talking to a proxy process that lives on the host. That proxy accepts the vsock connection, checks the requested destination against an allowlist, attaches the right service credentials, and forwards the request onward. The guest never sees a credential, and it never opens a socket of its own. This is the pattern Claude's secure-deployment documentation lays out directly: the agent VM communicates through vsock, and all traffic routes through a proxy on the host before it ever leaves the machine.

The effect on an attack is concrete. If a prompt injection or a compromised dependency manages to take over what the agent outputs, the blast radius is still bounded by whatever the host proxy allows. An attempt to send data to an arbitrary endpoint gets blocked before the packet leaves the host, because the guest was never in a position to make that connection on its own.

Production systems built on this idea vary mostly in how the policy gets expressed. AWS Lambda MicroVMs give each VM a dedicated HTTPS endpoint for inbound traffic, with outbound access configurable for either the public internet or a VPC, and authentication handled through service-issued JWE tokens; the policy lives at the infrastructure layer, not inside the agent's code. Google's Agent Gateway for Gemini Enterprise takes this further with a managed governance plane that sits between agents, running in Agent Runtime or Gemini Enterprise, and any external tool they try to call. Egress is bound to the project's Agent Registry and routed through a customer-owned Private Service Connect interface to reach private MCP servers inside a VPC, so the agent never has a direct path to anything external. The canonical version of this architecture removes the guest's network interface outright and puts every outbound request through a host-side proxy over vsock, which is what makes it possible for persistent agent infrastructure, including Maritime's, to run agents indefinitely without a path for lateral breakout through the network.

Egress policy belongs on the host, not inside the guest

Egress control placed inside the guest VM can be defeated by the very agent it's meant to constrain. A system prompt telling the model not to call certain endpoints, an in-guest firewall rule, or an SDK that claims to "only call approved endpoints" is a convention, and model-generated code can break conventions without even trying to. Docker Sandboxes' architecture documentation makes the point directly: "An LLM deciding its own security boundaries is not a security model. The bounding box has to come from infrastructure, not from a system prompt."

What follows from that is a sequencing rule: file access, network policy, and secrets all need to be defined before the agent ever starts running, so the agent operates inside a boundary set in advance, with the agent only ever reporting on a boundary already fixed. eBPF enforces this correctly when it's applied at the host level, because kernel-level egress filtering running outside the VM sits in a context the guest cannot reach or modify. The CreateOS sandbox pattern pairs this with Firecracker VM isolation, combining host-enforced egress control, kernel iptables plus a transparent proxy, with the VM boundary itself, so two independent layers enforce policy and neither one is something the guest controls.

The usual objection is that host-side enforcement adds latency and a new piece of infrastructure to operate. The latency cost of a proxy hop is small next to the time an LLM spends on inference, and the operational dependency is not a drawback so much as the reason the architecture works: centralizing policy on the host means it can be audited, versioned, and changed without touching a single guest image.

The suspend-resume lifecycle's effect on network state and connection persistence

Snapshot-and-restore scheduling is what makes per-agent VM economics work, because an idle agent that's suspended to disk costs only storage, not compute. But that same mechanism creates networking problems that simply don't exist in an always-on deployment. When a micro-VM suspends, any TCP connection in flight, any open WebSocket, any long-poll subscription, freezes in place. On resume, the guest's network state may no longer match what the external peer on the other end expects.

For agent products built around real-time streaming, live tool calls or streaming token output, something has to stay awake on the host side to hold the connection while the agent behind it is suspended. That's a genuine unsolved tension in the current generation of suspend-resume systems, not a detail any platform has fully closed. AWS Lambda MicroVMs handles the inbound half of the problem by giving each VM a dedicated HTTPS endpoint tied to its session: if a request arrives while the VM is suspended, Lambda holds that request, resumes the VM, and delivers it once the VM is ready, adding resume latency to the first response. The application still has to manage session routing, endpoint tracking, and cleanup on its own.

The pattern that holds up in practice inverts where the responsibility sits. The orchestrator or dispatcher holds the external connection on the host side, cheaply, and only resumes the VM once there's actual work to hand it. The guest is never asked to maintain a persistent connection it has no reliable way of holding across a sleep cycle. The same inversion applies to long-poll patterns, where an agent blocks on a queue or a streaming API: the host-side dispatcher does the long-polling, and the guest wakes only once there's something for it to process. The copy-on-write memory behavior of snapshot restore preserves network configuration exactly as it was at snapshot time, so IP address reassignment, connection teardown signaling, and any external service that treats the agent's IP as a session identifier all need deliberate handling on resume.

Multi-tenant fleet networking: per-agent isolation without per-agent operational overhead

A per-agent VM model only pays off at product scale if the networking layer is built for a fleet from the start, not bolted together one VM at a time. Every agent VM needs its own isolated network namespace, a TAP interface provisioned the moment it launches, routes configured before the guest even starts, and teardown logic that reclaims addresses cleanly when the agent is gone. Doing all of that by hand, agent by agent, is exactly the operational burden that makes a homebrew Firecracker stack expensive to run. The savings promised by snapshot-restore scheduling, where an idle agent costs only its storage, only materialize if the networking setup cost on each resume stays negligible; a slow TAP setup undoes the latency gain the whole model is built on.

Two production systems show this problem solved at different layers of abstraction. AWS Lambda MicroVMs absorbs TAP interface management and CNI plugin orchestration as managed-platform work: a team calls run-microvm and gets back a dedicated HTTPS endpoint, with no networking configuration left to manage by hand, and the operational cost sits fixed at the platform layer instead of multiplying per agent. Maritime applies the same principle down at the hardware level. Each agent on Maritime runs inside its own Firecracker micro-VM on dedicated hardware, with persistent disk and the ability to wake from a snapshot in under a second, and because networking and lifecycle management are handled by the platform itself, developers pay for storage during idle time rather than for a warm pool of pre-provisioned network interfaces sitting around unused.

Whether each agent keeps a stable IP address matters for any external service that allowlists by IP. A dedicated endpoint URL, which both Lambda MicroVMs and Maritime provide, holds up better than a raw IP address that might shift across a suspend and resume cycle.

Where the networking architecture breaks down

Three failure modes appear repeatedly in agent VM networking, and none of them are hypothetical. Each has a known fix, and each fix comes with a cost of its own. Scale-to-zero scheduling runs straight into connection persistence: suspending an idle agent saves compute cost, but it requires the host to hold connections the guest has no way of holding itself, and the fix, host-side dispatching, keeps the dispatcher layer always-on, which moves the idle cost elsewhere. Egress allowlists run into a similar wall at fleet scale: a single static domain allowlist enforced by the host proxy works fine for one agent type, but it turns into a versioning headache once a fleet contains agents with genuinely different roles and different legitimate destinations, and the fix, per-role policy applied at image build time, adds its own layer of image management. GPU-heavy and high-throughput networking workloads expose a third limit: the vsock-and-proxy hop costs almost nothing for an LLM tool call but becomes real overhead for workloads moving data at high packet rates or straight from GPU to network. Firecracker doesn't currently support VFIO device passthrough for direct GPU access, and any workaround that bypasses that restriction also bypasses some of the isolation the whole model depends on, leaving teams running GPU-intensive agents to weigh performance against isolation depth directly.

Research is starting to chip away at the latency side of this problem. SpecBox (arXiv:2607.23933, July 2026) overlaps VM preparation with LLM execution using intent-aware sandbox prewarming and stochastic sandbox prefetching, and reports a significant cut to cold-path latency. But scheduling optimizations like this run on a separate track from the policy questions this piece has laid out: what the guest can reach, how credentials move, what survives suspension, who holds the external connection. None of those get answered by a faster cold start. The micro-VM boundary stops lateral movement at the kernel level, and that's the floor underneath an isolated agent system, not the whole structure. Whether the isolation guarantee actually holds once that system is live depends on the networking architecture built on top of it, and that architecture has to be designed on purpose. It has to be a deliberate choice, not a consequence of the decision to use a micro-VM.