The agent is the computer

For most of the last decade, infrastructure teams have had two basic choices. Containers are small, fast, and dense. Virtual machines provide stronger isolation, but they are heavier and more expensive to operate. A lot of infrastructure architecture since 2014 has been some negotiation between those two facts.

MicroVMs give us another option. They use hardware virtualization like a traditional VM, but remove much of what made VMs heavy in the first place. That was already an interesting engineering result when Firecracker appeared. AI agents make the model much more relevant because agents need something that looks less like a container, and more like a computer.

The important distinction is between the model and the agent. An agent is not simply an LLM running inference. The model reasons. The agent acts on that reasoning. It runs commands, reads and writes files, calls APIs, queries databases, browses networks, invokes MCP servers, and uses whatever tools it has been given. LangChain describes the basic pattern as a model calling tools in a loop until the work is complete. CrewAI builds on essentially the same idea with agents, tools, workflows, and coordination.

Once you look at an agent that way, the infrastructure problem becomes clearer. We are not just finding somewhere to run an application. We are giving software a computer and allowing a model to decide what that computer does next.

Containers solved density, not isolation

Containers were one of the most important infrastructure changes of the last twenty years. They gave us standard packaging, fast startup, high density, reproducibility, and an ecosystem that made software dramatically easier to ship. Members of our team spent years at Red Hat helping customers move in that direction, and we would not undo any of it.

But containers were built around a tradeoff. Processes are isolated, while the Linux kernel underneath them is shared. Namespaces, cgroups, capabilities, seccomp, SELinux, and other controls make that boundary much stronger than it used to be, but the host kernel is still shared common infrastructure.

For normal applications, that tradeoff is often exactly right. You wrote the software, reviewed it, packaged it, and decided what it would do before it was deployed.

Agents are different.

Consider an agent troubleshooting a server. It may read logs, inspect configuration, run shell commands, call an internal API, query a database, write a script, execute that script, download a dependency, and connect to another system based on what it discovers. You cannot fully predict that sequence when the process starts because choosing what to do next is the job of the model.

That does not mean the model is malicious. It means the execution environment has to account for mistakes, prompt injection, malicious tool output, vulnerable dependencies, and actions nobody anticipated when the agent was launched. Once software is making decisions and creating side effects, the environment around it should be treated as untrusted.

Traditional VMs solve the boundary, but bring the server with them

A traditional VM gives a workload its own kernel behind a hardware virtualization boundary. That is a fundamentally different isolation primitive from multiple workloads sharing one kernel.

The problem is that the VM abstraction accumulated a lot of machinery because we spent decades using VMs to recreate physical servers. Virtual firmware, virtual hardware, bootloaders, full operating systems, systemd, SSH, package managers, guest agents, large disk images, background services, and long-lived machine state all became part of the normal operating model.

Very little of that bulk is actually required to get the isolation benefits of hardware virtualization.

An agent does not need a virtual server. It needs an isolated place to execute code for a period of time, then disappear.

That is the interesting part of microVMs.

Keeping it light

The basic idea is to keep the hardware virtualization boundary and remove as much of the traditional VM as possible. Firecracker demonstrated that approach at scale with a minimal device model on KVM and a VMM written in Rust, with components shared through the broader rust-vmm ecosystem.

Our work in Starlight centers on libkrun, which we use for lightweight virtualization and confidential-compute workloads. The appeal of libkrun is that it treats virtualization less like a separate infrastructure stack and more like a capability an application can use directly.

On Linux, libkrun runs on KVM and exposes only the virtual hardware the workload actually needs. It also supports AMD SEV and Intel TDX variants, which fits naturally with the confidential-compute work already in Starlight.

The important part is that the microVM is a compute primitive, not a lifecycle decision. A Starlight environment might exist for a single task, remain available across many agent sessions, or become a long-lived workspace with its own filesystem, tools, and state. The same isolation model works in each case.

That is very different from treating every VM as a traditional server that has to be provisioned, configured, patched, and administered as a permanent machine. With Starlight, the environment can live as long as the workload requires, while remaining lightweight, isolated, and controlled.

The model does not have to live inside the agent

One misconception that comes up often is that AI agents need GPUs. Usually they do not. The model may need a GPU. The agent execution environment generally does not.

Most of what an agent actually does is ordinary computing. It launches processes, parses JSON, reads files, runs Python, manipulates source code, calls APIs, queries databases, and talks to other systems. That needs CPU, memory, storage, and networking. The expensive matrix multiplication is happening somewhere else.

That means the model and the agent can be separated cleanly. The model may run against a cloud API, a vLLM cluster, an inference server in the same rack, or a confidential-compute endpoint. The model makes decisions and the agent execution environment carries them out.

That separation is useful for security because the inference credential does not need to exist inside the agent sandbox. It is also useful architecturally because the model can move without changing the execution environment.

More importantly, once inference and execution are separated, we can ask a question that a lot of agent architectures skip entirely: why should the model be somewhere else at all?

Run the model on your own platform

When practical, the model should run on the same platform as the agent. Starlight already supports this today.

Models are deployed as OCI workloads and exposed through OpenAI-compatible endpoints backed by vLLM or llama.cpp. They become versioned artifacts that can be pulled, signed, scanned, deployed, and rolled back using the same operational model as other Starlight workloads. Inference runs directly against the GPU without adding unnecessary virtualization in front of the accelerator.

Local inference also changes the economics of agents. Agents operate in loops, repeatedly reasoning, calling tools, processing results, and reasoning again. Across many users and automations, per-token pricing can quickly become a significant operating cost. Local inference turns that into capacity planning around infrastructure you control.

Control and data sovereignty matter even more. Remote inference introduces dependencies on connectivity, rate limits, provider uptime, and model availability. It also means logs, source code, configuration, database results, internal documents, and other tool output may repeatedly leave the organization as the agent works.

Running the model locally keeps that data inside the Starlight environment and allows operators to maintain a specific model version for as long as required. For disconnected, regulated, air-gapped, tactical, healthcare, industrial, and other sensitive environments, that can be a requirement rather than a preference.

An agent that needs the internet to think is fundamentally limited at the edge.

The LLM is the brain. The agent is the computer.

This is the framing we keep coming back to.

The model reasons and makes decisions. The agent turns those decisions into actions.

An LLM that outputs rm -rf /some/path has produced text. An agent with permission to execute that command has changed a system.

Much of the security discussion around AI focuses on model endpoints, prompt protection, output filtering, and model behavior. Those controls matter. But once a model can call tools, execute code, access files, query systems, or modify infrastructure, the execution environment becomes just as important as the model itself.

Agents are not just prompts wrapped around an LLM. They are computers acting on behalf of an LLM.

That means agent execution needs its own secure compute primitive.

Why Rust belongs here

A VMM sits on a sensitive boundary between guest-controlled input and the host. Historically, this type of systems software has involved a lot of manually managed memory, and memory-safety problems have produced some ugly security bugs over the years.

Rust helps reduce that particular class of risk. Its ownership and type systems catch many memory-safety problems at compile time while still giving developers the low-level control required for virtualization, networking, and operating-system work.

Rust does not make code secure by itself. Logic errors, unsafe code, bad protocols, kernel bugs, and bad architecture can all still cause problems. But memory safety is especially valuable in code that sits directly on a security boundary.

That is one of the reasons Rust appears throughout modern virtualization projects, and it is why we are using it heavily in the Starlight agent execution control plane. The trusted portion of this system should be as small, understandable, and memory safe as we can make it.

Containers, microVMs, and traditional VMs

This is not an argument that microVMs should replace containers. Containers remain a very good packaging format, and that is part of what makes this architecture practical.

OCI can remain the way software is built, distributed, scanned, signed, and stored. The microVM becomes the execution boundary when that software should not share the host kernel.

That distinction is much more useful than treating containers and VMs as competing ways to package software.

e0: one agent session, one disposable computer

This is what we are building with e0, the execution environment for Starlight agents.

e0 treats a microVM as a disposable computer created for a single agent session.

Agent framework (LangChain, CrewAI, your own)
                 |
                 v
     e0d, Rust control plane  <----->  inference container
                 |                     vLLM or llama.cpp
                 v                     OCI packaged, on GPU
              libkrun
                 |
                 v
              microVM
   tools, filesystem, processes, workspace

Both sides run on the same platform. The model sits in a container on the GPU. The agent runs inside a microVM using a small amount of CPU and memory. e0d sits between them as the trusted control plane.

The framework should not be the security boundary. LangChain should stay LangChain. CrewAI should stay CrewAI. A customer's own framework should not have to be rewritten around a new security model.

The framework handles orchestration. e0 handles execution.

That separation also gives us some insulation from how quickly the agent ecosystem is changing. New frameworks are going to appear, and current ones are going to evolve. We do not want infrastructure isolation to be reinvented every time that happens.

The basic unit in e0 is intentionally boring: one agent session, one microVM.

The session begins, Starlight creates an execution environment, the agent does its work, and the environment is destroyed when the session ends. The host remains authoritative over lifecycle, policy, and auditing throughout the session.

That makes normal infrastructure controls useful again. CPU limits, memory limits, process limits, execution deadlines, filesystem quotas, workspace boundaries, network policy, destination allowlists, tool budgets, auditing, and forced termination can all be enforced outside the agent.

That last part matters. An agent cannot be responsible for deciding whether it has exceeded its own permissions. The enforcement point has to sit outside the thing being controlled.

Default deny becomes practical

Networking is a good example. Many agent runtimes assume that because the agent needs to make HTTP requests, it should have general network access. We think that is the wrong default.

A coding agent might need GitHub, an internal registry, and one internal API. It probably does not need arbitrary access to everything routable from the host. An agent working with sensitive internal documents may need no network access at all.

The environment should start from deny and add access deliberately. The same principle applies to filesystems, processes, credentials, devices, and tools.

Separating inference from execution also helps with credentials. The token used to reach the model does not need to exist inside the agent microVM. The sandbox sends execution results to a trusted host-side component, that component communicates with the model, and the next requested action is sent back to the sandbox.

Compromising the sandbox does not automatically expose the inference credential.

The same approach can be used with other infrastructure credentials. They should enter an agent environment only when a specific task requires them, with the narrowest possible permissions, and disappear when the environment is destroyed.

Strong isolation and explicit lifecycle boundaries make this security model much easier to reason about.

MicroVMs are becoming a systems primitive

For a long time, we had processes as the cheap unit of execution and virtual machines as the expensive unit of isolation. Hardware virtualization, better VMM design, and languages like Rust have been steadily reducing the distance between those two things.

A microVM is not literally a process, and pretending otherwise ignores real differences in startup, memory, networking, and scheduling. But the operational model is starting to look similar.

Create an isolated machine. Run one thing inside it. Destroy it.

Once that becomes cheap enough, a lot of architectures that used to look unreasonable become practical. CI jobs can get machines. Plugins can get machines. User-generated code can get machines. MCP tools can get machines. Agents can get machines.

The machine does not have to be a permanent piece of infrastructure with an administrator, an SSH key, a patch schedule, and a three-year lifecycle. It can simply be the security boundary around one piece of work.

Agents are what make this urgent

Containers became ubiquitous because applications needed a better packaging primitive. We think microVMs have a similar opportunity because autonomous software needs a better execution primitive.

Traditional applications mostly run code selected by their developers ahead of time. Agents decide what code or tool to run while they are working. As they gain access to shells, browsers, interpreters, databases, infrastructure APIs, SaaS systems, and eventually physical devices, that difference starts to matter a lot.

We should assume that agents will sometimes be wrong. They will encounter hostile input. Prompt injection will continue to exist. Tools will have vulnerabilities. Models will misunderstand situations. Eventually an agent will do something nobody planned for.

The infrastructure underneath it should be designed with that assumption.