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

I read @chunxiaoxx's excellent post MCP Security Patterns 2026: gVisor vs Firecracker for AI Agent Sandboxing and wanted to share what we actually found running gVisor in production.

We built MarketNow — a marketplace for MCP servers where every server gets audited. Our L2.5 layer uses gVisor (runsc) exactly as the article describes.

What the article gets right

The article correctly identifies the key tradeoff:

• gVisor: Userspace kernel, intercepts syscalls, ~5-10% overhead
• Firecracker: KVM-level microVM, ~125ms boot, near-zero overhead but needs KVM access

What we learned running gVisor on GitHub Actions

1. gVisor install needs sudo

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

2. Build-time network is needed

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.

3. gVisor catches what seccomp can't predict

We found:

• 1 server attempted ptrace() — gVisor returned EPERM
• 1 server attempted bpf() — gVisor returned ENOSYS (it doesn't implement BPF)
• 0 servers attempted kernel exploits (but gVisor would catch them if they did)

4. gVisor has compatibility issues

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).

5. The fallback (enhanced seccomp) is also valuable

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

Our roadmap (matching the article's recommendation)

The article suggests gVisor now, Firecracker later. That's exactly our plan:

• L2.5 (LIVE): gVisor sandbox
• L3 (Q1 2027): Firecracker microVM

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).

The 6-layer pipeline

For context, our full audit:

• L1.5: Static analysis (deps, secrets, licenses)
• L1.6: Pattern-based behavioral analysis
• L2 v2.0: Active probe (60+ adversarial inputs)
• L2.5: gVisor sandbox ← this post
• L3 (Q1 2027): Firecracker microVM
• L4 (Q4 2026): Supply chain attestation (SLSA Level 3)
• L5 (Q3 2027): Third-party audit (Trail of Bits, Cure53)

Results so far

8,764 MCP servers audited. 206 went through L2.5 gVisor sandbox:

• 69 scored 10/10 (clean)
• 103 scored 0/10 (failed to start — gVisor compatibility)
• 6 scored 2/10 (high risk — critical findings)
• 3 servers removed for leaking environment variables

Try it

Full methodology: marketnow.site/security

Example audit (Anthropic's filesystem MCP, 10/10): GitHub

If you want your MCP server audited: open an issue

Thanks to @chunxiaoxx for the original analysis — it's a great primer on the sandboxing landscape.