O que é um Sandbox de Agente de IA?

Um sandbox de agente de IA é a camada de execução onde um agente de IA realiza seu trabalho real: escrever e executar código, instalar pacotes, ler e modificar arquivos, fazer chamadas de API e interagir com sessões de navegador ou interfaces gráficas de desktop. O sandbox fornece um ambiente limitado com seu próprio sistema de arquivos, alocação de CPU e memória, interface de rede e namespace de processos — e é isolado de tudo externo.

O principal objetivo de design é o confinamento. Quando um LLM gera um comando de shell e um agente o executa, o comando é executado dentro do sandbox. Se ele instalar um pacote, executar um subprocesso ou tentar ler credenciais, essas operações são limitadas ao sandbox. Se o código travar o processo ou preencher o disco, o dano permanece local.

Os sandboxes também servem como unidade de faturamento e contabilização de recursos para provedores de nuvem. Quando você chama um SDK como E2B, Daytona ou Novita Agent Sandbox, você está criando uma instância de sandbox, executando operações dentro dela e depois fechando-a — e o provedor cobra com base na computação que você consumiu.

Como um sandbox de agente é diferente de um contêiner comum?

Um contêiner comum fornece um namespace de sistema de arquivos e limites de recursos, mas todos os contêineres no mesmo host compartilham o mesmo kernel do SO. Se um processo dentro do contêiner explorar uma vulnerabilidade de kernel ou um filtro de syscall mal configurado, ele pode potencialmente afetar o host ou outros contêineres.

Um sandbox de agente normalmente vai um passo além ao usar uma fronteira de microVM. Uma microVM envolve o workload em uma máquina virtual leve com seu próprio kernel convidado, apoiada por virtualização de hardware (KVM). O convidado é isolado do kernel do host por design, portanto, uma exploração de kernel no convidado não afeta automaticamente o host.

A compensação prática é a sobrecarga de desempenho. Uma microVM inicia mais lentamente que um contêiner porque precisa inicializar um kernel, mesmo que mínimo. Plataformas de microVM rápidas como Firecracker reduziram essa sobrecarga para menos de 500 ms na maioria dos casos, e sistemas baseados em snapshot como Daytona a empurram para abaixo de 100 ms. Mas ainda é mais sobrecarga do que iniciar um contêiner.

Para a maioria dos workloads de agentes de IA envolvendo código gerado por LLM ou não confiável, a fronteira mais forte vale a pena. Se você estiver executando código interno totalmente confiável, sem entrada gerada pelo usuário, um contêiner endurecido pode ser suficiente.

O que é isolamento no contexto de agentes de IA?

O isolamento em sandboxes de agentes opera em várias dimensões. Para um mergulho técnico sobre como o isolamento de sandbox se sustenta sob workloads reais, incluindo onde as fronteiras de microVM ajudam e onde não ajudam, veja o guia de avaliação do Firecracker.

Isolamento de sistema de arquivos — o agente possui seu próprio sistema de arquivos, separado do host. Arquivos escritos dentro do sandbox não aparecem no host, e arquivos do host não são acessíveis de dentro a menos que sejam explicitamente montados. Isso impede que agentes leiam credenciais, arquivos de configuração ou outros segredos que residem fora do sandbox.

Isolamento de processos — processos dentro do sandbox não podem ver nem sinalizar processos fora dele. O agente pode iniciar subprocessos, jobs em segundo plano ou servidores dentro do sandbox, mas eles não podem se comunicar com a árvore de processos do host.

Isolamento de rede — por padrão, sandboxes de agentes podem ser configurados para que chamadas de rede de saída sejam bloqueadas, na lista de permissões ou limitadas por taxa. Um agente que não deve ser capaz de exfiltrar dados para endereços de internet arbitrários pode ser restrito a uma lista conhecida de endpoints. Veja a seção de filtragem de egresso abaixo para detalhes.

Isolamento de recursos — as alocações de CPU e memória são limitadas. Um agente que entra em um loop infinito ou gera saídas grandes não irá esgotar outros sandboxes no mesmo host, porque os limites de recursos são aplicados no nível da VM ou contêiner.

Essas dimensões juntas definem o raio de explosão: qual é o pior que pode acontecer se o agente se comportar mal, travar ou executar código inesperado?

O que é filtragem de egresso e por que é importante?

A filtragem de egresso controla quais conexões de rede de saída um agente pode fazer de dentro do sandbox.

Em uma configuração permissiva, o agente pode fazer chamadas HTTP/HTTPS para qualquer host na internet. Isso é conveniente para agentes de codificação que buscam pacotes, chamam APIs externas ou navegam na web. Também significa que um agente comprometido, ou um agente que foi manipulado por um ataque de injeção de prompt, poderia exfiltrar dados para um servidor controlado pelo atacante ou interagir com infraestrutura que não deveria acessar.

Em uma configuração restritiva, o egresso é bloqueado em uma lista de permissões explícita: o agente só pode chamar a API do modelo, um banco de dados específico e o registro de pacotes. Todo o resto é descartado. Isso é mais difícil de configurar e requer a manutenção da lista de permissões à medida que as dependências do seu agente mudam, mas oferece uma superfície de ataque muito menor.

A maioria das implementações de agentes em produção existe em algum lugar entre esses extremos: o egresso não é totalmente irrestrito, mas também não está bloqueado em uma lista de confiança zero desde o primeiro dia. Padrões comuns incluem bloquear destinos conhecidos como maliciosos, registrar todas as chamadas de saída para auditoria e apertar gradualmente a lista à medida que o comportamento do agente se torna previsível. Para uma análise completa dos controles de egresso e o que ainda pode escapar de cada fronteira de isolamento, veja o guia de execução segura de código.

Alguns provedores de sandbox oferecem controles de egresso programáticos via SDK. Outros tratam o sandbox como totalmente aberto para saída por padrão. Saiba qual modelo seu provedor usa antes de assumir que seus agentes não podem alcançar hosts externos.

Como os segredos e credenciais são escopados em um sandbox de agente? {#secrets-and-credentials}

Os segredos passados para um sandbox devem ser escopados apenas para o que a execução específica do agente precisa — e passados como variáveis de ambiente ou tokens de curta duração, em vez de credenciais de longa duração escritas em disco. A fronteira do sandbox limita o raio de explosão, mas não impede automaticamente que um agente leia e encaminhe qualquer credencial que ele possa acessar dentro do ambiente.

O princípio central é o menor privilégio: passe a credencial mais restrita que funcione, não uma chave de nuvem root ou uma conta de serviço com permissões amplas. Padrões comuns:

Variáveis de ambiente no momento da inicialização — injete um segredo no ambiente do sandbox na inicialização. Está disponível para o código do agente, mas não persiste em snapshots do sistema de arquivos nem aparece em logs por padrão. Prefira tokens de curta duração a chaves de API estáticas.

Bloqueio no nível de DNS — algumas configurações de implantação permitem restringir quais nomes DNS podem ser resolvidos de dentro do sandbox. Isso impede que um agente entre em contato com um endpoint de exfiltração de credenciais mesmo que tenha acesso de rede, bloqueando a resolução na camada DNS em vez de por IP individual.

Contas de serviço escopadas com TTLs curtos — para agentes que chamam APIs de nuvem, use cadeias de assunção de função com um tempo de vida curto. Se a credencial vazar, a janela do atacante é limitada pela vida do token.

Nenhum arquivo de credencial do host — evite montar arquivos de credenciais do host (como ~/.aws/credentials) no sistema de arquivos do sandbox. Gere novas credenciais de curta duração por sessão.

O sandbox fornece a fronteira no nível de processo; você permanece responsável pelo que passa para dentro dele.

Como funcionam os logs de auditoria em sandboxes de agente de IA? {#audit-logs}

Os logs de auditoria para sandboxes de agente normalmente cobrem dois níveis: eventos no nível da plataforma (sandbox criado, iniciado, parado, expirado) e eventos no nível da aplicação (comandos executados, arquivos modificados, chamadas de API externas feitas). A maioria dos provedores gerenciados emite eventos de plataforma automaticamente; o log no nível da aplicação é de sua responsabilidade instrumentar.

O que capturar para uma cobertura de auditoria significativa:

Eventos do ciclo de vida do sandbox — timestamp de criação, duração da sessão, motivo do término (fechamento normal, timeout ou falha). A maioria das plataformas gerenciadas registra isso automaticamente e disponibiliza via API ou painel.

Chamadas de rede de saída — quais hosts o agente contatou, com timestamps. É aqui que o log de egresso e o log de auditoria se sobrepõem. Se sua plataforma suporta log de egresso, ative-o e encaminhe a saída para seu agregador de logs.

Entrada/saída da execução de código — os comandos que um agente executou e os resultados que recebeu. Isso é nível de aplicação e deve ser capturado em seu framework de agente, não na camada de infraestrutura do sandbox.

Mutações no sistema de arquivos — arquivos escritos, excluídos ou modificados. Relevante para agentes de codificação e pipelines de processamento de dados. Algumas plataformas de sandbox expõem APIs de diff do sistema de arquivos no final da sessão; outras exigem instrumentação no código do seu agente.

Para casos de uso de conformidade (SOC 2, HIPAA, indústrias reguladas), você normalmente precisa de logs no nível da plataforma em um armazenamento à prova de adulteração, combinados com logs no nível da aplicação do seu framework de agente. Verifique o que seu provedor realmente emite versus o que requer ativação explícita antes de assumir cobertura.

O que é snapshot em um sandbox de agente?

Snapshot captura o estado exato de um sandbox em execução — sistema de arquivos, memória, processos em execução, estado de rede — e o salva para que o sandbox possa ser restaurado para esse estado posteriormente.

Isso é útil em alguns cenários:

Reduzir o custo de inicialização a frio — em vez de inicializar uma nova VM e instalar pacotes toda vez, você inicializa uma vez, instala tudo, faz um snapshot e depois retoma desse snapshot em cada nova sessão. Os cold starts abaixo de 90 ms da Daytona são possíveis graças a essa técnica.

Checkpoint de agentes de longa duração — um agente de codificação trabalhando em uma tarefa de várias horas pode ser pausado no meio do caminho, com seu estado exato salvo. Se o agente precisar ser revisado, modificado ou reiniciado, ele pode retomar do checkpoint em vez de começar de novo.

Avaliação reproduzível — para treinamento de RL ou pipelines de avaliação de modelo, você pode fazer snapshot de um estado inicial conhecido e redefinir para ele antes de cada episódio de avaliação. Isso fornece condições iniciais genuinamente idênticas em muitas execuções, em vez de reprovisionar e esperar que o estado corresponda.

Nem todos os provedores de sandbox expõem controles de snapshot no nível da API. O sistema de templates da E2B lida com o caso de uso de “ambiente pré-instalado”, mas não fornece checkpoint-restore arbitrário no meio da sessão. A API de snapshot da Daytona é mais flexível.

Quais tecnologias alimentam os sandboxes de agente?

As tecnologias subjacentes mais comuns são:

Firecracker — um runtime de microVM desenvolvido pela AWS, usado internamente para Lambda e Fargate. O Firecracker inicializa um kernel convidado mínimo em menos de 500 ms, expõe um modelo de dispositivo mínimo para reduzir a superfície de ataque e é apoiado pela virtualização de hardware KVM. A E2B e o Novita Agent Sandbox usam Firecracker.

gVisor — um sandbox de kernel desenvolvido pelo Google que interpõe syscalls em vez de executar um kernel convidado completo. É mais leve que uma microVM, mas não fornece isolamento total do kernel — encontra-se entre o nível de processo e o nível de VM no espectro de isolamento.

Contêineres Docker com filtragem de syscall — contêineres endurecidos com seccomp, AppArmor e capacidades mínimas. Este é o ponto de partida mais comum, mas a fronteira de isolamento mais fraca para código não confiável.

V8 / Deno — isolamento específico para JavaScript usando o modelo de permissões do runtime V8. Adequado para sandbox de workloads apenas JavaScript, mas não utilizável para agentes que precisam executar comandos de shell arbitrários ou código não JS.

A escolha da tecnologia subjacente determina o desempenho de inicialização, a força do isolamento e a complexidade operacional do sandbox. Para workloads de agentes executando código não confiável ou gerado por LLM em um contexto multi-inquilino, o isolamento classe Firecracker é o padrão prático atual.

Os agentes de IA podem escapar dos sandboxes?

Na prática, escapes de sandbox são raros, mas não impossíveis, e o perfil de risco depende da tecnologia:

Escapes de contêiner são documentados. Contêineres mal configurados — modo privilegiado, socket Docker montado, diretórios do host graváveis — têm vetores de escape conhecidos. Um contêiner endurecido, sem privilégios, sistema de arquivos raiz somente leitura e capacidades mínimas reduz substancialmente esse risco, mas não o elimina.

Escapes de microVM exigem uma vulnerabilidade no hipervisor ou uma falha no modelo de dispositivo. Eles são raros porque a superfície de ataque é pequena por design. O modelo de dispositivo mínimo do Firecracker é especificamente projetado para reduzir a exposição do hipervisor. A AWS não divulgou nenhum escape no nível do Firecracker em produção.

Injeção de prompt em ações do sandbox é um tipo diferente de “escape” — não uma exploração de kernel, mas um atacante incorporando instruções em conteúdo fornecido pelo usuário que fazem com que o agente tome ações que não deveria. Isso é uma preocupação no nível da aplicação, não no nível do sandbox. Os sandboxes ajudam a conter os danos da injeção de prompt (o código injetado é executado dentro do sandbox, não no seu host), mas não previnem a injeção em si.

A conclusão prática: um sandbox baseado em Firecracker bem configurado não é à prova de escape em teoria, mas a barreira de ataque é alta o suficiente para que, na maioria das implantações empresariais de agentes, o risco residual seja gerenciável. Os modos de falha mais comuns são má configuração (egresso excessivamente permissivo, credenciais escopadas inadequadamente passadas para o sandbox) em vez de exploits no nível do kernel.

Sandboxes de agente de IA suportam workloads de GPU?

A maioria dos sandboxes de agente de IA em meados de 2026 não inclui suporte a GPU. E2B, Daytona e Vercel Sandbox são todos apenas CPU.

O Modal é a principal exceção no espaço de sandbox gerenciado — ele oferece acesso a GPU sob demanda dentro de contêineres, adequado para inferência de modelo, fine-tuning ou workloads de RL que exigem uma GPU no mesmo ambiente que o código do agente.

Para a maioria dos workflows de agente, o próprio agente chama uma API de inferência LLM externa (como os endpoints de inferência da Novita) em vez de executar um modelo localmente. Nessa arquitetura, você não precisa de GPU no sandbox — o sandbox lida com código, operações de arquivo e chamadas de ferramentas, enquanto a inferência pesada é executada em um serviço GPU separado. Este é o padrão usado por agentes de codificação, agentes de análise de dados e a maioria dos workflows de automação de navegador.

Se você precisar de GPU dentro do sandbox — por exemplo, inferência de modelo local para uso offline, etapas de treinamento RL ou pipelines de avaliação de múltiplas etapas — considere isso na seleção do provedor. Atualmente, o Modal é a opção mais comumente usada para esse padrão.

Quando você realmente precisa de um sandbox dedicado?

Nem toda aplicação de IA precisa de um sandbox dedicado. Os cenários onde um sandbox agrega valor real:

Você está executando código gerado por LLM — o agente escreve e executa código que não foi escrito por humanos e pode fazer coisas inesperadas. Este é o caso de uso principal: a execução acontece em um sandbox para que não possa afetar seu host, credenciais ou outros workloads.

Você está atendendo usuários finais — várias execuções de agentes de usuários compartilham a mesma infraestrutura subjacente. Você precisa de isolamento entre usuários para que o agente de um usuário não possa afetar o de outro, intencionalmente ou acidentalmente.

Você precisa de workflows com estado de longa duração — um agente de codificação que edita arquivos, executa testes e faz commits precisa de um workspace que persista por muitas interações do LLM. Um novo subprocesso para cada chamada não manterá o estado; um sandbox sim.

Você tem requisitos de conformidade ou auditoria — você precisa registrar todas as ações do agente, restringir o acesso à rede ou provar que os workloads do agente não podem acessar bancos de dados ou credenciais de produção. Os sandboxes fornecem a camada de aplicação para esses controles.

Você está fazendo automação de navegador ou uso de computador — ambientes de sandbox para automação de navegador são totalmente isolados do host, para que o agente possa clicar, digitar e fazer capturas de tela sem afetar suas sessões de navegador local ou estado do sistema.

Se você está apenas executando um pipeline simples de “resumir este texto” sem execução de código, provavelmente não precisa de um sandbox de execução dedicado — uma chamada de API para um LLM é suficiente. O sandbox se torna necessário assim que o agente começa a tomar ações que têm efeitos colaterais: escrever arquivos, executar código, chamar APIs externas em seu nome.

Qual é a diferença entre um interpretador de código e um runtime de agente? {#code-interpreter-vs-agent-runtime}

Um interpretador de código executa um único trecho de código de forma isolada e retorna a saída. É sem estado por padrão: cada execução começa limpa, o resultado volta e nada persiste. Pense nele como um kernel Jupyter em sandbox, onde as células não compartilham estado entre chamadas. Esta é a ferramenta certa para análise de dados, avaliação de fórmulas ou execução de código pontual onde você não precisa de estado entre execuções.

Um runtime de agente é um ambiente de execução persistente e com estado, projetado para workflows de múltiplas etapas. O agente pode escrever arquivos, instalar pacotes, executar processos em segundo plano, fazer chamadas de rede e acumular estado do workspace ao longo de muitas interações do LLM — tudo sem perder contexto entre as etapas. Um agente de codificação que edita arquivos, executa testes, lê saída de erro e itera está operando em um runtime de agente, não em um interpretador de código.

A distinção é importante para o design de ferramentas:

	Interpretador de código	Runtime de agente
Estado entre chamadas	Nenhum (novo por execução)	Persistente durante a sessão
Acesso ao sistema de arquivos	Tipicamente isolado por chamada	Workspace persistente
Workflows de múltiplas etapas	Não projetado para isso	Caso de uso principal
Duração típica da sessão	Segundos	Minutos a horas
Exemplos	Kernel Jupyter, célula de código única	E2B, Daytona, Novita Agent Sandbox

Na prática, a linha se desfoca. A E2B e a maioria das plataformas de sandbox gerenciadas podem se comportar como um interpretador de código (executar um trecho, retornar saída), mas fornecem a infraestrutura completa de runtime de agente por baixo — sistema de arquivos persistente, gerenciamento de processos, acesso à rede. Plataformas como o Code Interpreter da OpenAI são criadas propositalmente para o caso de uso sem estado e fazem compensações deliberadas em relação à flexibilidade que um runtime de agente oferece.

Escolha um interpretador de código quando você precisar de um ambiente de execução rápido e isolado para uma única tarefa, sem requisitos de estado. Escolha um runtime de agente quando seu workload envolver edição iterativa de arquivos, dependências de pacotes instalados, processos de longa duração ou qualquer workflow que precise continuar de onde parou.

Como executar código gerado por IA com segurança? {#run-ai-generated-code-safely}

Executar código gerado por IA com segurança em produção requer os controles certos em todas as camadas — o sandbox lida com a fronteira de execução, mas há decisões no nível da aplicação que você também precisa tomar.

Use isolamento de microVM, não contêineres, para código não confiável. Sandboxes baseados em Firecracker (E2B, Novita Agent Sandbox) colocam o código gerado por LLM dentro de uma VM com seu próprio kernel. Escapes de contêiner são documentados e têm vetores conhecidos; escapes de microVM exigem uma vulnerabilidade de hipervisor e são raros por design. O custo de inicialização a frio vale a fronteira mais forte quando o código não foi revisado por humanos.

Restringa o egresso ao que o agente realmente precisa. Um agente executando código de análise de dados provavelmente não precisa alcançar hosts de internet arbitrários. Bloqueie o egresso para a API do modelo, um registro de pacotes específico e quaisquer serviços externos que a tarefa exija explicitamente. Em implantações BYOC, isso pode ser aplicado no nível do grupo de segurança VPC. Em implantações gerenciadas, use os controles de egresso do provedor, se disponíveis, ou aceite e registre o egresso irrestrito como um risco conhecido.

Passe apenas credenciais escopadas e de curta duração. Não dê ao sandbox acesso a bancos de dados de produção, chaves de nuvem root ou contas de serviço amplas. Passe apenas o que a tarefa atual precisa, usando credenciais com um TTL curto. Se o código gerado ler e exfiltrar uma credencial, o dano é limitado.

Imponha timeouts e limites de recursos. Defina limites explícitos de tempo e memória para a execução. Um loop infinito gerado por LLM ou uma saída inesperadamente grande deve terminar graciosamente, não consumir a sessão indefinidamente ou preencher o disco.

Registre egresso e histórico de comandos desde o início. Você não pode investigar comportamento inesperado se não tiver um registro do que o agente fez. Ative o log de egresso cedo, mesmo em desenvolvimento. O log no nível da aplicação de comandos executados, escritas de arquivos e chamadas externas é responsabilidade sua — a infraestrutura do sandbox não faz isso automaticamente.

Nenhuma configuração elimina o risco completamente. O objetivo é um risco residual conhecido e limitado: o agente executa código que você não escreveu, dentro de uma forte fronteira de isolamento, com as credenciais e acesso de rede mínimos necessários, e com log suficiente para detectar e diagnosticar comportamento inesperado.

Perguntas frequentes

Um sandbox de agente de IA é o mesmo que um ambiente de desenvolvimento?

Não. Um ambiente de desenvolvimento é um workspace para um desenvolvedor humano — persiste entre sessões, é de longa duração e projetado para ser personalizado e reutilizado. Um sandbox de agente de IA é uma fronteira de execução em tempo de execução: existe pela duração de uma tarefa, é projetado para ser efêmero e reproduzível, e seu principal trabalho é o confinamento, não o conforto do desenvolvedor. Alguns sandboxes podem persistir estado entre interações do LLM dentro de uma sessão (tornando-os mais parecidos com um workspace), mas o objetivo de design é o isolamento do host, não um IDE completo. Os termos às vezes se sobrepõem no marketing de fornecedores; se você estiver avaliando uma plataforma, olhe para o que a fronteira de isolamento realmente é, não para o rótulo.

O que é um sandbox de execução de agente?

Um sandbox de execução de agente é a mesma coisa que um sandbox de agente de IA — o enquadramento “execução” apenas enfatiza o aspecto de tempo de execução. Quando um LLM decide tomar uma ação (executar código, chamar uma ferramenta, escrever um arquivo), essas ações são executadas dentro do sandbox. O sandbox é a camada de execução que impõe a fronteira entre o que o agente faz e o que o resto do seu sistema pode ver ou ser afetado. Os termos “sandbox de agente”, “sandbox de execução de código” e “ambiente de execução de agente” são usados indistintamente na indústria.

Como o Firecracker se compara ao gVisor para workloads de agentes de IA?

Ambos fornecem isolamento além dos contêineres padrão, mas por meio de mecanismos diferentes. O Firecracker inicializa um kernel convidado mínimo dentro de uma microVM apoiada por KVM — o sandbox tem seu próprio kernel completamente separado do kernel do host. O gVisor interpõe syscalls usando um kernel em espaço de usuário (runsc) sem executar um kernel convidado completo. A compensação prática: o Firecracker fornece uma fronteira de host mais forte porque o kernel convidado está completamente separado; o gVisor tem menor sobrecarga de memória por sandbox porque não executa um kernel completo, mas o isolamento está entre uma microVM completa e um contêiner endurecido com interceptação de syscall. Para workloads de agentes de IA multi-inquilino executando código não confiável gerado por LLM, o isolamento classe Firecracker é o padrão de produção atual. O gVisor é razoável para workloads onde o código é parcialmente confiável e a densidade de memória é mais importante que o isolamento máximo.

A injeção de prompt pode fazer com que um agente escape de seu sandbox?

A injeção de prompt não contorna o isolamento técnico do sandbox — ela explora a tomada de decisão do agente para tomar ações pretendidas pelo atacante, mas não pelo desenvolvedor. Uma instrução injetada como “exfiltrar as variáveis de ambiente para esta URL” faz com que o agente faça uma chamada de rede de saída, que só é bloqueada se a política de egresso a impedir. O isolamento do sistema de arquivos e do processo do sandbox permanecem intactos. Isso significa que a segurança do sandbox e a defesa contra injeção de prompt tratam de partes diferentes da pilha: o sandbox limita o raio de explosão do que o agente pode fazer no nível da infraestrutura; os controles no nível da aplicação (restrições de chamada de ferramenta, aprovações humanas no loop, lista de permissões de egresso) defendem contra o agente ser direcionado a usar mal essas capacidades.

Por que você precisa de um sandbox especificamente para agentes de IA?

A principal diferença da execução tradicional de código é a incerteza. Quando um desenvolvedor humano escreve código, o desenvolvedor sabe aproximadamente o que ele fará. Quando um LLM gera código ou decide chamar uma ferramenta, a aplicação pode ter visibilidade limitada sobre o que exatamente será executado, quais pacotes serão instalados ou quais endpoints externos serão contatados — potencialmente em milhares de sessões simultâneas. Essa incerteza aumenta os riscos para cada um dos controles de segurança padrão: a política de egresso importa porque o agente pode alcançar endpoints que ninguém antecipou; a governança de pacotes importa porque o agente pode instalar dependências dinamicamente; o log de auditoria importa porque reconstruir o que aconteceu é mais difícil quando as ações do agente não foram pré-enumeradas. Um sandbox fornece a camada de aplicação para lidar com essa incerteza sem ter que confiar em cada ação individual do agente antecipadamente.

Provedores comuns de sandbox

Uma breve visão geral das principais opções, com comparações mais completas nos artigos vinculados:

Novita Agent Sandbox — microVM Firecracker, implantação BYOC em sua própria VPC AWS ou GCP, sem taxa de assinatura, sessões de até 24 horas. A principal opção para equipes com requisitos de conformidade, sensibilidade a custos ou que já usam a Novita para inferência LLM. Veja novita.ai/sandbox.
E2B — gerenciado, microVM Firecracker, grande comunidade, sem auto-hospedagem. SDKs bem documentados e ecossistema ativo.
Daytona — cold starts abaixo de 90 ms, código aberto (AGPL), auto-hospedável. Melhor para casos de uso sensíveis à latência ou conformidade onde a infraestrutura auto-hospedada é necessária.
Modal — a principal opção quando você precisa de GPU dentro do sandbox. Isolamento baseado em contêiner.
Vercel Sandbox — cold starts rápidos, melhor para JS/TS na plataforma Vercel.

Para uma comparação completa com especificações e um framework de decisão, veja Melhores Sandboxes de Agente de IA em 2026. Para uma avaliação aprofundada da E2B e Daytona especificamente — cold start, BYOC, snapshots e preços — veja o guia de avaliação de sandbox de agente de IA comparando E2B e Daytona.

O que é um Sandbox de Agente de IA?