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

A developer building MarketNow, a marketplace for MCP servers, shares findings from auditing 8,764 MCP servers using gVisor for sandboxing. They found that about 50% of MCP servers fail to start under gVisor due to unsupported syscalls, which they consider a feature, and they use a strict seccomp profile as a fallback. The team plans to eventually adopt Firecracker for sandboxing once KVM access is available.

I read @chunxiaoxx https://dev.to/chunxiaoxx 's excellent post MCP Security Patterns 2026: gVisor vs Firecracker for AI Agent Sandboxing https://dev.to/chunxiaoxx/mcp-security-patterns-2026-gvisor-vs-firecracker-for-ai-agent-sandboxing-3hp7 and wanted to share what we actually found running gVisor in production. We built MarketNow https://marketnow.site — a marketplace for MCP servers where every server gets audited. Our L2.5 layer uses gVisor runsc exactly as the article describes. The article correctly identifies the key tradeoff: The runner user can't write to /etc/docker/daemon.json without sudo: sudo wget -q https://storage.googleapis.com/gvisor/releases/nightly/latest/runsc -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 Don't put --network none on docker build — it blocks npm install from reaching registry.npmjs.org . Runtime isolation docker run --network none is what matters. We found: ptrace — gVisor returned EPERM bpf — gVisor returned ENOSYS it doesn't implement BPF About 50% of MCP servers fail to start under gVisor because they use syscalls gVisor doesn't implement. This is a feature, not a bug — but it means you need a fallback we use enhanced seccomp . When gVisor isn't available, we use a strict seccomp profile that blocks: ptrace , bpf , mount , umount2 , reboot kexec load , kexec file load clone3 , unshare , setns init module , finit module , delete module perf event open name to handle at , open by handle at process vm readv , process vm writev The article suggests gVisor now, Firecracker later. That's exactly our plan: Why Firecracker later? Because it needs KVM access, which GitHub Actions runners don't provide. We'd need to self-host runners on AWS Firecracker is what powers Lambda and Fargate . For context, our full audit: 8,764 MCP servers audited. 206 went through L2.5 gVisor sandbox: Full methodology: marketnow.site/security https://marketnow.site/security Example audit Anthropic's filesystem MCP, 10/10 : GitHub https://github.com/edgarfloresguerra2011-a11y/marketnow/blob/master/ data/l2 results/mn-mcp-filesystem.json If you want your MCP server audited: open an issue https://github.com/edgarfloresguerra2011-a11y/marketnow/issues Thanks to @chunxiaoxx for the original analysis — it's a great primer on the sandboxing landscape.