# The isolation tech behind managed AI sandboxes (gVisor, Firecracker) — worth it locally?

> Source: <https://dev.to/yujisuzuki/the-isolation-tech-behind-managed-ai-sandboxes-gvisor-firecracker-worth-it-locally-4nh0>
> Published: 2026-08-30 15:00:00+00:00

In Part 1, I laid out three options for where to draw the isolation boundary around an AI coding agent: Claude Code Sandbox, Docker AI Sandboxes, and AI Sandbox + HostMCP (this project). All three run on a normal dev machine with nothing more exotic than Docker or OS-level primitives.

But if you look at how managed cloud AI agent services isolate *their* sandboxes, a different pair of names comes up: gVisor and Firecracker. They're worth understanding on their own terms — and worth asking whether they belong in a local setup too.

Managed cloud AI agent services that need strong isolation actually use technologies like these:

Worth flagging: both of the AWS/Google services above are managed cloud services, not alternatives for a local dev environment. I'm citing them only to show that gVisor/Firecracker are real technologies actually used in production — not to run the same product-level feature comparison I did for Docker AI Sandboxes in Part 1 (they're not in the same product category to begin with).

Firecracker works by spinning up a single lightweight VM (a microVM) and running code inside it. gVisor works differently — it doesn't create a virtual machine at all. A userspace program called "Sentry" intercepts system calls and reimplements kernel functionality itself to achieve isolation (the process itself runs normally on the host). When Google describes it as "VM-level isolation strength," that's about the strength, not the mechanism — worth keeping straight.

| Approach | Creates a VM? | Runs on |
|---|---|---|
| Firecracker (AWS) | Yes (microVM) | Linux (requires KVM) |
| gVisor (Google) | No (intercepts syscalls) | Linux (as a Docker runtime) |

Both technologies are open source, so they're not cloud-provider-exclusive — you can use them locally too. How easy that is differs a lot between the two.

gVisor can be used locally just by switching the Docker runtime to `runsc`

. This raises "process isolation strength" — a different axis from AI Sandbox's "secret hiding via volume mounts" covered in Part 1 — so it's additive, not a replacement. You can check whether it's actually usable in your environment with `check-gvisor.sh`

([script on GitHub](https://github.com/YujiSuzuki/ai-sandbox/blob/main/.sandbox/host-tools/check-gvisor.sh); a read-only check run on the host OS via HostMCP).

Firecracker can run locally too, but it needs Linux + KVM plus an integration layer like `firecracker-containerd`

— switching runtimes alone isn't enough. In practice this becomes "choose an entirely different isolation boundary," putting it closer to the Docker AI Sandboxes product category from Part 1.

Whether kernel exploits need to be part of your threat model at all also depends on your dev machine's OS.

On macOS with Docker Desktop/OrbStack, it's easy to forget that containers actually run inside a separate, disposable, lightweight Linux VM — not directly on macOS itself. Even a successful kernel exploit inside a container only compromises that Linux VM directly; reaching macOS itself (the Darwin kernel) would require a separate attack on the hypervisor (a VM escape) as an additional step. In other words, on a Mac dev machine, there's already one extra layer of isolation at work — from Docker Desktop/OrbStack's own implementation — independent of anything AI Sandbox configures. So there's generally little need to add gVisor on a Mac dev machine.

On Linux with Docker running directly, a kernel exploit inside a container is a direct attack on the host OS kernel. AI Sandbox doesn't specify a runtime in `docker-compose.yml`

, so it stays on Docker's default `runc`

, with nothing blocking this path. So on a Linux dev machine, switching the Docker runtime to `runsc`

(gVisor) is worth considering. As noted above, this is an additive measure on a different axis from secret hiding, and you can check feasibility the same way, with `check-gvisor.sh`

.

Because of this difference in baseline exposure, the priority of adding gVisor-based isolation differs between Linux and Mac dev machines.

gVisor and Firecracker solve a real problem — they're what production cloud services reach for when they need strong, kernel-level isolation. But for a local dev machine, whether they're worth adopting depends heavily on your OS: on Linux, `runsc`

is a cheap, additive check worth running; on macOS, Docker Desktop/OrbStack's own VM boundary already covers most of what you'd gain. Firecracker, meanwhile, is enough of a setup lift that adopting it locally is really "pick a different isolation boundary" rather than a drop-in addition.

None of this changes the two gaps that AI Sandbox + HostMCP focuses on from Part 1 — filesystem-level secret hiding and controlled cross-container access. gVisor/Firecracker sit on the "process isolation strength" axis; AI Sandbox sits on the "does the AI's filesystem contain secrets at all" axis. They're orthogonal, and you can combine them if your setup calls for it.

If you haven't read Part 1 yet, it's here: [Part 1](https://dev.to/yujisuzuki/dont-you-trust-the-ai-vendors-own-sandbox-i-didnt-have-a-good-answer-2k50).