Why AI needs a new isolation boundary

For most of the last twenty years, infrastructure security has been built around a fairly stable assumption: software is written by people, reviewed by people, deployed through controlled processes, and then operated within boundaries we understand reasonably well.

AI changes that assumption.

We are moving toward systems that can reason over a task, generate code, invoke tools, modify files, call APIs, interact with infrastructure, and choose their next action at runtime. That is a very different workload from a traditional application server or a container running a known service. The software is no longer simply executing a path that was defined before deployment. In many cases, it is deciding what to do while it is already running.

That shift matters because much of the infrastructure underneath AI was designed for a different era.

Containers, Kubernetes, virtual machines, and the security systems surrounding them are all important parts of modern computing. None of them are going away. But the assumptions behind how we use them need to change as the software running on top becomes more autonomous and more capable.

At Mainsail, we believe microVMs are becoming an important part of that new foundation. That is why both e0, our secure execution environment for AI agents, and x0, our Kubernetes platform, are built around microVM technology. The goal is to get the hardware-enforced isolation benefits of virtualization without carrying forward all of the operational weight traditionally associated with virtual machines.

Containers solved a different problem

Containers were one of the most important infrastructure developments of the last two decades. They made software easier to package, distribute, deploy, and scale, and they gave organizations a far more efficient way to operate applications than treating every workload like a server.

But containers were primarily an application packaging and process-isolation technology. They were not designed to give every workload its own hardware security boundary.

Most containers share the host kernel. Technologies such as namespaces, cgroups, seccomp, SELinux, capabilities, and runtime security can create strong layers of protection around that model, and Starlight uses many of them. The architecture is proven and, for many workloads, entirely appropriate.

AI makes the tradeoff more important.

An autonomous agent can receive an objective instead of a fixed instruction set. It may generate commands, manipulate files, interact with external systems, process untrusted content, call tools, and make decisions based on model output. Even when the model is trusted and the application is well designed, the behavior of the system is less deterministic than the traditional workloads infrastructure teams have spent decades securing.

That does not make agents inherently unsafe. It does mean we should be more deliberate about how much of the surrounding system they are allowed to trust.

The same is true of Kubernetes. As clusters become a home for inference services, AI applications, data pipelines, automation, and autonomous software, the consequences of a compromised or misbehaving workload increase. The shared-kernel model that was a reasonable efficiency tradeoff for conventional services deserves another look when the software running inside the environment has considerably more authority.

Why microVMs

The traditional answer to stronger isolation has always been the virtual machine.

A VM gives a workload its own kernel and places a hardware virtualization boundary between the guest and the host. The problem is that conventional virtual machines also carry decades of assumptions about how computers are deployed and managed. They are generally treated as long-lived systems with complete operating environments, generalized virtual hardware, persistent configuration, and lifecycle tooling modeled after physical servers.

That model works well when the workload is, effectively, a server.

It is less attractive when the thing being isolated may exist for a few seconds or minutes.

MicroVMs preserve the part of virtualization that matters most for this problem: the workload runs behind a KVM-backed hardware boundary with its own guest kernel. The surrounding environment can be much smaller and more purpose-built.

Starlight uses libkrun and KVM to provide lightweight microVM execution with dedicated CPU and memory boundaries and isolated guest kernels. For e0 and x0, we are engineering the environment around very fast startup, with a target of booting purpose-built microVMs in less than 100 milliseconds. That speed is important because it changes how often we can reasonably use a hardware isolation boundary.

If creating an isolated machine becomes close enough to creating a container or process, the VM boundary no longer has to be reserved for a small number of heavyweight workloads. It can become part of the normal execution model.

That is where microVMs become particularly useful for AI.

e0: isolating autonomous execution

e0 is Starlight's secure execution environment for AI agents. Its architecture begins with a simple principle: model-generated actions should be treated as untrusted execution, even when the larger application is trusted.

There are many ways an agent can behave unexpectedly without anything being fundamentally wrong with the model. It can process malicious input, follow a prompt injection, generate vulnerable code, misunderstand a tool response, choose the wrong command, or simply make a bad decision.

Trying to eliminate every possible mistake before execution is unrealistic. Infrastructure has to assume that unexpected behavior will eventually happen and be designed to limit what that behavior can affect.

In e0, every execution session runs inside its own disposable libkrun microVM. The session gets a separate guest kernel and a KVM hardware boundary rather than sharing the host kernel with other agent sessions. When the work is complete, the compute environment can be destroyed while the agent's durable workspace remains available for future sessions.

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

That separation between compute and state is important. It means an agent does not need to retain the same execution environment indefinitely simply because its work needs to persist.

e0 also keeps critical authority outside the guest. The first-party planner runs on the host. Inference credentials do not enter the agent microVM. Network access is controlled externally. Resource budgets are host enforced. Audit records are maintained outside the workload, alongside independent runtime, model-I/O, network, and host evidence.

The point is not to assume that an agent can never be compromised. The architecture is designed so that a compromised or badly behaving guest still does not automatically gain the authority of the host, the inference service, another session, or the systems around it.

That is a much more practical way to think about autonomous software.

x0: putting a stronger boundary underneath Kubernetes

We applied the same thinking to Kubernetes with x0.

x0 runs standard k3s or k0s, but each controller and worker node runs inside its own libkrun microVM. Kubernetes itself remains familiar. The Kubernetes API, kubectl, Helm, CRDs, operators, controllers, kubelet, and the Kubernetes scheduler continue to work as expected.

What changes is the execution boundary underneath the node.

Signed OCI Kubernetes-node image
            |
            v
      libkrun microVM
            |
            v
  independent guest kernel
            |
            v
      k0s + containerd
            |
            v
  Kubernetes OCI workloads

Each x0 node gets its own guest kernel, CPU and memory allocation, network identity, persistent node state, and hardware-backed isolation boundary. That gives us a stronger separation between Kubernetes nodes and clusters without requiring customers to adopt a proprietary replacement for Kubernetes.

That matters because replacing Kubernetes would solve the wrong problem.

Kubernetes is already deeply embedded in enterprise infrastructure, developer workflows, commercial software, and modern AI platforms. There is enormous value in preserving that ecosystem. The opportunity is not to discard Kubernetes but to improve the substrate it runs on.

MicroVMs let us do that.

Instead of treating every Kubernetes node as a conventional heavyweight VM, x0 can use a purpose-built microVM. Instead of relying only on container boundaries between workloads and the infrastructure underneath them, each node begins with its own isolated kernel.

For conventional workloads, that is a useful security improvement. For AI infrastructure, where clusters increasingly host models, agents, data services, and automation with access to sensitive systems, the additional boundary becomes much more valuable.

Confidential microVMs

Hardware virtualization solves one part of the trust problem. Confidential computing extends that boundary further.

Intel TDX and AMD SEV-SNP allow workloads to execute in protected memory environments backed by the processor. In the supported threat model, the host kernel or hypervisor cannot simply inspect guest memory or CPU state, and the workload can produce attestation evidence describing the environment in which it is running.

This creates a different relationship between the workload and the infrastructure operator.

In a conventional virtualized system, root on the host remains extraordinarily powerful. Confidential computing is designed to reduce how much the workload has to trust that host.

That is particularly interesting for AI because the data being processed may be far more sensitive than the application code itself. Agents and models may work with proprietary source code, operational plans, financial information, intelligence data, customer records, credentials, or regulated information. Protecting the application perimeter is useful, but increasingly we also need to protect the execution environment while that information is being processed.

MicroVMs and confidential computing work well together because the isolation boundary is already small and purpose-built. A workload can receive its own hardware-isolated environment, and on compatible hardware that environment can also become a confidential microVM protected by technologies such as TDX or SEV-SNP.

The long-term significance is not simply "encrypted VMs." It is the ability to create small, short-lived, attestable execution environments for individual workloads and tasks without treating every one of them like a traditional server.

Infrastructure has to change with the software

The infrastructure industry has spent decades moving toward higher levels of abstraction. Physical systems became virtual machines. Virtual machines gave way to containers. Containers became Kubernetes resources. Applications became APIs. Now agents are beginning to consume those APIs and act across them.

That progression has made computing easier to operate, but every abstraction still depends on a security boundary somewhere underneath it.

AI is making that boundary more important again.

As software becomes more autonomous, the infrastructure below it needs to assume less about how the workload will behave. Security controls need to live outside the workload wherever possible. Credentials should not automatically travel with execution. Audit systems should not depend entirely on the software being audited. Network access should be explicit. Resource limits should be enforced externally. Sensitive execution should be able to use hardware-backed confidentiality.

MicroVMs give us a useful foundation for that model because they combine a real virtualization boundary with a lifecycle that is much closer to modern application infrastructure.

For e0, that means an agent session can receive its own disposable hardware-isolated execution environment.

For x0, it means every Kubernetes controller and worker can run behind its own microVM boundary while preserving the Kubernetes ecosystem.

With confidential computing, those same environments can be extended so that even the host has a more limited view into the workload.

None of this means containers, Kubernetes, or conventional virtual machines are obsolete. They remain essential technologies. But the rise of AI changes where we should use each of them.

The software we are deploying today has more authority, more access, and more freedom to decide what happens next than the software these platforms were originally designed to run. The infrastructure underneath it should reflect that reality.

That is why microVMs are becoming a core part of Starlight's architecture, and why we expect hardware isolation to become much more common as AI moves from answering questions to taking action.

Want to see the boundary in practice? Talk with Mainsail about running agents and Kubernetes on Starlight microVMs, or read more about agent microVMs and Kubernetes microVMs.