I Gave an AI Agent Root Access. Nothing Broke.

How I sandbox LLM agents in disposable Firecracker microVMs on Krova Cloud — no public IP, one-command lifecycle, and why containers weren't a real boundary.

Why containers weren't enough
The standard advice — "run the agent in a Docker container, drop privileges" — fails in one specific way: containers share a kernel. Every container on that host is one kernel bug away from its neighbors. That's exactly why Firecracker exists. AWS built it to run other people's code at scale because namespaces weren't a real boundary.

So the agent gets a microVM. Own kernel, own rootfs, own everything.

The setup
On Krova Cloud each microVM is called a Cube. Whole provisioning is one command:

npm i -g @krovacloud/cli

krova cubes create agent-1 --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04
# ✓ Cube provisioned  ·  booted in 0.9s

krova ssh agent-1
root@agent-1:~#

Two things matter here:

1. No public IP. The Cube sits on a private NAT'd network. There's no address to scan, no port 22 on the internet, no inbound surface. Check for yourself from inside:

root@agent-1:~# ip -brief addr
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.x.x/24   # private. that's it.

root@agent-1:~# ss -tlnp
# only listeners *you* started — nothing is reachable from outside

Traffic only enters through ports you explicitly open, and those can be IP-allowlisted. For an agent box, I open nothing.

1. It's disposable. Boots in under a second, billed by the minute. So I stopped treating it as a pet: each agent session gets a fresh Cube, and when the session ends it's deleted. No leftover cron jobs, no stale credentials sitting in a long-lived environment.

The session lifecycle I actually run

set -euo pipefail

CUBE="agent-$(date +%s)"

# fresh box per session
krova cubes create "$CUBE" --cpu 2 --ram 4 --disk 40 --image ubuntu-24.04

# credentials injected at runtime as short-lived env vars,
# never baked into the image
krova ssh "$CUBE"

# session over? nothing to clean up
krova cubes delete "$CUBE"

And when I automate it from CI instead of my laptop, it's the v1 API — idempotency key included so retries don't double-provision:

curl -X POST https://krova.cloud/api/v1/spaces/$SPACE/cubes \
  -H "X-API-KEY: $KROVA_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "name": "agent-session-42",
    "image": "ubuntu-24.04",
    "resources": { "vcpu": 2, "ramGb": 4, "diskGb": 40 }
  }'

A session that lives 20 minutes on a 2 vCPU / 4 GB Cube costs a few cents, minute-billed. Cheaper than the coffee I drink while it runs.

The parts I still don't trust (read this)
Isolation is not the same as safety. Let me be blunt, because this is where people get hurt:

A microVM stops the agent from escaping to your other workloads. It does not stop it from wrecking its own box.
It does not stop it from using credentials you handed it. AdministratorAccess AWS keys + a bulletproof sandbox = a very secure machine making a very expensive mistake.
So the boring controls still apply, on top of the VM:

Scoped, short-lived tokens — injected at runtime, never in the image
No shared volumes with anything you care about
Egress restricted where it matters (the agent doesn't need your whole network)
The VM is the blast radius. Credential scoping is the actual control. Krova gives you the boundary — the hygiene inside it is still your job, same as any self-hosted box.

Anyone telling you "just sandbox it and you're done" is selling something.

The takeaway
I used to think agent safety was a model problem. A big chunk of it is an infrastructure problem you can solve today with 2018-era technology:

Give it a real boundary (own kernel, not namespaces)
Give it no address (no public IP)
Throw it away when you're done
That's the whole trick.

How are you sandboxing agents right now — containers, microVMs, or "vibes and hope"? And has anyone actually measured escape risk on their current setup? Would love to compare notes in the comments.