Response to 'gVisor vs Firecracker for AI Agent Sandboxing' — what we learned auditing 8,764 MCP servers

Short summary

A production deep-dive into sandboxing MCP servers with gVisor, revealing that ~50% of 8,764 audited servers fail under gVisor due to unimplemented syscalls, while a small number attempted dangerous calls like ptrace and bpf. The author outlines a layered audit roadmap from gVisor (live) to Firecracker microVMs (Q1 2027), noting Firecracker's KVM requirement blocks adoption on managed CI runners. A strict seccomp profile blocking ptrace, bpf, mount, and kernel module syscalls serves as fallback when gVisor is unavailable.

• •~50% of 8,764 audited MCP servers fail under gVisor due to unimplemented syscalls; 1 attempted ptrace, 1 attempted bpf, 3 removed for leaking env vars
• •Layered security roadmap: gVisor sandbox live now, Firecracker microVM planned Q1 2027 (blocked by KVM access on cloud CI runners)
• •Strict seccomp fallback profile blocks ptrace, bpf, mount, kexec_load, clone3, unshare, init_module, perf_event_open and other kernel-level syscalls

Generated with AI, which can make mistakes.