Agent Package Installation and Kernel-Level Customization in Micro-VMs

Firecracker micro-VM isolation for AI agents gives each agent its own Linux kernel through KVM hardware virtualization, while containers share the host kernel. With that boundary in place, untrusted agents can install packages with root-level access and customize their systems. The full deployment model also requires layered security, external network controls, and snapshot-restore so each agent’s customized environment can remain isolated, persistent, and affordable.

Why shared-kernel environments are structurally inadequate for agents that install and customize freely

An agent that runs commands, installs packages, and manipulates files executes code the host should treat as untrusted. A language model is a probabilistic text generator whose output carries no authority to control the machine beneath it. Prompt-injected input makes that distinction especially important because outside content can influence the commands an agent generates. The isolation boundary must therefore contain actions the application never intended, as well as keep apart workloads that are expected to cooperate.

Standard containers built on Docker and runc separate processes through Linux namespaces and cgroups, but every tenant still shares the host OS kernel. Red Hat’s advisory describes CVE-2019-5736 as a runc flaw that permits root-level access to the host machine. Snyk’s disclosure describes CVE-2024-21626 as a runc container breakout to the underlying host OS. These failures illustrate the structural concern rather than establish that every container is insecure. Containers can support ordinary package installation, but they cannot give an agent unrestricted control of its own kernel because that kernel also belongs to the host.

How to give each AI agent its own isolated kernel with Firecracker

Firecracker runs in user space on Linux KVM, which uses Intel VT-x / AMD-V hardware virtualization extensions to separate guest execution from the host. Each micro-VM boots its own Linux kernel instead of adding another process boundary around the host kernel. Full VMs such as EC2 and VMware also provide kernel isolation, but their tens-of-seconds boot times and hundreds of MB of overhead make per-agent deployment costly. Firecracker boots in approximately 125 milliseconds with approximately 5 MB of memory overhead. This changes the practical unit of isolation from a shared machine to an individual agent.

Each micro-VM is a Firecracker process with an API server thread, a thread for each vCPU, and a VMM thread handling device emulation and the event loop. Firecracker supports only six emulated device types, reducing the device surface compared with QEMU’s hundreds. Its jailer companion confines the VMM itself and drops privileges before execution. Another option, gVisor, intercepts syscalls through a user-space kernel and offers easier integration with container orchestration platforms with different compatibility trade-offs. Hardware virtualization provides the decisive distinction for full kernel ownership.

What an agent can do inside its own kernel that it cannot do in a shared-kernel environment

Inside its guest, an agent can use apt or yum to install system packages and pip to build compiled extensions. System libraries and native binaries become ordinary parts of its environment rather than dependencies that must all be approved in advance. Kernel ownership also permits deeper changes, including modifying parameters through sysctl, loading kernel modules, and configuring guest network interfaces. These operations act on the guest’s kernel and system state. They do not grant equivalent authority over the host.

Browser sessions can use a full Linux environment with a display stack, audio/video device support, and the privileges needed for browser sandboxing. Network tools and debuggers can use guest kernel interfaces without acquiring control over neighboring workloads. In deployments such as Maritime’s persistent per-agent micro-VMs, a broken package install, corrupted dependency, or destructive command is contained within the affected agent’s sandbox by design. The useful capability is therefore not merely permission to install software, but permission to alter and rebuild an entire working environment without making that environment shared infrastructure.

The four-layer security model that makes unrestricted agent root access safe for multi-tenant deployments

Root inside a guest remains powerful, so the security case depends on independent layers. The first layer is KVM hardware virtualization, which prevents guest code from directly accessing host memory, devices, or kernel interfaces under normal operation. The second is per-thread seccomp filtering around Firecracker. The API thread gets the calls it needs for network I/O, while vCPU threads get the calls they need for KVM operations. Blocking unnecessary syscalls narrows what a compromised VMM thread could do.

The third layer consists of cgroups and namespaces, which constrain resources and isolate process and network views. CPU placement and quotas bound execution, while memory cgroups cap usage. The fourth layer is jailer privilege dropping, which establishes a chroot filesystem jail and other restrictions before executing Firecracker without root privileges. These controls protect different boundaries and keep guest root separate from host root, although micro-VM escapes remain possible and exploit paths through the layers can vary. The defensible claim is layered risk reduction, with both the workload sandbox and hypervisor standing between untrusted agent code and the host.

Memory hotplugging and CPU management: matching resource allocation to how agents actually behave

Containment must also work when the resources an agent needs change sharply during a session. An agent may need little memory for a simple query and multiples of that working set when parsing a large document. Memory hotplugging allows a running Firecracker micro-VM to expand without downtime, within a ceiling configured before boot. The ceiling still requires planning because it cannot be deferred until the workload has already exceeded it.

CPU allocation follows a different rule. The vCPU count is fixed before boot, so changing it requires a new micro-VM. Fleet orchestration must account for that constraint when assigning work. CPU pinning through cpuset cgroups reduces the cache and NUMA penalties associated with migration between physical cores, helping make latency more predictable. Memory oversubscription needs separate care because Firecracker allocates used pages, allowing configured maxima to exceed the host’s physical capacity. If too many agents need their maximum at once, the Linux OOM killer can stop VMs, so operators must allow for peak demand when they set oversubscription ratios.

Snapshot-restore as the mechanism that makes the full package-install lifecycle economically viable at scale

Even when agents use resources efficiently as they run, waiting costs more. Agents often use CPU for seconds during a tool call, then remain idle while the model reasons. Keeping every customized environment continuously running makes the bill reflect inactivity as much as useful work. Snapshot-restore changes that relationship by capturing the VM’s kernel, memory, disk state, installed packages, and open file handles. A dormant environment can then occupy storage rather than idle compute and restore in under a second.

An agent installs its dependency stack once, snapshots the configured environment, and resumes from that state on later wakes. Its system customization lasts through the pause, with no need to run a startup script again. This is the economic basis of Maritime’s snapshot-and-restore scheduling and pricing model, which substitutes storage cost for idle compute. Dedicated kernels become an affordable deployment unit only when their idle lifecycle is managed as deliberately as their active one.

Networking inside micro-VMs: the operational complexity that kills most self-managed deployments

Firecracker does not provide a plug-and-play equivalent to Docker’s bridge networking. Each micro-VM communicates through a TAP device, and the host must create the interface, assign an IP, configure routing, and maintain iptables rules. Those tasks recur across the fleet rather than ending when the first VM boots successfully. Mistakes in that setup can break an agent’s connections or open paths that isolation was meant to close.

Outbound policy matters especially because an agent that can connect anywhere can exfiltrate data or contact attacker-controlled infrastructure. Enforcement belongs outside the guest because guest root can alter its own iptables rules. A per-sandbox gateway can apply that policy, while an external credential store can inject credentials at the network layer or through a browser agent, keeping secrets outside the guest. Firecracker also exposes granular network and storage rate limits through its API, but operators must configure them for each VM. Managed infrastructure has genuine value here because it takes responsibility for starting Firecracker processes and managing routing, policy, and per-VM configuration.

What kernel-level customization looks like in practice: the package-install and environment-setup lifecycle

The lifecycle begins when an agent or setup script installs the environment’s dependencies inside a fresh guest. It runs apt, yum, or pip to place system libraries, native binaries, and compiled extensions where the tools expect them. It then configures kernel-facing tools, including network sniffers, debuggers using ptrace, and utilities that change sysctl parameters. Having its own kernel keeps those changes on the agent’s machine.

Browser automation adds its own preparation through tools such as Playwright, Puppeteer, and headless Chrome. The environment supplies the display server, device nodes, and browser sandbox support that the session requires. Once configuration is complete, a snapshot preserves packages, environment variables, open file handles, and kernel state for subsequent restores. A later conflicting library install or damaged configuration affects only that agent’s environment. AWS Lambda MicroVMs describes the same design goal through isolated kernel, memory, and disk state, preserved dependencies, and platform-managed routing. The workflow is therefore installation, customization, preservation, and reuse, with the isolation boundary intact throughout.

How MCP integration changes the surface area agents need to customize

MCP standardizes how agents call tools, access resources, and invoke services, but it does not remove the tools’ installation requirements. A browser automation tool still needs a browser binary, a database tool needs a client library, and a compiler tool needs a toolchain. Many of these tools run as local processes or system services. As the tool set grows, the execution environment must accommodate more than a fixed collection of application dependencies.

A stateless tool request can still need packages, configuration, and files set up during an earlier interaction. Snapshot-restore preserves that preparation so a request can reach a configured environment without repeating installation. With per-agent micro-VMs, each tenant also has its own toolchain versions, binary paths, and system service configuration. Shared-kernel environments can isolate many ordinary dependency differences, but they do not provide independent kernels when a tool requires system-level changes.

Why per-user agent deployment is the right primitive and what it requires from the infrastructure layer

A per-user agent needs more than an isolated command runner. It needs a durable machine whose installed tools and file state can evolve with that user’s work. OpenAI dots, Manus’s Cue, and Simular Sai reflect this model by giving each agent its own machine. Making that model practical requires the properties developed here, namely kernel isolation, contained root access, persistent customization, and low idle cost. Sub-second restore is also a product requirement because a machine that takes tens of seconds to return interrupts the interaction it exists to support.

Maritime deploys each AI agent in its own persistent Firecracker micro-VM on bare metal, with package installation privileges, browser sessions, and snapshot-restore wake latency under a second. Its persistent disk and flat-rate model apply the architecture to per-user deployment rather than treating each interaction as a fresh execution job. Operators can also run Self-managed Firecracker, but they then have to handle resource scheduling, snapshots, and the external network boundary. The builder’s choice is consequently not just where an agent runs, but which actions its infrastructure can safely permit. Per-user micro-VMs with managed persistence and snapshot economics make the full customization lifecycle a practical default instead of a privilege that shared infrastructure must withhold.