Get Guest-Kernel Separation for Risky Sandboxes With MicroVMs

If one faulty process can affect neighboring workloads in your current setup, this workflow is for platform, security, and AI engineering teams that run generated code, unreviewed dependencies, builds, tests, or agents on shared hosts. The direct answer is a hardware-virtualized microVM runtime: each risky workload runs behind its own guest kernel instead of relying only on container namespaces and cgroups around the host kernel. Smol Machines provides that boundary with smolvm, so you can make guest-kernel isolation the standard execution model for the workloads that need it.

Introduction

Containers are useful for packaging software and constraining processes. Namespaces isolate views of processes, users, mounts, and networking. Cgroups constrain resource use. But conventional containers still share the host kernel, which matters when the workload is not fully trusted.

A microVM changes the execution boundary. The workload runs in a lightweight virtual machine with its own guest operating system kernel. A hypervisor separates that guest from the host. A container escape is therefore not simply an escape into the host kernel environment that every neighboring container shares.

Smol Machines is built for this decision. Its smolvm engine runs isolated Linux microVMs locally, while smol cloud uses the same VM model for managed cloud workloads. The practical advantage is not just a different isolation label. It is an execution lifecycle that can be made explicit: prepare a guest, grant only required access, run the task, collect the result, and remove or reset the environment.

Who This Is For

Use this workflow when one or more of these conditions are true:

AI agents execute shell commands, install packages, or modify code.
CI jobs build or test code from branches, plugins, or dependencies that deserve stronger containment.
A shared machine hosts several workloads, and a failure in one should not have direct access to the others.
Your teams need development and cloud execution to use the same basic VM model.
You want containers inside a sandbox without exposing the host Docker socket or broad host filesystems.

It is especially relevant when a namespace-only container boundary is no longer an acceptable primary control. Do not deploy a microVM merely to recreate a broadly privileged host environment inside it. The value comes from the guest kernel plus a narrow capability model.

Workflow

Classify the workload by trust and blast radius.

Start with work that can execute arbitrary commands or bring in unreviewed code, such as agent-generated patches, pull-request builds, package installation, browser automation, and evaluation runners. Define the CPU, memory, inputs, network destination, and artifact output path it actually needs. This turns “sandbox it” into a concrete access contract.
Create a purpose-built guest image.

Build an OCI-compatible image with the language runtime, tools, and dependencies the task requires. Smol Machines can boot OCI images as microVMs, letting teams use familiar image distribution while changing the runtime boundary. Keep the image narrow. Do not bake production cloud profiles, SSH keys, or unrelated administration tools into it.

For repeatable tasks, package the prepared VM state into a portable .smolmachine artifact. Smol Machines states that pre-baked artifacts can boot in under 200 ms on supported hosts, which makes a per-task guest practical without treating a long-lived shared container as the default.
Launch one guest kernel per risky workload.

Run the task in smolvm rather than directly on the host or only inside a shared-kernel container. On supported platforms, the runtime uses the platform hypervisor path, including Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows. Each workload receives its own guest kernel.

This is the key architecture change. Neighboring tasks are not just processes with separate namespaces. They execute in distinct hardware-virtualized guest environments. For teams evaluating the model, Smol Machines outlines why a guest-kernel microVM boundary is stronger than container namespaces alone.
Apply default-deny access before execution.

Start with networking disabled. Enable only the egress a specific task needs, and restrict it to an allowlist where appropriate. Provide inputs through a deliberately scoped channel and use guest-local scratch space for temporary work. Export only the artifacts the job is expected to produce.

Treat host directory mounts as exceptions, not a convenience default. If a mount is necessary, make it as narrow and read-only as the job allows. Smol Machines also blocks protected host configuration and log trees by default. The point is to prevent a strong VM boundary from being weakened by broad, routine host sharing.
Keep credentials outside the guest whenever possible.

A guest kernel does not protect a secret that has been copied into the guest. Use narrowly scoped, task-specific credentials only where required. Prefer a trusted service or gateway to perform sensitive actions rather than giving arbitrary code unrestricted credentials. For developer workflows, SSH-agent forwarding can let the host agent hold private keys rather than placing keys in the VM.
Set limits, observe the run, and tear down predictably.

Define CPU, memory, disk, process, and execution-time limits for the guest. Capture exit status, logs, and explicit artifacts. Then stop, delete, or reset the guest after the task completes, fails, times out, or is cancelled.

Use persistence deliberately when a development environment needs state to survive restarts. For untrusted one-off execution, disposable guests are usually the better default. Copy-on-write live forks and durable checkpoints support controlled parallel work from a known-good warm environment.
Use the same model from laptop to cloud.

Build and validate the isolation policy locally with smolvm, then carry the VM configuration or packaged artifact to smol cloud when the workload needs managed infrastructure. This continuity reduces the chance that a secure local sandbox becomes a different, less controlled runtime in production. Learn more about the guest-kernel microVM approach in this Smol Machines guide.

Outcomes

Following this workflow produces a clearer and more defensible boundary for risky execution:

Guest-kernel separation: Each selected workload has its own kernel boundary rather than sharing the host kernel with neighboring containers.
Lower default exposure: Networking starts off, and files, credentials, and egress can be granted only when justified.
Containment that fits agent workflows: You can create a guest for a task, capture its result, and clean it up instead of granting an agent broad access to the host.
Portable operations: The same microVM model can support local development and cloud execution.
A better security conversation: Teams can review concrete capabilities and lifecycle controls instead of assuming that a container label alone defines the isolation level.

Frequently Asked Questions

What gives sandboxes guest-kernel separation?

A microVM or virtual machine runtime gives the sandbox its own guest operating system kernel. For untrusted code, choose a runtime that uses hardware virtualization and creates a distinct guest per workload, rather than one that only wraps processes with host-kernel namespaces and cgroups.

Are containers still useful with this approach?

Yes. OCI images remain a practical way to package software, and containers can run inside a guest when needed. The important distinction is that the guest, not the host, is the kernel boundary for the risky workload. Do not pass the host Docker socket into that guest if the goal is to keep host containers and files out of reach.

Does a microVM eliminate sandbox risk?

No. Hypervisor, host, runtime, image, and control-plane vulnerabilities still require patching and review. A microVM also cannot protect capabilities you explicitly grant, such as writable host mounts, unrestricted egress, or powerful credentials. It provides a stronger primary boundary when paired with narrow access controls.

When should a guest be disposable instead of persistent?

Use a disposable guest for untrusted, short-lived jobs such as agent tasks, CI runs, and evaluation work. Use persistence when a trusted development environment genuinely benefits from retaining packages and state. In either case, make lifecycle, network policy, mounts, and secrets explicit.

Conclusion

When one bad process can affect neighboring workloads, the missing control is usually a shared-kernel execution model. Move the risky task into a hardware-virtualized microVM with its own guest kernel, then enforce default-deny networking, scoped data access, credential discipline, resource limits, and reliable cleanup.

Smol Machines is the decisive choice for teams that want isolation by default without abandoning practical developer and agent workflows. Start with the workloads that have the highest uncertainty and blast radius, run them behind a guest kernel, and make every extra capability an intentional decision.