Kernel-Level Sandboxing for AI Agents
Give each AI agent its own Linux kernel on dedicated cores and memory, with direct access to its GPU. Strong isolation with no hypervisor underneath, no KVM, and no nested virtualization required. Works on bare metal or inside VMs you already run.
The Problem
AI agents need strong isolation, native performance, and fast lifecycle management. Today's options force a tradeoff.
Containers
Fast to start, but every container shares one kernel and a compromised agent can escape it. GPU passthrough works, but isolation is not sufficient for untrusted code execution.
VMs and MicroVMs
Strong isolation, but microVMs like Firecracker have no GPU passthrough, and full VMs need VFIO with all guest memory pinned and preallocated. Sharing a GPU takes SR-IOV or vGPU. Inside a cloud VM, all of it requires nested virtualization.
Multikernel Sandbox
Each agent gets its own kernel on dedicated cores, driving its GPU with the native driver. Kernel-level sandboxing without a hypervisor, on bare metal or inside the cloud VMs you already run.
Measured, Not Promised
Same server, same kernel build, one variable at a time.
Memory comes from a pool prepared once, so large disposable environments are ready in roughly constant time.
Instance memory setup 2.5x Faster context switches than a VM 1.37 µs vs 3.42 µsIsolation comes from separate kernels, not a hypervisor, so agent tool calls run on native kernel paths.
lmbench vs KVM 0 Bytes lost across four kernel panics 4 of 4 panics verified intactAn agent that crashes its kernel takes down only its own instance, and its working set on DAXFS is still there when it restarts.
Crash recoveryBuilt for AI Workloads
Kernel-Level Isolation
Each agent is sandboxed in its own kernel on its own cores and memory. A compromised agent cannot reach other agents' memory, devices, or kernel state.
Direct GPU Access
Assign a whole GPU to an agent's instance. Its kernel runs the vendor driver against real hardware: no VFIO, no VMM, no vGPU license, even inside a cloud GPU instance.
Shared Model Weights
Load model weights once into DAXFS and every agent instance maps the same physical copy, with zero copies and no per-agent load time. Firecracker has no shared filesystem, so each microVM holds its own copy.
No KVM Required
Runs on bare metal or inside VMs you already rent. No /dev/kvm, no nested virtualization, no special instance types.
Dedicated Cores
Each agent's cores run only its own kernel. No vCPU time-slicing, no steal time, no noisy neighbors between agents.
Fast Instance Creation
Instances draw memory from a prepared physical pool: 32 GiB assigned in 111 ms, with no page population on the launch path.
Crash-Contained Agents
A kernel panic stays inside one agent's instance. Memory on DAXFS survives it intact, so recovery is a kernel boot, not a cold start.
Docker Compatible
Deploy agents using your existing Docker images and workflows. No new packaging format, no new APIs.
Sandlock on Top, Multikernel Underneath
Multikernel draws the boundary between agents: each one gets its own kernel, cores, and memory. Sandlock draws the boundary inside an agent: every tool call, shell command, or generated script runs in its own lightweight process sandbox, confined by Landlock and seccomp, with network egress denied by default.
A compromised tool has to escape Sandlock to reach the rest of its agent, then escape the agent's kernel to reach anyone else. Sandlock starts in about 5 ms and needs no root, containers, or hypervisor, so the inner layer adds almost nothing to each call.
How to Get It
Multikernel Sandbox is open-source software you deploy on your own infrastructure. Free to download and build; enterprise adoption runs through our design partner program.
Open Source
Download and build from source. Deploy AI agent sandboxes on any multikernel-enabled Linux machine. Community support via GitHub issues.
Design Partner Program
We are onboarding a small number of AI platform teams as design partners: the team that builds Multikernel works embedded with yours, and your requirements drive the roadmap.