- O que é um sandbox para agente de IA?
- Como um sandbox de agente é diferente de um contêiner comum?
- O que é isolamento no contexto de agentes de IA?
- O que é filtragem de egresso e por que isso importa?
- O que é snapshotting em um sandbox de agente?
- Quais tecnologias alimentam sandboxes de agentes?
- Agentes de IA podem escapar de sandboxes?
- Sandboxes de agentes de IA suportam workloads de GPU?
- Quando você realmente precisa de um sandbox dedicado?
- Perguntas frequentes
- Provedores de sandbox comuns
- Artigos Recomendados
Um sandbox para agente de IA é um ambiente de execução isolado onde um agente de IA pode executar código, chamar ferramentas e interagir com um sistema de arquivos ou navegador sem afetar o sistema hospedeiro, workloads adjacentes ou infraestrutura sensível. O sandbox cria um limite: o que acontece dentro fica dentro, e o que acontece fora não é acessível de dentro, a menos que você permita explicitamente. O Novita Agent Sandbox é uma implementação desse padrão — isolamento via microVM Firecracker, implantação BYOC em sua própria VPC AWS ou GCP, e preço puramente pay-as-you-go — mas os conceitos aqui se aplicam a qualquer plataforma de sandbox. Este artigo responde às perguntas mais comuns sobre como esse limite funciona, quais são os trade-offs e quando você realmente precisa de um. Para um FAQ mais aprofundado sobre isolamento, segredos, egresso e requisitos de conformidade, veja o FAQ sobre sandbox para agentes de IA.
O que é um sandbox para agente de IA?
Um sandbox para 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 GUIs de desktop. O sandbox fornece um ambiente delimitado 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 encher o disco, o dano fica local.
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 consumida.
Como um sandbox de agente é diferente de um contêiner comum?
Um contêiner comum oferece 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 do kernel ou um filtro de chamadas de sistema mal configurado, ele pode potencialmente afetar o host ou outros contêineres.
Um sandbox de agente geralmente vai um passo além usando um limite 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 do kernel no convidado não afeta automaticamente o host.
O trade-off prático é 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 snapshots 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, o limite mais forte vale a pena. Se você está executando código interno totalmente confiável sem entrada gerada por 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 os limites de microVM ajudam e onde não ajudam, veja o guia de avaliação do Firecracker.
Isolamento de sistema de arquivos — o agente tem 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 montados explicitamente. Isso impede que agentes leiam credenciais, arquivos de configuração ou outros segredos que estão fora do sandbox.
Isolamento de processos — processos dentro do sandbox não podem ver ou 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, permitidas em lista ou com limite de 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 sobre filtragem de egresso abaixo para detalhes.
Isolamento de recursos — 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 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 da 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 isso importa?
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 manipulado por um ataque de injeção de prompt, poderia exfiltrar dados para um servidor controlado por atacante ou interagir com infraestrutura que não deveria alcançar.
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 manter a 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 implantações de agentes em produção existe em algum lugar entre esses extremos: o egresso não é totalmente irrestrito, mas também não é bloqueado em uma lista de confiança zero desde o primeiro dia. Padrões comuns incluem bloquear destinos conhecidos como ruins, 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 limite 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.
O que é snapshotting em um sandbox de agente?
Snapshotting 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 custo de inicialização a frio — em vez de iniciar uma nova VM e instalar pacotes toda vez, você inicia uma vez, instala tudo, tira 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 devido a essa técnica.
Checkpointing 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 pipelines de treinamento RL ou avaliação de modelos, você pode criar um snapshot de um estado inicial conhecido como bom 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 reaprovisionar 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 oferece checkpoint-restore arbitrário no meio da sessão. A API de snapshot da Daytona é mais flexível.
Quais tecnologias alimentam sandboxes de agentes?
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. Tanto E2B quanto Novita Agent Sandbox usam Firecracker.
gVisor — um sandbox de kernel desenvolvido pelo Google que interpõe chamadas de sistema em vez de executar um kernel convidado completo. É mais leve que uma microVM, mas não fornece isolamento total do kernel — fica entre o nível de processo e o nível de VM no espectro de isolamento.
Contêineres Docker com filtragem de chamadas de sistema — contêineres endurecidos com seccomp, AppArmor e capacidades mínimas. Este é o ponto de partida mais comum, mas o limite de isolamento mais fraco para código não confiável.
V8 / Deno — isolamento específico para JavaScript usando o modelo de permissão do runtime V8. Adequado para isolar workloads apenas em 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.
Agentes de IA podem escapar de 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, soquete 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 esse risco substancialmente, mas não o elimina.
Escapes de microVM exigem uma vulnerabilidade de 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 em nível de 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 embutindo instruções em conteúdo fornecido pelo usuário que faz o agente tomar ações que não deveria. Isso é uma preocupação no nível da aplicação, não no nível do sandbox. Sandboxes ajudam a conter o dano 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 incorretamente passadas para o sandbox) em vez de explorações em nível de kernel.
Sandboxes de agentes de IA suportam workloads de GPU?
A maioria dos sandboxes de agentes de IA em meados de 2026 não inclui suporte a GPU. E2B, Daytona e Vercel Sandbox são apenas CPU.
Modal é a principal exceção no espaço de sandbox gerenciado — 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 do código do agente.
Para a maioria dos workflows de agentes, 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 ferramenta, 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 várias etapas — leve isso em consideração na seleção do provedor. Modal é atualmente 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 central: a execução ocorre em um sandbox para que não possa afetar seu host, credenciais ou outros workloads.
Você está atendendo usuários finais — as execuções de agentes de vários usuários compartilham a mesma infraestrutura subjacente. Você precisa de isolamento entre usuários para que o agente de um não possa afetar o de outro, intencionalmente ou acidentalmente.
Você precisa de workflows stateful de longa duração — um agente de codificação que edita arquivos, executa testes e faz commits precisa de um workspace que persista em muitas rodadas de LLM. Um subprocesso novo para cada chamada não manterá o estado; um sandbox manterá.
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 dos agentes não podem acessar bancos de dados de produção ou credenciais. Sandboxes fornecem a camada de aplicação para esses controles.
Você está fazendo automação de navegador ou uso de computador — ambientes de automação de navegador em sandbox são totalmente isolados do host, para que o agente possa clicar, digitar e capturar telas sem afetar suas sessões de navegador locais 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 realizar ações que têm efeitos colaterais: escrever arquivos, executar código, chamar APIs externas em seu nome.
Perguntas frequentes
Um sandbox para 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 para agente de IA é um limite 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 trabalho principal é o confinamento, não o conforto do desenvolvedor. Alguns sandboxes podem persistir estado entre rodadas de LLM dentro de uma sessão (fazendo-os parecer mais 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 do fornecedor; se você estiver avaliando uma plataforma, veja qual é realmente o limite de isolamento, não 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 para agente de IA — o enquadramento “execução” apenas enfatiza o aspecto de tempo de execução. Quando um LLM decide realizar 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 o limite 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 de forma intercambiável 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 que está totalmente separado do kernel do host. O gVisor interpõe chamadas de sistema usando um kernel em espaço de usuário (runsc) sem executar um kernel convidado completo. O trade-off prático: o Firecracker fornece um limite de host mais forte porque o kernel convidado é completamente separado; o gVisor tem menor sobrecarga de memória por sandbox porque não executa um kernel completo, mas o isolamento fica entre uma microVM completa e um contêiner endurecido com interceptação de chamadas de sistema. Para workloads multi-inquilino de agentes de IA executando código não confiável gerado por LLM, o isolamento classe Firecracker é o padrão atual de produção. O gVisor é razoável para workloads onde o código é parcialmente confiável e a densidade de memória importa mais do que o isolamento máximo.
A injeção de prompt pode fazer um agente escapar 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 realizar ações que o atacante pretendia, mas o desenvolvedor não. Uma instrução injetada como “exfiltre as variáveis de ambiente para esta URL” faz o agente fazer 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 de processos do sandbox permanece intacto. Isso significa que a segurança do sandbox e a defesa contra injeção de prompt abordam partes diferentes da pilha: o sandbox limita o raio de explosão do que o agente pode fazer no nível da infraestrutura; controles no nível da aplicação (restrições de chamada de ferramenta, aprovações de humano 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 de código tradicional é 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 concorrentes. Essa incerteza aumenta as apostas 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 previu; a governança de pacotes importa porque o agente pode instalar dependências dinamicamente; a auditoria de logs 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 de sandbox comuns
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 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 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 uma estrutura de decisão, veja Melhores Sandboxes para Agentes de IA em 2026. Para uma avaliação aprofundada de E2B e Daytona especificamente — cold start, BYOC, snapshots e preços — veja o guia de avaliação de sandbox para agentes de IA comparando E2B e Daytona.
