gVisor vs Firecracker: What we learned auditing 8,764 AI agent servers

AI agent sandboxing demands more than theoretical security models—it requires real-world validation. After auditing 8,764 Model Context Protocol (MCP) servers on MarketNow, we put gVisor’s userspace kernel to the test in production. Here’s what actually worked, what failed, and why Firecracker might be the next step.

The core trade-off: Isolation vs. performance

The debate between gVisor and Firecracker isn’t just theoretical. Both tools aim to isolate untrusted code, but they take fundamentally different approaches.

• gVisor operates as a userspace kernel, intercepting system calls before they reach the host. This adds about 5-10% overhead but provides fine-grained control over allowed operations. Its primary strength lies in catching unexpected syscalls like ptrace() or bpf(), which traditional seccomp filters might miss.

• Firecracker, in contrast, leverages KVM to create microVMs with near-zero overhead. However, it requires direct KVM access—something cloud CI runners like GitHub Actions don’t provide. Boot times are fast (~125ms), but the dependency on hardware virtualization limits its immediate applicability.

The article by chunxiaoxx framed this trade-off accurately. Our experience confirmed it: gVisor is easier to deploy today, but Firecracker could offer better performance and isolation when KVM is available.

Lessons from running gVisor in GitHub Actions

Deploying gVisor in a CI environment like GitHub Actions introduced unexpected challenges. Here’s what we discovered the hard way:

Installation hurdles

gVisor’s setup isn’t as straightforward as standard Docker runtimes. The Docker daemon configuration requires root-level modifications, which aren’t possible on GitHub’s shared runners:

sudo wget -q  -O /usr/local/bin/runsc
sudo chmod +x /usr/local/bin/runsc

echo '{"runtimes":{"runsc":{"path":"/usr/local/bin/runsc"}}}' | sudo tee /etc/docker/daemon.json
sudo systemctl restart docker

Without these steps, the runsc runtime won’t function, breaking your sandboxing pipeline.

Network isolation pitfalls

A common mistake is assuming --network none during builds will suffice for isolation. In reality, build-time network restrictions break dependency installations:

docker build --network none .  # ❌ Fails with npm install errors

Instead, apply network isolation at runtime:

docker run --network none my-image  # ✅ Safe and functional

Runtime isolation is where gVisor’s true value lies.

Syscall interception in action

gVisor’s ability to block unexpected syscalls proved invaluable. During our audit, we observed:

• One server attempted to use ptrace(), which gVisor blocked with an EPERM error.
• Another tried to load a BPF program, but gVisor returned ENOSYS since it doesn’t implement BPF support.
• No servers managed to exploit kernel vulnerabilities—though gVisor would have caught such attempts if they occurred.

These findings highlight gVisor’s strength: it doesn’t just restrict syscalls arbitrarily—it enforces a strict security model that prevents entire classes of attacks.

Compatibility failures and fallbacks

About half of all MCP servers failed to start under gVisor. This wasn’t due to security restrictions but because the servers relied on syscalls not implemented by gVisor’s userspace kernel. This is a feature, not a bug—it forces developers to write more portable code.

For servers that couldn’t run under gVisor, we implemented an enhanced seccomp fallback profile that blocks dangerous operations:

• Privilege escalation syscalls: ptrace, mount, umount2, reboot
• Kernel module manipulation: init_module, finit_module, delete_module
• Process introspection: process_vm_readv, process_vm_writev
• Namespace manipulation: clone3, unshare, setns
• Performance monitoring: perf_event_open
• Filesystem operations: name_to_handle_at, open_by_handle_at

This profile isn’t as strict as gVisor’s, but it still prevents the most critical attack vectors.

Our multi-layer security pipeline

MarketNow’s audit process spans six layers, each designed to catch different classes of vulnerabilities:

• L1.5 Static analysis: Checks dependencies, exposed secrets, and license compliance.
• L1.6 Behavioral analysis: Detects suspicious patterns in server behavior.
• L2 Active probing: Subjects servers to over 60 adversarial inputs to test resilience.
• L2.5 gVisor sandbox: Isolates servers in a userspace kernel environment.
• L3 Firecracker microVM: Scheduled for Q1 2027, will provide hardware-enforced isolation on self-hosted runners.
• L4 Supply chain attestation: Targeting SLSA Level 3 by Q4 2026 to verify artifact integrity.
• L5 Third-party audits: Planned for Q3 2027 with firms like Trail of Bits and Cure53.

So far, we’ve audited 8,764 MCP servers. Of the 206 that passed through our gVisor sandbox:

• 69 achieved a perfect 10/10 score with no red flags.
• 103 servers failed to start due to gVisor’s syscall limitations—a sign of their non-portable code.
• 6 servers scored 2/10, identifying critical risk factors.
• 3 servers were removed immediately for leaking environment variables.

What’s next for AI sandboxing?

Our roadmap aligns with chunxiaoxx’s recommendation: start with gVisor for broad compatibility, then migrate to Firecracker as infrastructure matures. The primary bottleneck isn’t the technology—it’s the operational constraints of cloud CI environments.

For teams considering AI agent sandboxing, the choice depends on your priorities:

• If you need immediate, deployable isolation and can tolerate slight overhead, gVisor is a strong starting point.
• If you require maximum performance and have KVM access, Firecracker is the future—but prepare for self-hosted runners.
• Regardless of the tool, a layered security approach (static analysis, behavioral testing, runtime isolation) will catch vulnerabilities that any single layer might miss.

The AI agent ecosystem is still young, but its security requirements are evolving rapidly. Tools like gVisor and Firecracker are just the beginning—expect more specialized sandboxing solutions to emerge as the threat landscape grows.