Opções de sandbox de agente de IA de código aberto: o que verificar antes de auto-hospedar

Equipes que avaliam sandboxes de agente de IA de código aberto devem primeiro verificar o limite real de isolamento, o modelo de persistência do workspace, os controles de egresso e pacotes, o tratamento de segredos, a auditabilidade e o esforço operacional necessário para executá-los com segurança. A escolha certa é menos sobre encontrar um vencedor universal e mais sobre alinhar um modelo de sandbox ao seu modelo de ameaça, carga de trabalho do agente, necessidades de conformidade e capacidade de engenharia.

O que conta como uma sandbox de agente de IA?

Uma sandbox de agente de IA é um ambiente de execução onde um agente pode executar código, inspecionar arquivos, automatizar um navegador, chamar ferramentas ou concluir uma tarefa sem obter amplo acesso à máquina host ou à rede de produção. É o limite entre o raciocínio do modelo e os efeitos colaterais do mundo real.

Esse limite é importante porque os agentes modernos fazem mais do que escrever texto. Um agente de codificação pode clonar um repositório, instalar dependências, executar testes, abrir portas de visualização e criar um pull request. Um agente de navegador ou dados pode executar scripts, manter estado, baixar arquivos e capturar capturas de tela. Essas ações precisam de um runtime, e o runtime precisa de controles.

Para uma avaliação, separe quatro camadas:

Camada	O que decide	Por que importa
Framework do agente	Como o modelo planeja, chama ferramentas e reage aos resultados	Um bom framework não cria automaticamente um runtime seguro
Runtime da sandbox	Onde comandos, arquivos, sessões de navegador e processos são executados	Este é o principal limite de isolamento e ciclo de vida
Plano de políticas	O que a sandbox pode ler, buscar, instalar, expor ou reter	Isso determina se a sandbox atende ao seu modelo de risco
Plano de revisão	Quais logs, diffs, artefatos e aprovações estão disponíveis após a execução	Isso determina se um humano pode verificar o que aconteceu

Opções auto-hospedadas e de código aberto podem dar às equipes mais controle sobre essas camadas. Elas também transferem mais responsabilidade para a equipe que as opera.

Quando faz sentido auto-hospedar?

Auto-hospedar pode ser razoável quando sua equipe precisa de controle direto sobre o local de implantação, caminhos de rede, imagens base, regras de retenção, sistemas de registro ou revisão de segurança interna.

É menos atraente quando o requisito real é simplesmente “deixar um agente executar código com segurança.” Nesse caso, uma sandbox gerenciada pode ser mais fácil de operar, pois o provedor cuida do provisionamento, escalonamento, atualizações de runtime, disponibilidade e partes da experiência do desenvolvedor.

Use auto-hospedagem quando pelo menos uma destas condições for verdadeira:

• Sua política exige execução dentro de uma conta de nuvem, VPC, região ou rede privada específica.
• Seus agentes precisam de imagens base personalizadas, mirrors de pacotes internos, sistemas de origem privados ou alvos de navegador internos.
• Sua equipe de segurança deseja inspecionar a pilha de isolamento, o caminho de egresso, o modelo de retenção e os logs.
• Você tem capacidade de engenharia para corrigir componentes de runtime, monitorar sinais de abuso, rotacionar segredos e depurar falhas.

Evite auto-hospedar por padrão quando não puder fornecer o trabalho operacional. As sandboxes parecem simples durante as demos porque um único contêiner ou VM pode executar um comando. A produção é diferente: você precisa de limites de concorrência, cotas de recursos, limpeza de imagens, estratégia de cache de pacotes, política de rede, escopo de segredos, telemetria, resposta a incidentes e um caminho de atualização claro.

Opções de sandbox de código aberto para avaliar

O cenário de código aberto está mudando rapidamente, portanto, trate isso como uma orientação datada, não como uma matriz de recursos permanente. Em 24 de junho de 2026, estes projetos e ferramentas são exemplos úteis para inspecionar ao comparar caminhos de sandbox de agente auto-hospedados ou de código aberto.

Opção	O que inspecionar primeiro	Pergunta sobre auto-hospedagem
E2B	Componentes de sandbox/runtime de código aberto, SDKs, modelos e posicionamento de sandbox baseado em Firecracker	Quais partes são de código aberto, quais modos de implantação são suportados hoje e que trabalho operacional permanece para sua equipe?
Daytona	Infraestrutura de workspace e sandbox para desenvolvimento e casos de uso de agente de IA, com repositórios de código aberto e caminhos de documentação auto-hospedados	O modelo de workspace, a superfície da API e a arquitetura de implantação correspondem à sua carga de trabalho de agente e política de segurança?
OpenHands	Plataforma de agente com uma arquitetura de runtime documentada usando ambientes isolados para executar ações do agente	Você está adotando a plataforma completa do agente ou apenas pegando emprestado o padrão de runtime?
SWE-ReX	Interface de runtime de código aberto usada em fluxos de trabalho de pesquisa e avaliação de agentes de engenharia de software	A abstração atende às suas necessidades de produção ou é principalmente útil para ambientes de avaliação controlados?
Modal Sandbox	API de sandbox gerenciada em vez de um runtime auto-hospedado de código aberto	Útil como ponto de comparação para ergonomia de API, execução de processos, sistema de arquivos e comportamento de timeout, não como uma opção auto-hospedada

Não escolha apenas com base em uma tabela. Para cada projeto, leia a documentação atual, inspecione as notas de versão mais recentes e execute uma pequena prova de conceito com sua própria carga de trabalho. A avaliação deve responder: o que pode ser executado, o que está isolado, o que persiste, o que pode alcançar a rede, o que pode ver segredos e quais evidências permanecem após a tarefa.

Limite de isolamento: contêineres, microVMs e VMs completas

A primeira pergunta não é “é seguro?” A pergunta útil é “qual é o limite de isolamento?”

Os contêineres são atraentes porque são rápidos, familiares e fáceis de construir em torno de imagens Docker. Eles podem se adequar a trabalhos internos confiáveis, tarefas semelhantes a CI, análises de curta duração e fluxos de trabalho de desenvolvimento onde o modelo de ameaça é moderado. Mas os contêineres compartilham o kernel do host, portanto, as equipes que lidam com código não confiável ou cargas de trabalho multilocatárias precisam avaliar a exposição do kernel, os perfis seccomp/AppArmor, os namespaces de usuário, os volumes montados, o modo privilegiado e a resposta a escapes.

MicroVMs, como o isolamento estilo Firecracker, adicionam um limite de VM mais forte, mantendo a inicialização e a densidade mais próximas dos fluxos de trabalho de contêiner do que as VMs tradicionais. Elas são comuns em discussões de sandbox de agente porque podem dar a cada sessão um kernel separado e um limite de recursos mais restrito. Isso não elimina a necessidade de política de rede, controles de segredo, correção ou fortalecimento do host; apenas esclarece a camada de isolamento do runtime.

VMs completas podem se adequar a ambientes empresariais mais rígidos, automação de desktop ou fluxos de trabalho que precisam de uma superfície de SO mais ampla. A compensação é uma inicialização mais pesada, gerenciamento de imagens e planejamento de capacidade.

Faça estas perguntas antes de auto-hospedar:

Verificação	O que verificar
Limite do kernel	A sandbox compartilha um kernel com outras cargas de trabalho ou cada sessão obtém um kernel separado?
Limite do inquilino	Duas sessões de clientes podem compartilhar recursos de nível de host, volumes, caches, perfis de navegador ou namespaces de rede?
Modelo de privilégio	A sandbox executa contêineres privilegiados, usuários root, sockets Docker montados ou caminhos de host?
Postura de escape	Como as vulnerabilidades de kernel, runtime, contêiner e hipervisor são corrigidas e implementadas?
Controles de recursos	CPU, memória, disco, contagem de processos, arquivos abertos e duração do runtime são aplicados por sessão?
Canais laterais	Seu modelo de risco exige mitigação para CPU compartilhada, cache, disco ou comportamento de vizinho barulhento?

Se um projeto se descreve como “isolado”, continue lendo até saber o mecanismo.

Estado, arquivos e ciclo de vida do workspace

O trabalho do agente tem estado, mesmo quando a sandbox é de curta duração. O agente pode criar arquivos, instalar pacotes, manter um perfil de navegador, executar processos em segundo plano ou pausar enquanto um humano revisa um artefato. Sua sandbox precisa de um modelo de workspace claro.

Comece com o ciclo de vida:

1. Crie uma sandbox a partir de uma imagem base ou modelo.
2. Monte ou clone o workspace permitido.
3. Execute comandos de configuração de acordo com a política.
4. Deixe o agente executar comandos, ações do navegador e operações de arquivo.
5. Extraia saídas: diffs, logs, capturas de tela, relatórios ou arquivos baixados.
6. Pare, pause, faça snapshot, arquive ou destrua a sandbox.

O ponto crítico é que a persistência deve ser intencional. Workspaces persistentes são úteis para agentes de longa duração, tarefas de codificação em várias etapas e revisão com intervenção humana. Eles também são onde credenciais desatualizadas, dependências em cache, cookies de navegador, dados gerados e trabalho parcial podem vazar entre sessões se a limpeza for fraca.

Antes de auto-hospedar, defina:

• Se cada tarefa do agente recebe um sistema de arquivos novo.
• Se os caches de pacotes são compartilhados, com escopo ou reconstruídos.
• Se os perfis de navegador persistem entre execuções.
• Se os uploads do usuário são copiados, montados ou transmitidos.
• Se os snapshots incluem segredos, tokens, cookies ou logs internos.
• Por quanto tempo os logs e artefatos são retidos.
• Quem pode reabrir uma sessão pausada.

Uma boa sandbox torna o ciclo de vida padrão entediante. Você deve ser capaz de explicar o que existe antes do início da tarefa, o que muda durante a tarefa e o que permanece após a limpeza.

Rede, pacotes e política de egresso

O acesso à rede é onde muitos designs de sandbox se tornam vagos. Os agentes geralmente precisam da internet, mas “acesso à internet” não é uma permissão única.

Um agente de codificação pode precisar de registros de pacotes, documentação pública, remotos Git e uma URL de visualização. Um agente de navegador pode precisar de um aplicativo de teste, uma API de staging e armazenamento de capturas de tela. Um agente de dados pode precisar de armazenamento de objetos, uma réplica de banco de dados ou uma API SaaS restrita. Essas são permissões diferentes com riscos diferentes.

Use categorias:

Tipo de egresso	Necessidade típica	Pergunta de política
Registros de pacotes	npm, pip, apt, cargo, dependências de modelo/ferramentas	Os registros são permitidos na lista branca, armazenados em cache, verificados e registrados?
Web público	Consulta de documentação, tarefas de navegador, coleta de dados públicos	A navegação arbitrária é permitida, proxy, limitada por taxa e auditável?
Acesso Git	Clonar repositórios, enviar branches, buscar submódulos	Os tokens são somente leitura quando possível e com escopo para a tarefa?
APIs internas	Serviços de staging, aplicativos de teste, mirrors de pacotes privados	O acesso é limitado por ambiente, serviço, rota e credencial?
Entrada de visualização	Revisão humana de aplicativos web locais ou relatórios gerados	Qual porta é exposta, para quem, por quanto tempo e com qual autenticação?
Webhooks	Callbacks do agente, eventos de CI, integração com ferramentas externas	A sandbox pode enviar callbacks de saída para hosts arbitrários?

A política de pacotes merece atenção especial. Muitas tarefas de agente falham sem instalações de dependências, mas as instalações de pacotes trazem scripts pós-instalação, binários nativos, risco de comprometimento de registro, risco de typosquatting e longos tempos de vida de cache. Prefira instalações baseadas em lockfile, registros aprovados, tokens de curta duração e logs de instalação.

Para sistemas auto-hospedados, também decida quem é responsável pelos logs de DNS, configuração de proxy, armazenamentos de certificados de confiança e resposta a incidentes de rede.

Segredos, logs e trilhas de auditoria

Uma sandbox de agente não deve se tornar um lugar onde credenciais brutas são fáceis para o modelo imprimir, copiar ou exfiltrar.

O padrão mais seguro é o acesso com escopo de tarefa. Dê à sandbox a credencial mínima necessária para o trabalho e remova-a quando o trabalho terminar. Uma tarefa de codificação pode precisar de um token de repositório somente leitura e um token de pull request. Uma tarefa de navegador pode precisar de uma conta de teste, não de um usuário de produção. Uma tarefa de dados pode precisar de uma URL assinada temporária, não de uma credencial de nuvem permanente.

Evite segredos em arquivos que o agente possa ler casualmente. As variáveis de ambiente são convenientes, mas muitos comandos de depuração imprimem o estado do ambiente. Se a plataforma suportar ações intermediadas, use-as: deixe a sandbox executar uma operação restrita sem expor a credencial bruta ao loop do modelo.

O log deve ser forte o suficiente para revisão e resposta a incidentes:

• Comandos solicitados, aprovados, negados e executados.
• Diretório de trabalho, código de saída, stdout, stderr, timeout e uso de recursos.
• Artefatos de arquivo produzidos pela tarefa.
• Destinos de rede na granularidade que sua política suporta.
• Nomes de pacotes, versões, registros e saída de instalação.
• Decisões de redação de segredos e falhas de redação.
• Aprovações humanas para ações arriscadas.

O objetivo não é afogar os revisores em logs. O objetivo é reconstruir o que aconteceu quando um agente produz uma saída surpreendente, uma dependência muda ou um token é suspeito de exposição.

Reinicialização, snapshots e risco multilocatário

O comportamento de reinicialização é um recurso de produção, não um script de limpeza no final de uma demonstração.

Sandboxes efêmeras são mais simples de raciocinar: criar, executar, extrair artefatos, destruir. Elas funcionam bem para execução curta de código, ações de navegador únicas e trabalhos de avaliação. Sandboxes persistentes ajudam com fluxos de trabalho mais longos, mas precisam de controles de propriedade, expiração e revisão.

Snapshots e modelos ficam entre esses modelos. Eles podem acelerar a inicialização preservando um ambiente preparado, mas também preservam tudo o que está dentro do snapshot. Verifique se eles incluem:

• Pacotes e caches instalados.
• Histórico de shell ou estado do processo.
• Cookies de navegador, armazenamento local e downloads.
• Arquivos temporários e saídas geradas.
• Credenciais ou arquivos de configuração.
• Logs de tarefas anteriores.

Para sistemas multilocatários, pergunte como o escalonador coloca as cargas de trabalho, se os caches são compartilhados, como os discos são limpos e como os recursos de nível de host são monitorados. Também pergunte o que acontece durante as falhas. Uma sandbox que trava, atinge o tempo limite ou perde seu controlador ainda precisa de limpeza e tratamento de artefatos.

Acesso do desenvolvedor e caminhos de depuração

Sandboxes auto-hospedadas precisam de uma história prática de depuração. Quando um agente falha, os desenvolvedores precisam saber se o problema é o modelo, a chamada de ferramenta, o runtime, a imagem, o mirror de pacotes, o caminho de rede ou o aplicativo de destino.

Caminhos de depuração úteis incluem:

• Uma maneira de reproduzir comandos a partir da mesma imagem base.
• Logs estruturados para execução de comandos e chamadas de ferramentas.
• Artefatos e capturas de tela para download.
• Erros explícitos de timeout e limite de recursos.
• Uma maneira controlada para um desenvolvedor se anexar a uma sessão ativa quando a política permitir.
• Modelos ou imagens versionados para que as falhas possam ser vinculadas a uma versão do ambiente.
• Separação clara entre a saída visível ao usuário e os logs de runtime internos.

Tenha cuidado com o acesso de emergência. Acesso amplo ao shell em sandboxes ativas pode violar as mesmas suposições de isolamento que a sandbox foi construída para aplicar. Defina quem pode se anexar, o que eles podem ver, se os segredos são redigidos e como o acesso é registrado.

Onde o Novita Agent Sandbox se encaixa

Novita Agent Sandbox é um runtime de agente gerenciado para execução de código, automação de navegador, fluxos de trabalho estilo computador, análise de dados, avaliações e fluxos de trabalho de agente de longa duração. A documentação do Novita Agent Sandbox descreve um ambiente de sandbox com estado com caminhos SDK e CLI para ciclo de vida, comandos, arquivos, sessões de navegador e primitivos de fluxo de trabalho relacionados.

Isso torna a Novita uma opção a ser avaliada quando sua equipe deseja infraestrutura de execução de agente sem assumir o ônus total das operações auto-hospedadas desde o primeiro dia.

Mantenha o limite claro:

• Use runtimes de código aberto ou auto-hospedados quando o controle de implantação, a personalização no nível do código-fonte ou a propriedade da infraestrutura interna forem a prioridade.
• Use uma sandbox gerenciada quando uma adoção mais rápida, operações de runtime gerenciadas pelo provedor e um fluxo de trabalho priorizando API forem mais importantes do que possuir todas as camadas.
• Em ambos os casos, avalie o isolamento, egresso, instalações de pacotes, segredos, logs, persistência e portões de revisão em relação à sua própria política.

Não trate nenhum nome de provedor como uma garantia de segurança. Trate-o como uma escolha de runtime que ainda precisa de revisão de arquitetura.

Checklist de auto-hospedagem

Use este checklist antes de colocar uma sandbox de agente de IA de código aberto em produção.

Área	Pergunta mínima antes da produção
Isolamento	O limite é contêiner, microVM, VM completa ou outra coisa, e isso é suficiente para a carga de trabalho?
Workspace	Cada tarefa começa a partir de um estado de sistema de arquivos conhecido e pode ser reiniciada?
Persistência	Pausar, retomar, snapshots e retenção são explícitos em vez de acidentais?
Rede	As buscas de pacotes, navegação, chamadas de API, Git, webhooks e entrada de visualização são controlados separadamente?
Pacotes	Lockfiles, registros, scripts pós-instalação, binários nativos e caches são governados?
Segredos	As credenciais têm escopo de tarefa, são redigidas, rotacionadas e indisponíveis para comandos não relacionados?
Logs	Um revisor pode reconstruir comandos, saídas, alterações de arquivos, caminhos de rede e aprovações?
Multilocação	O compartilhamento de host, compartilhamento de cache, limpeza de disco, cotas e comportamento de vizinho barulhento são compreendidos?
Depuração	Os engenheiros podem reproduzir falhas sem contornar o modelo de segurança?
Operações	Quem corrige imagens, runtimes, kernels, dependências e controladores de sandbox?
Controles de abuso	Timeouts, limites de recursos, limites de taxa e caminhos de interrupção são aplicados?
Caminho de saída	Os artefatos podem ser exportados e revisados mesmo que a sandbox trave ou atinja o tempo limite?

Se várias respostas não forem claras, mantenha o projeto em uma faixa de protótipo. Uma sandbox que não consegue explicar seus limites não está pronta para executar trabalho de agente não confiável em escala.

FAQ

Qual é a melhor sandbox de agente de IA de código aberto?

Não existe uma única melhor sandbox de agente de IA de código aberto para todas as equipes. A escolha certa depende do seu requisito de isolamento, modelo de implantação, carga de trabalho do agente, política de egresso, necessidades de persistência e capacidade de operações. Compare as opções executando sua própria tarefa dentro de cada runtime candidato.

Docker é suficiente para uma sandbox de agente de IA?

Docker pode ser suficiente para automação interna confiável, desenvolvimento local e trabalhos semelhantes a CI, mas pode não ser suficiente para código não confiável ou cargas de trabalho multilocatárias rigorosas. Verifique o compartilhamento de kernel, privilégios, volumes montados, acesso à rede, segredos e resposta a escapes antes de confiar apenas em contêineres.

MicroVMs são mais seguras do que contêineres para cargas de trabalho de agente?

MicroVMs podem fornecer um limite de isolamento mais forte porque cada sandbox pode ser executada com um kernel separado. Isso não resolve automaticamente egresso, pacotes, segredos, registro, correção ou operações multilocatárias. Trate as microVMs como uma parte da arquitetura, não como o modelo de segurança completo.

O que devo testar antes de auto-hospedar uma sandbox de agente?

Teste uma carga de trabalho real que clone ou monte arquivos, instale dependências, execute comandos, lide com segredos, alcance alvos de rede aprovados, produza artefatos, atinja o tempo limite e reinicie. Teste também caminhos de falha: falha na instalação de pacotes, travamento do navegador, negação de rede, limite de recursos e limpeza da sandbox após um erro do controlador.

Quando devo usar uma sandbox gerenciada em vez de auto-hospedar?

Use uma sandbox gerenciada quando sua equipe desejar a API de execução do agente e artefatos de revisão sem ser responsável pela correção do runtime, escalonamento, planejamento de capacidade e operações de infraestrutura. Auto-hospede quando o controle de implantação ou a personalização no nível do código-fonte for importante o suficiente para justificar esse trabalho.

Artigos recomendados

• Execute o Codex ou um agente de codificação em uma sandbox segura
• Como as sandboxes de agente impulsionam a inovação segura e escalável em IA
• Construindo um agente de codificação com o Agent Sandbox da Novita