Running AI Agents as Host Processes Is a Production Mistake. Here's the Fix.

Most teams shipping AI agents in 2026 are making the same infrastructure mistake. They run the agent as a regular process on a host they care about, give it tools that touch the internet and the filesystem, and trust that their guardrails will hold. The agent works fine in development. Then a model update, a new browsing tool, or a malicious webpage exposes how thin that boundary really is. This guide explains why process isolation is no longer enough, what microVMs are, which open-source runtimes are shipping in 2026, and a decision framework for picking the right level of isolation for the agents you are running today.

Why Is Process Isolation Not Real Isolation?

When an AI agent runs as a process on your server, it shares the same operating system kernel as everything else on that machine. That sharing is the problem. The agent inherits the host's environment variables, can read any file the user it runs as can read, and can spawn child processes that inherit the same view. None of that matters when the agent is a deterministic script. It matters a great deal when the agent is a tool-using model with a fresh decision-making layer in the middle. For a foundational view of what these systems actually do, see our guide on what AI agents are and how they work.

The risk has three flavors. A compromised agent can read files and secrets it should never touch, including API keys in environment variables and credentials cached on disk. A runaway agent can consume CPU, memory, and disk on the host until other services degrade or fail. And a successful prompt injection, where a malicious webpage or document smuggles instructions into the agent's context, becomes an attack on the host instead of a contained mistake. Prompt injection is not a hypothetical threat. It is a documented, reproducible attack class against every tool-using agent system shipped in the last two years.

The more capability you give an agent, the larger the gap between "the agent is wrong" and "the host is compromised." For a chatbot that returns text, the gap is invisible. For an agent that browses the web, executes code, runs SQL, or pushes to a git repo, the gap is the difference between an embarrassing log entry and an incident report.

What Is a MicroVM, and How Is It Different From a Container?

A microVM is a lightweight virtual machine. It is not a heavy traditional VM (slow to boot, big disk image), and it is not a container (which shares the host kernel). It sits in the middle. Each microVM gets its own minimal guest kernel, runs under hardware-level isolation via KVM on Linux or Hypervisor.framework on macOS, and exposes only the devices and network paths you allow. Boot time is measured in milliseconds, not minutes, which is what makes per-session microVMs practical for interactive AI agent workloads.

The trade-off table looks like this:

The microVM row is the one to focus on. It gives you the isolation properties of a full VM with boot times close enough to a container that you can spin one up per agent session, do the work, and tear it down without users noticing.

What Are the Real MicroVM Tools Shipping in 2026?

Three open-source projects matter for AI agent isolation right now. They are all in the libkrun family, all production-ready or close to it, and they each solve a slightly different shape of the problem.

libkrun (containers/libkrun)

libkrun is the foundation. It is a dynamic library, maintained under the containers organization on GitHub, that embeds a minimal Virtual Machine Monitor directly into a host process. It abstracts complex virtualization behind a simple C API and uses KVM on Linux and Hypervisor.framework on macOS and ARM64. The result is microVM-grade isolation with a footprint close to a container, no separate VMM daemon required. libkrun is the building block. The tools below sit on top of it.

microsandbox

microsandbox is an open-source, self-hosted sandbox runtime for AI agent code execution, built in Rust by Zerocore AI. It uses libkrun under the hood, advertises sub-200ms cold-start times, and runs standard OCI container images, so any image you already have can run as a hardware-isolated guest. The first public release shipped in May 2025, and the project has accumulated roughly 3,300 GitHub stars in the time since. The interesting design choice is the network layer. Secrets never leave the host. When the sandboxed agent makes a verified TLS connection to an allowed host, microsandbox swaps a placeholder for the real credential at the network boundary, so the agent itself never sees the secret. DNS rebinding protection, cloud metadata blocking, and DNS-to-IP binding all activate by default. If you are building a backend that runs user-supplied or model-generated code (think AI tool calls, per-user notebooks, or evaluator pipelines), this is the runtime to evaluate first.

brood-box (Stacklok)

brood-box, from Stacklok, is the opposite shape. It is a CLI tool for running coding agents (Claude Code, Codex, OpenCode) inside a hardware-isolated microVM with the feel of a local terminal. Under the hood it uses go-microvm, which sits on libkrun, for sub-second VM boots. The workspace snapshot uses FICLONE on Linux and clonefile(2) on macOS for near-instant copy-on-write cloning, so the agent gets a full copy of your project to work in without touching the original until you say so. Network access from inside the VM is governed by three egress profiles: locked (only the LLM provider's API endpoint), standard (LLM plus common developer infrastructure), and permissive (all outbound traffic). When the session ends, you review every diff before a single byte touches your real workspace. If you are running coding agents on developer laptops or in CI, this is the one.

Red Hat RamaLama and the broader pattern

The pattern is broader than the agent-runtime niche. Red Hat's RamaLama project, covered in the Red Hat Developer article "Supercharging AI isolation: microVMs with RamaLama and libkrun," pulled libkrun-based isolation into mainstream model-serving in mid-2025. When a vendor like Red Hat is shipping libkrun integrations into a production AI tool, the maturity argument is settled. The technology works, it is supported, and it is becoming a default rather than a curiosity. For broader context on where production agents are landing, see our landscape analysis on where agentic AI is actually working in 2026.

What About NVIDIA OpenShell?

NVIDIA OpenShell, announced at GTC 2026 and currently in alpha, is worth a separate paragraph because it solves the same problem with a fundamentally different architecture. OpenShell does not use libkrun or microVMs. It runs as a K3s Kubernetes cluster inside a single Docker container, and the isolation properties come from a stack of Linux Security Module enforcement (Landlock for filesystem, seccomp for syscalls) plus an OPA-evaluated HTTP CONNECT egress proxy for network policy. The tagline that captures the difference is "here is a policy engine, declare what the agent can do" rather than "here is a sandbox, run your code inside."

Both approaches close the process-isolation gap. They make different trade-offs. A microVM gives you a dedicated guest kernel per session, which is the strongest possible boundary against kernel-level escape, at the cost of a separate guest to manage. A Landlock-plus-policy approach reuses the host kernel, which is lighter weight, but it depends on the kernel features being correctly applied and the policy being correctly written. For a high-stakes workload where the kernel is the attack surface you most worry about, microVMs are the right call. For a centralized, policy-governed agent platform where you want declarative rules per agent, an OpenShell-shaped approach has real ergonomic advantages. They are not mutually exclusive, and you will see hybrid setups (microVMs governed by an external policy engine) become normal in late 2026.

Which Isolation Level Should You Actually Pick?

The right isolation level is a function of what tools the agent has, what data it can see, and what the cost of a host compromise would be. Use this as a starting point and adjust upward when in doubt.

What Does This Look Like in Practice?

Adopting microVM isolation for an existing agent is not a rewrite. It is five concrete steps, each measurable on its own.

Step 1: Inventory the tool surface. List every tool the agent has access to. For each tool, write down what it can read, what it can write, and whether it can take in untrusted text from the outside world. Web browsing, retrieval from a vector store of user uploads, code execution, shell access, and file reads from a writable directory all count as untrusted input. The output of this step is a simple risk classification per tool.

Step 2: Pick a runtime that matches the shape. If the agent runs locally on developer machines or in CI for coding work, evaluate brood-box. If the agent is an HTTP service that runs code per request or per user, evaluate microsandbox. If your agent platform is centralized and you want declarative policy more than per-session isolation, NVIDIA OpenShell is worth a serious look. Pick one runtime for the first migration. Mixing runtimes early creates more operational overhead than the security gain is worth.

Step 3: Lock egress. The default for any new sandbox should be the most restrictive egress profile that still lets the agent do its job. brood-box ships locked, standard, and permissive profiles out of the box. microsandbox lets you allow-list specific hosts and rewrite credentials at the network layer. Start with the smallest allow-list, add hosts only when something breaks, and keep an audit log of additions. The principle is the same as any firewall rule: deny by default, allow by exception, review the exceptions.

Step 4: Rotate per session. A microVM you reuse across sessions is much weaker than one you spin up fresh. State leaks between users, cached context from one task influences another, and a successful prompt injection in session N can plant a payload that triggers in session N+1. Build the orchestration so a new user request gets a fresh guest, and the guest is destroyed at the end of the request. Sub-200ms boot times exist for exactly this pattern.

Step 5: Measure containment, not prevention. Your metric is not "how many prompt injections did we block." The model-layer guardrails will fail sometimes, and that is fine. Your metric is "when an agent did something wrong, what did it actually reach." Track every escape attempt, every blocked egress, every sandbox kill. If those numbers are zero, your detection is broken, not your security. Adversarial agents leave footprints. Good isolation lets you see them. For a deeper view of how agentic systems are evolving in production, see our guide on designing agentic AI workflows for production.

What Mistakes Are Teams Making in 2026?

Defaulting to bare Docker for browsing agents. A container is a fine boundary for a deterministic worker. It is the wrong boundary for an agent that loads pages from the open web. The threat model includes attacker-controlled HTML, and the kernel surface inside a container is not built to absorb that. If an agent has a browser tool, the runtime should not be a container.

Trusting prompt-level guardrails over execution-level isolation. System prompts, refusal training, and content filters are useful, but they are not a security control. They reduce the rate of attempts. They do not bound the consequences. A team that invests heavily in prompt hardening and ships the agent as a host process has invested in the wrong layer. The isolation boundary is the part that has to hold when everything else fails.

Reusing sandboxes across sessions. Long-lived sandboxes are a convenience feature that quietly converts a fresh-per-session security model into a shared-state security model. Once you reuse a guest, you are back to many of the failure modes of a process-on-host setup, just with extra steps.

Not locking egress. The most common operational shortcut is to leave outbound traffic wide open because something might need to call something. Wide open egress is how exfiltrated credentials leave your network. Allow-list the destinations, log every denied request, and review the log weekly. The friction of adding a host to an allow-list is much less than the cost of explaining a credential leak.

Frequently Asked Questions