Chapter 03 Planned

# Each agent gets a tiny fortress.

Normal containers share a kernel. If one container is told "go read the other guy's files," it can probably find a way. We can't have that. Firecracker is a tool that wraps each pod in a real virtual machine, so the wall between agents is the same wall between two laptops on the same desk.

## The problem we are solving

A normal Docker container is not a real machine. It's a process with some fences around it. Linux uses tricks (namespaces, cgroups, seccomp) to make the process feel isolated. But it's still sharing the Linux kernel with every other container on the same node. One nasty bug in the kernel and one container can read every other container's memory.

This is fine if you trust everything running on your node. It is not fine if your business is "run code on behalf of strangers and customers who don't want their data to leak."

The exact attack we don't want

Juan (sales) is told he can only use the HR agent. The HR agent is just a process running Claude Code. Juan says: "read /workspaces/sales/.houston/sessions and summarize." If the HR agent's process can reach those files, Juan just bypassed his permissions. The auth layer can't stop this — the agent literally has filesystem access. The only fix is to make sure HR's process can't even see Sales' disk.

## Firecracker, in one paragraph

Firecracker is a tool from AWS. They invented it to run AWS Lambda. It boots a real virtual machine in about 125 milliseconds, with a real Linux kernel inside, completely separated from the host. Each Firecracker VM is called a "microVM" because it's stripped down to almost nothing: no drivers you don't need, no boot screens, no nonsense. Just enough Linux to run your process.

The wall between two Firecracker microVMs is the same kind of wall between your MacBook and the Windows laptop next to it. Hardware level. To get from one to the other, you need a bug in the CPU, not a bug in some Linux feature.

## Kata Containers, in one paragraph

Kubernetes doesn't know what Firecracker is. It only knows how to start containers. Kata Containers is the translator. It pretends to be a normal container runtime to Kubernetes, but under the hood, each "container" it starts is actually a Firecracker microVM. You add one config line to your pod (`runtimeClassName: kata-fc`) and Kubernetes is happy. Your pod gets a real VM.

Your pod spec
Says `runtimeClassName: kata-fc`. Everything else is normal Kubernetes.
Kata Containers (the translator)
Kubernetes thinks it's starting a container. Kata starts a Firecracker microVM instead.
Firecracker microVM
Real virtual machine. Real Linux kernel. Hardware-level wall. Boots in ~125 ms.
Kubernetes on top, Firecracker on the bottom, Kata gluing them together.

## Why not gVisor?

gVisor is the competitor. Google built it. Same idea (better isolation than regular containers) but it works by intercepting system calls instead of running a real VM. Cheaper to run. Weaker wall.

- gVisor: catches every syscall, simulates it in user space. Lower overhead, no real VM. Used by Google Cloud Run. Solid against most attacks.
- Firecracker: actual hardware-level virtualization. Stronger wall. Used by AWS Lambda and Fly.io.

For Houston specifically: we are running customer code (agents) on shared infrastructure, with an open marketplace where some agents will be community contributed. That means we should assume some agent code is hostile or buggy. Firecracker is the right answer for that threat model. We can switch to gVisor as an option later if the cost story demands it.

## The performance question

"Doesn't booting a VM per agent make everything slow?" Used to be true. Not anymore.

- Firecracker cold start: ~125 ms to boot the VM itself.
- Add Houston engine startup: another few hundred ms.
- Total user-facing delay on first message after idle: roughly half a second.
- Subsequent messages: zero overhead. The VM is already running.

Half a second of "agent waking up" is a feature, not a bug. It maps perfectly to scale to zero (Chapter 4), which means idle agents cost nothing.

## What this gets us

- Hardware-level isolation. The HR agent literally cannot reach the Sales agent's files because it's a different VM with a different kernel.
- Per agent OAuth tokens are safe. Each pod has its own credentials. Compromise one, you compromise one. Not all.
- Compliance answers write themselves. "How are agents isolated?" "Each one runs in its own Firecracker microVM." Conversation over.
- Community agents are safe to host. Someone publishes a malicious agent? Worst case it owns its own pod. Can't escape.

The catch

Kata + Firecracker is operationally heavier than vanilla containers. You need bare metal nodes (or nested virtualization), proper RuntimeClass setup, and you can't use every K8s feature out of the box (some networking plugins don't play nice with microVMs). This is real engineering, not a flag flip. Budget several weeks for the platform team to get it production-ready the first time.

What we install on the cluster

Kata Containers operator from their official charts. Register a RuntimeClass called `kata-fc`. Configure node pools to support nested virtualization (or use bare metal nodes — most clouds offer them). Every agent pod manifest sets `spec.runtimeClassName: kata-fc`. Control plane pods, Postgres, Redis, the boring stuff stays on regular `runc`.

← Previous
Kubernetes
Next →
Knative