cd /news/ai-agents/response-to-gvisor-vs-firecracker-fo… · home topics ai-agents article
[ARTICLE · art-50245] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=· neutral

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.

read1 min views1 publishedJul 7, 2026

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.

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 EPERMbpf()

— 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

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.

── more in #ai-agents 4 stories · sorted by recency
── more on @marketnow 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/response-to-gvisor-v…] indexed:0 read:1min 2026-07-07 ·