Resposta a 'gVisor vs Firecracker para Sandboxing de Agentes de IA' — o que aprendemos auditando 8.764 servidores MCP

Li o excelente post de @chunxiaoxx Padrões de Segurança MCP 2026: gVisor vs Firecracker para Sandboxing de Agentes de IA e queria compartilhar o que realmente encontramos ao rodar o gVisor em produção.

Construímos MarketNow — um marketplace para servidores MCP onde cada servidor é auditado. Nossa camada L2.5 usa gVisor (runsc) exatamente como o artigo descreve.

O que o artigo acerta

O artigo identifica corretamente a principal troca:

gVisor: Kernel em espaço de usuário, intercepta chamadas de sistema, ~5-10% de sobrecarga
Firecracker: MicroVM a nível KVM, ~125ms de inicialização, sobrecarga quase zero, mas precisa de acesso KVM

O que aprendemos rodando gVisor no GitHub Actions

1. A instalação do gVisor precisa de sudo

O usuário do runner não pode escrever em /etc/docker/daemon.json sem 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. Rede em tempo de construção é necessária

Não coloque --network none no docker build — isso bloqueia npm install de alcançar registry.npmjs.org. A isolação em tempo de execução (docker run --network none) é o que importa.

3. gVisor captura o que o seccomp não pode prever

Encontramos:

1 servidor tentou ptrace() — gVisor retornou EPERM
1 servidor tentou bpf() — gVisor retornou ENOSYS (não implementa BPF)
0 servidores tentaram exploits de kernel (mas gVisor os capturaria se o fizessem)

4. gVisor tem problemas de compatibilidade

Cerca de 50% dos servidores MCP falham ao iniciar sob gVisor porque usam chamadas de sistema que o gVisor não implementa. Isso é uma característica, não um bug — mas significa que você precisa de uma alternativa (usamos seccomp aprimorado).

5. A alternativa (seccomp aprimorado) também é valiosa

Quando o gVisor não está disponível, usamos um perfil seccomp rigoroso que bloqueia:

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

Nosso roadmap (correspondendo à recomendação do artigo)

O artigo sugere gVisor agora, Firecracker depois. Esse é exatamente o nosso plano:

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

Por que Firecracker depois? Porque precisa de acesso KVM, que os runners do GitHub Actions não fornecem. Precisaríamos auto-hospedar runners na AWS (Firecracker é o que alimenta Lambda e Fargate).

O pipeline de 6 camadas

Para contexto, nossa auditoria completa:

L1.5: Análise estática (dependências, segredos, licenças)
L1.6: Análise comportamental baseada em padrões
L2 v2.0: Prova ativa (60+ entradas adversariais)
L2.5: sandbox gVisor ← este post
L3 (Q1 2027): microVM Firecracker
L4 (Q4 2026): Atestação da cadeia de suprimentos (SLSA Nível 3)
L5 (Q3 2027): Auditoria de terceiros (Trail of Bits, Cure53)

Resultados até agora

8.764 servidores MCP auditados. 206 passaram pela sandbox gVisor L2.5:

69 pontuaram 10/10 (limpos)
103 pontuaram 0/10 (falharam ao iniciar — compatibilidade com gVisor)
6 pontuaram 2/10 (alto risco — descobertas críticas)
3 servidores removidos por vazamento de variáveis de ambiente

Experimente

Metodologia completa: marketnow.site/security

Exemplo de auditoria (sistema de arquivos MCP da Anthropic, 10/10): GitHub

Se você quiser que seu servidor MCP seja auditado: abra uma issue

Agradecimentos a @chunxiaoxx pela análise original — é uma ótima introdução ao cenário de sandboxing.