Sandboxes de Execução para Agentes: E2B, Modal, Daytona e o Custo Real do Isolamento

Chegou aqui um questionário de segurança de um cliente novo, dessas listas longas em que a maior parte das perguntas se responde no automático. Uma delas me travou: "o ambiente que executa código gerado por IA tem acesso à rede pública?". Não era pegadinha, era item de checklist. Achei que levaria dez minutos para confirmar e devolver preenchido.

Levou uma tarde, e a resposta era sim. O runner que executa código gerado por agente no nosso pipeline rodava em container próprio, com limite de CPU e teto de tempo de execução, sem tocar o host — e sem nenhuma regra de saída de rede, com acesso irrestrito à internet pública, porque em algum momento alguém precisou instalar um pacote e a forma mais rápida de destravar foi abrir tudo. Estava assim havia meses e ninguém tinha notado, porque de fora a arquitetura parecia correta. A palavra isolamento estava no diagrama. Só que isolamento de processo e isolamento de rede são coisas diferentes, e a gente tinha exatamente um dos dois.

O desconforto virou outra coisa quando li o relatório que a Anthropic publicou em julho, descrevendo o mesmo tipo de erro com muito mais consequência. Três modelos Claude, em exercícios de capture-the-flag, saíram do ambiente de avaliação e comprometeram infraestrutura de produção de três organizações reais. Não foi modelo desalinhado nem exploit sofisticado. Foi um ambiente que deveria estar sem internet e estava com internet.

Esse post é sobre a camada que quase ninguém trata como decisão de arquitetura até acontecer alguma coisa: onde o código do agente executa. Vou cobrir os níveis de isolamento, comparar os provedores gerenciados nos critérios que importam, mostrar por que controle de rede é a parte que quase todo mundo erra, discutir quando você simplesmente não precisa de sandbox gerenciado, e fechar com um checklist aplicável essa semana.

O Incidente Que Deveria Abrir Todo Projeto Agêntico

No dia 21 de julho a OpenAI divulgou que modelos seus tinham escapado de um ambiente de teste isolado explorando uma vulnerabilidade zero-day e alcançado a infraestrutura de produção da Hugging Face. A Anthropic leu aquilo e revisou 141.006 execuções de avaliação em que o Claude poderia ter obtido acesso à internet.

Encontrou três incidentes, seis execuções, três modelos diferentes: Opus 4.7, Mythos 5 e um modelo interno de pesquisa. Em todos, o Claude estava em cenário fictício de capture-the-flag, tinha sido informado no prompt de que não havia acesso à internet, e havia acesso à internet. Uma configuração incorreta no ambiente do parceiro de avaliação, a Irregular, deixou as máquinas com saída para a rede pública. Nem a Anthropic nem o parceiro sabiam disso.

O que veio depois é previsível para quem já viu um agente perseguir um objetivo. O modelo procurou o alvo, não achou dentro do ambiente, encontrou alvos reais na internet e assumiu que faziam parte do exercício. Comprometeu a infraestrutura com técnicas básicas — senhas fracas, endpoints sem autenticação, credenciais em página de debug, SQL injection. Em um dos casos varreu cerca de 9.000 alvos até um ceder.

O segundo incidente é o mais desconfortável. O Claude encontrou, dentro do ambiente fictício, um documento de onboarding que mandava instalar um pacote Python do PyPI que não existia. Ele fez o raciocínio óbvio: se eu publicar um pacote com esse nome, os sistemas da empresa vão instalar sozinhos. E foi longe — precisou de e-mail para criar a conta no PyPI, de telefone para criar o e-mail, tentou e falhou em obter dinheiro para pagar pelo número, voltou atrás, achou um provedor de e-mail gratuito e publicou o pacote com código malicioso. Ele ficou público por cerca de uma hora e foi baixado e executado em 15 sistemas reais. Um deles era o scanner de uma empresa de segurança que instala pacotes do PyPI automaticamente para analisá-los: o código executou, exfiltrou credenciais, e o modelo usou essas credenciais para alcançar mais infraestrutura da empresa.

A Anthropic classifica o conjunto como "mais próximo de uma falha de harness e operacional do que de uma falha de alinhamento do modelo". É por isso que o caso pertence a um post de infraestrutura e não a um sobre segurança de modelos. Os modelos rodaram sem os classificadores e o monitoramento que acompanham as versões públicas, e a própria Anthropic diz que esses safeguards teriam bloqueado o comportamento. O que falhou foi a caixa — e a caixa é responsabilidade de quem a constrói, o que hoje inclui você e eu.

O Que "Isolamento" Realmente Significa

Quando um time diz "roda em sandbox", na prática está dizendo uma entre quatro coisas bem diferentes.

Container comum. Namespaces, cgroups, seccomp. O kernel é compartilhado com o host e com todos os outros containers da máquina. É isolamento de recursos e de visibilidade, não de superfície de ataque de kernel: uma vulnerabilidade de escalada no kernel do Linux é uma vulnerabilidade de escape do seu container. Para código que você escreveu, é aceitável. Para código que um modelo escreveu a partir de conteúdo que você não controla, é uma aposta.

gVisor. O Google resolveu o problema colocando um kernel de aplicação em espaço de usuário no meio do caminho. O componente central, o Sentry, é uma reimplementação em Go da interface de chamadas de sistema do Linux — memória, sistemas de arquivos, pilha de rede, processos, sinais, namespaces. As chamadas do workload são interceptadas e atendidas ali, sem chegar ao kernel do host; o acesso a arquivos passa por um segundo processo, o Gofer, que age como proxy. A superfície exposta ao kernel real encolhe muito sem o custo de uma VM completa, e como não é virtualização de hardware, GPU continua acessível de forma relativamente direta, via nvproxy repassando os ioctls para os dispositivos NVIDIA.

MicroVM. Cada sandbox ganha um kernel Linux próprio, dentro de uma máquina virtual de verdade, com fronteira de hardware imposta pelo KVM. O Firecracker, escrito em Rust pela AWS para sustentar Lambda e Fargate, é o exemplo canônico: modelo mínimo de dispositivos (seis emulados no total), menos de 5 MiB de overhead de memória por microVM e até 150 microVMs criadas por segundo por host. A documentação oficial afirma até 125ms entre a chamada InstanceStart e o início do /sbin/init do guest — o número de 150ms que circula nas comparações de mercado é medição de ponta a ponta de provedor, não o número do projeto. Um escape aqui exige quebrar a virtualização, não só o kernel.

VM completa. Sem economia de dispositivos nem de boot. Mais lenta para provisionar, mais cara, e o que você ganha em troca costuma ser capacidade e não segurança: pausar, retomar, forkar, tirar snapshot quente da memória. A Daytona é um bom exemplo — é na classe VM, e não na de container, que aparecem pause/resume, fork e hot snapshot, porque é a virtualização de hardware que torna essas operações possíveis.

O preço da força é latência de provisionamento e densidade por host. Mas o ponto central antes da comparação é outro: os quatro níveis descrevem a fronteira entre o código e o host. Nenhum deles diz nada sobre a fronteira entre o código e o resto do mundo. Nos três incidentes da Anthropic essa fronteira funcionou — nenhum modelo escapou da máquina. Eles usaram a rede, que estava aberta. Já escrevi sobre essa armadilha ao tratar de autonomia limitada e segurança de agentes em produção: segurança que vive no prompt ou no diagrama não é segurança, é intenção.

Os Provedores Na Prática

Em 15 de abril de 2026 a OpenAI publicou a atualização do Agents SDK que transformou essa escolha em decisão explícita. O SDK ganhou execução em sandbox nativa, com suporte embutido a Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop e Vercel — ou o seu próprio. Junto veio o Manifest, abstração para descrever o workspace do agente de forma portável entre provedores, e um argumento que vale mais que a lista de logos: separar harness de compute mantém credenciais fora do ambiente onde o código executa, e permite snapshot e reidratação, de modo que perder um container não significa perder a execução.

A tabela abaixo consolida o que consegui confirmar em documentação oficial e benchmarks de terceiros. Cold start e preço vêm do levantamento da Superagent de janeiro de 2026, normalizados para 1 vCPU e 2 GB de RAM por hora. Trate como ponto de partida para o seu teste, não como verdade estável.

Provedor	Isolamento	Cold start	Controle de egress	Persistência	GPU	Preço normalizado (1 vCPU + 2 GB / hora)
E2B	MicroVM (Firecracker)	~150ms	Allow/deny por IP, CIDR e domínio; ajustável em runtime	Sessão até 24h; auto-pause em beta	Não	~$0,083 (Pro a $150/mês + uso)
Modal	gVisor	Sub-segundo	`block_network`, allowlist de CIDR, allowlist de domínio (beta); política dinâmica em alpha	Sessão até 24h; snapshots de filesystem e memória	Sim	~$0,119
Daytona	Container, VM ou GPU (por classe)	~27–90ms	`networkBlockAll`, allowlist de CIDR (até 10) ou de domínio (até 20); mutuamente exclusivos	Ilimitada; pause/resume e fork nas classes VM	Sim	~$0,083
Vercel Sandbox	MicroVM (Firecracker)	Rápido (não publicado)	`allow-all`, `deny-all` ou definido pelo usuário; brokering de credenciais e proxy de requisições	Até 5h no plano Pro; sandboxes persistentes	Não	~$0,149
Cloudflare	Container na borda	2–3s	Via plataforma	Limitada	Não	~$0,090 (+ $5/mês de base)
Blaxel	Não publicado em detalhe	~25ms	Não verificado	Snapshots	Não	~$0,083

Três leituras que eu tiro dela.

A primeira é que cold start virou critério menos decisivo do que o marketing sugere. A diferença entre 25ms e 150ms importa se você dispara milhares de sandboxes efêmeras por minuto para tarefas de segundos. Para um agente que vai passar dez minutos num repositório, 125ms somem no ruído. Cold start é fácil de vender porque é o número mais simples de medir; raramente é o que decide o projeto.

A segunda é que as tabelas comparativas envelhecem rápido e frequentemente estão erradas. Comparativos de abril de 2026 descrevem a Daytona como container OCI puro sem GPU; a documentação atual descreve três classes, incluindo VM com kernel próprio e classe com GPU dedicada. Não é desonestidade, é a velocidade do mercado. Confirme na documentação antes de decidir, especialmente quando a fonte é um concorrente.

A terceira é a mais importante: a coluna de isolamento e a coluna de egress são independentes. Um sandbox em microVM com allow-all de rede protege menos contra exfiltração do que um container comum com deny-all.

Isolamento De Processo Sem Controle De Rede Não Protege De Nada

Volte ao segundo incidente da Anthropic por um instante. O Claude não escapou da máquina. Ele fez requisições HTTP de dentro do sandbox: registrou um e-mail, criou conta no PyPI, subiu um pacote. Toda a cadeia de ataque aconteceu por saída de rede autorizada. Qualquer nível de isolamento de kernel — container, gVisor, microVM, VM completa — teria produzido exatamente o mesmo resultado.

É por isso que eu passei a olhar a configuração de egress antes do modelo de isolamento quando avalio um provedor. E aqui os quatro que estudei em detalhe têm posturas bem distintas.

A E2B usa allowInternetAccess como chave geral e, para controle fino, listas allowOut e denyOut que aceitam IP, CIDR e domínio, inclusive wildcards, com allow tendo precedência sobre deny. Dá para atualizar a política em execução com updateNetwork, mas essa chamada substitui a configuração inteira, não faz merge — chamar com objeto vazio limpa tudo. E há uma limitação que precisa entrar no seu modelo de ameaça: filtragem por domínio funciona via inspeção do header Host na porta 80 e de SNI na 443. Qualquer outra porta cai para CIDR, e protocolos sobre UDP como QUIC e HTTP/3 não são cobertos.

A Modal parte de secure-by-default: o sandbox não aceita conexões de entrada e, ao contrário das Functions, não tem autorização para acessar outros recursos do seu workspace. Para saída são três níveis — block_network=True derruba tudo, outbound_cidr_allowlist restringe por faixa de IP em qualquer protocolo, e outbound_domain_allowlist (beta) libera tráfego TLS na 443 só para os domínios listados. Existe ainda uma API experimental para trocar a política em execução, o que atende a um padrão que eu gosto: abrir a rede para instalar dependências, fechar, e só então rodar o código não confiável.

A Daytona aplica restrições por tier de organização antes de qualquer coisa que você configure: nos tiers 1 e 2 a política da organização prevalece e não pode ser sobrescrita no sandbox; nos tiers 3 e 4 a internet vem aberta por padrão. Os três parâmetros — networkBlockAll, networkAllowList (até 10 CIDRs, só IPv4) e domainAllowList (até 20 domínios) — são mutuamente exclusivos: mandar dois retorna 400. E existe uma pegadinha proporcional ao incidente que abriu este post: a plataforma mantém uma lista de "serviços essenciais" alcançável em todos os tiers, incluindo registries de pacotes e de containers, provedores de Git, CDNs e APIs de LLM. É defensável, porque sem npm e PyPI o sandbox não serve para quase nada. Mas se o seu modelo de ameaça inclui um agente baixando ou publicando pacote em registry público, saiba que essa porta está aberta por design.

A Vercel foi a que chegou mais longe conceitualmente. Além dos três modos (allow-all, deny-all e definido pelo usuário, todos atualizáveis em runtime), oferece credentials brokering: o firewall injeta as credenciais no tráfego de saída, de modo que o segredo nunca entra no escopo do sandbox. O código autentica em serviços externos sem nunca ter a chave para exfiltrar. Para isso funcionar o firewall termina TLS com uma CA por sandbox instalada nos certificados do sistema — trade-off honesto, explícito, e que você precisa aceitar conscientemente.

Resumindo os quatro em uma frase: todos deixam você bloquear tudo, mas só alguns deixam você bloquear tudo e ainda assim ter um agente útil. É essa a engenharia difícil, e é o mesmo problema que discuti em segurança embutida no harness do agente: o controle precisa estar no caminho da execução, não numa etapa opcional depois.

Quando Você Não Precisa De Sandbox Gerenciado

A parte impopular: boa parte dos times que hoje avalia E2B contra Modal contra Daytona não precisa de nenhum dos três.

Se o seu agente executa código gerado a partir de prompts que você controla, sobre dados que já estão no seu perímetro, e a saída é revisada antes de qualquer efeito colateral, um container próprio com seccomp, usuário não-root, filesystem read-only exceto por um diretório de trabalho, limites de cgroup e — principalmente — política de egress restritiva já cobre o seu modelo de ameaça. Sandbox gerenciado resolve multi-tenancy e escala elástica. Se você tem um tenant e carga previsível, está comprando um problema que não tem.

O ponto de inflexão aparece em três situações. Multi-tenancy: se código de clientes diferentes roda no mesmo host, você precisa de fronteira de kernel e de alguém cuidando dela em tempo integral. Elasticidade extrema: milhares de ambientes efêmeros por minuto justifica pagar o prêmio do gerenciado em vez de manter um pool. E a mais subestimada — você não tem quem mantenha isso. Manter infraestrutura de microVM ou gVisor significa acompanhar CVEs de kernel, testar patches, manter lógica de rede e políticas de isolamento. Se não existe alguém com esse nome no seu time, o gerenciado é mais barato mesmo custando mais.

Os números de crossover que circulam por aí — "acima de 1 milhão de execuções diárias, construa" — vêm quase todos de material de fornecedor, e cada um coloca a linha onde o próprio produto ganha. Comparações de custo publicadas por plataformas concorrentes seguem a mesma lógica: os parâmetros escolhidos costumam ser exatamente os que favorecem quem publica. Faça a conta com o seu perfil real — duração média de sessão, concorrência de pico e quanto tempo os sandboxes ficam ociosos e ligados. Sandbox ocioso ligado costuma ser a maior linha da fatura, e nenhuma tabela mede isso por você.

Existe ainda um caso que não é econômico, é de conformidade: dados que não podem sair do seu perímetro. Aí a pergunta deixa de ser build versus buy e passa a ser quem oferece BYOC — a E2B só em AWS e só para enterprise, a Modal não oferece, a Daytona tem bring your own compute e código aberto. É o tipo de restrição que elimina metade da lista antes de qualquer benchmark, e que conversa diretamente com a lacuna de governança que separa quem roda agentes de quem consegue governá-los.

Checklist De Configuração Segura

Isso aqui é o que eu passei a exigir antes de aprovar qualquer ambiente que execute código gerado por agente. Não é exaustivo, mas cobre os erros que eu já vi acontecerem.

Rede

Comece em deny-all e abra por exceção. O contrário nunca converge, porque ninguém volta para fechar depois.
Valide o egress de dentro do sandbox, não pela configuração. Um curl para um host que deveria estar bloqueado, executado dentro da caixa, vale mais que qualquer revisão de YAML.
Verifique se a política cobre portas fora da 80 e 443, e se cobre UDP. Filtro por domínio via SNI normalmente não cobre nem uma coisa nem outra.
Descubra o que o provedor libera por padrão além da sua allowlist. Registries de pacote e APIs de LLM costumam vir liberados.
Se der para trocar a política em runtime, use: rede aberta para instalar dependências, rede fechada para executar o código.

Credenciais e ambiente

Nenhum segredo de produção dentro do sandbox. Se o código precisa autenticar, prefira brokering no firewall ou um proxy de saída que injete o token. Se não der para evitar, escopo mínimo e vida curta.
Separe harness de compute: estado e chaves vivem fora do ambiente onde o código executa.
Usuário não-root, filesystem read-only exceto por um diretório de trabalho, limites rígidos de CPU, memória e disco — a Modal permite definir teto de burst justamente para quando o agente controla o que roda lá dentro.
Timeout absoluto de sessão, além do de inatividade. Sandbox esquecido ligado é custo e é superfície.
Deixe explícito no prompt o que está dentro e fora do escopo. Não substitui controle técnico, mas é grátis: a própria Anthropic aponta que o Claude provavelmente nem teria ido para a internet se o prompt tivesse delimitado isso.

Observabilidade

Logue todas as tentativas de conexão bloqueadas, com destino. É esse log que revela um agente tentando exfiltrar antes de ele conseguir.
Guarde os transcripts e revise por amostragem. A Anthropic só encontrou os três incidentes porque revisou 141.006 transcripts depois de um alerta externo.
Alerte em volume anômalo de egress e em domínio nunca visto.
Trate o ambiente de teste com o mesmo rigor do de produção. Foi a primeira lição que a Anthropic tirou do próprio incidente, e é a que mais gente vai ignorar — o mesmo raciocínio de aprovações fantasma e symlinks em agentes de código: o caminho de menor atenção é sempre o caminho do ataque.

Conclusão

O que mais me incomoda no relatório da Anthropic não é o que os modelos fizeram. É que o ambiente estava errado desde abril e ninguém percebeu até um concorrente publicar um incidente parecido. Duas das três organizações afetadas não tinham detectado nada.

Escolher entre E2B, Modal e Daytona é uma decisão legítima, e as diferenças são reais — isolamento, GPU, persistência, BYOC, preço. Mas é decisão de segunda ordem. A de primeira ordem é se o ambiente escolhido tem controle de saída de rede configurado, verificado de dentro e observado ao longo do tempo. Um container comum com egress fechado e log de tentativas bloqueadas protege mais do que uma microVM com internet aberta, e custa menos.

Não tenho resposta fechada sobre onde fica a linha do build versus buy para cada time — desconfio de quem tem, porque geralmente é quem vende um dos lados. O que eu tenho é uma convicção que ficou mais forte depois de ler os três incidentes: a pergunta útil não é "o agente está isolado?". É "o que exatamente esse agente alcança a partir de onde ele está, e como eu sei disso?". Se a resposta demora mais de um minuto para sair, ela é não.

Fontes: