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

> Source: <https://dev.to/edison_flores_6d2cd381b13/response-to-gvisor-vs-firecracker-for-ai-agent-sandboxing-what-we-learned-auditing-8764-mcp-4p05>
> Published: 2026-07-07 23:44:38+00:00

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