O que é a Execução Sandboxed do E2B e por que seu agente de IA precisa disso

O que é a execução em sandbox do E2B

Quando um agente de IA gera código e o executa, esse código precisa ser executado em algum lugar. A questão é onde — e com que nível de acesso.

E2B (abreviação de “Environment to Binary”) é uma infraestrutura de código aberto para executar código gerado por IA em sandboxes na nuvem. Em vez de executar o código na sua máquina local com suas permissões de usuário, seus arquivos e seu acesso à rede, o E2B cria um container isolado na nuvem. O código é executado dentro desse container. Quando termina, o container é destruído.

O conceito é simples: trate cada execução de código como não confiável. Dê a ele um ambiente descartável. Deixe-o fazer seu trabalho. Pegue os resultados. Descarte o ambiente.

Esse é o mesmo princípio por trás de como os sistemas de CI/CD na nuvem funcionam. O GitHub Actions não executa seus scripts de build em um servidor compartilhado onde um projeto pode ler os segredos de outro projeto. Cada execução recebe um container novo. O E2B aplica esse mesmo modelo à execução de código de agentes de IA.

Como funciona o ciclo de vida do container

O ciclo de vida de uma sandbox do E2B segue um padrão previsível.

Quando seu agente de IA precisa executar código, a plataforma solicita um novo container do E2B. Esse container é um ambiente Linux leve — pense nele como uma máquina virtual mínima que inicializa em menos de um segundo. Ele tem seu próprio sistema de arquivos, sua própria árvore de processos, seu próprio namespace de rede.

O container recebe apenas o que precisa: o código a ser executado, os arquivos de trabalho relevantes para a tarefa e quaisquer dependências especificadas na solicitação de execução. Ele não recebe suas chaves SSH. Ele não recebe seus arquivos .env. Ele não recebe acesso à sua rede local.

O código é executado. Se ele produzir arquivos de saída, esses arquivos são extraídos e salvos no seu espaço de trabalho persistente. Se ele falhar, ele falha dentro do container — seu sistema não é afetado. Se ele tentar fazer uma solicitação de rede para localhost:5432 esperando alcançar seu banco de dados, essa solicitação não vai a lugar nenhum.

Quando a execução é concluída — ou quando o tempo limite expira — o container é encerrado e seu sistema de arquivos é apagado. Não há estado residual. A próxima tarefa começa com um container novo, não um reciclado com artefatos restantes de uma execução anterior.

Por que isso é importante: a alternativa é pior do que você pensa

Para entender por que a execução em sandbox é importante, veja o que acontece sem ela.

OpenClaw — a estrutura de agente de IA de código aberto que alcançou 150.000 estrelas no GitHub em 10 semanas — executa código gerado por IA diretamente na sua máquina. O agente de IA tem acesso total ao shell. Ele pode ler e escrever qualquer arquivo que sua conta de usuário possa acessar. Ele pode fazer solicitações de rede para qualquer serviço que sua máquina possa alcançar. Ele pode instalar pacotes, modificar configurações do sistema e executar comandos arbitrários.

A pesquisa de segurança que se seguiu não foi encorajadora. Pesquisadores da Snyk documentaram problemas de segurança generalizados no marketplace do ClawHub, incluindo distribuição de malware e injeção de prompts.

Além do marketplace, a própria arquitetura é o problema. A plataforma armazena credenciais em texto simples, e várias organizações de segurança publicaram avisos sobre a arquitetura.

Esse não é um risco teórico. Isso é o que acontece quando o código gerado por IA é executado sem uma sandbox.

O que a execução em sandbox possibilita

Uma vez que a execução de código está isolada em um container, várias coisas se tornam possíveis que antes eram arriscadas demais.

Execução segura de código de qualquer modelo. Quando seu agente de IA escreve um script em Python para processar seus dados, você não precisa revisar cada linha antes de executá-lo. O script é executado em uma sandbox. Se ele fizer algo inesperado, o raio de explosão é zero. Essa é a diferença entre “espero que esse código seja seguro” e “não importa se esse código é seguro, porque ele não pode alcançar nada importante.”

Processamento de dados sem risco de vazamento. Você pode passar dados sensíveis para uma sandbox para processamento — registros financeiros, listas de clientes, métricas internas — sabendo que os dados existem apenas dentro do container durante a duração da tarefa. Eles não são escritos em um sistema de arquivos compartilhado. Eles não são acessíveis a outros usuários na mesma plataforma. Quando o container é destruído, os dados desaparecem.

Isolamento multi-inquilino. Em uma plataforma com múltiplos usuários, o sandboxing significa que a execução de código de um usuário não pode interferir na de outro. Não há estado compartilhado entre os containers. Isso é essencial para qualquer plataforma de nuvem séria, mas está completamente ausente nas ferramentas de agentes de IA locais.

Ambientes reproduzíveis. Cada execução começa a partir de um estado conhecido. Sem problemas de “funciona na minha máquina”. Sem estado acumulado de execuções anteriores causando comportamentos inesperados. Se uma tarefa funciona uma vez, ela funciona toda vez, porque o ambiente é idêntico a cada vez.

Para uma análise mais profunda sobre por que o sandboxing é a direção que toda a indústria de agentes de IA está tomando, veja nosso post sobre por que agentes de IA em sandbox são o futuro. E se você quiser ver a execução em sandbox na prática, o caso de uso de execução de código passa por fluxos de trabalho reais.

Desempenho: a execução na nuvem não é o gargalo que você espera

Uma suposição comum é que executar código em um container remoto deve ser mais lento do que executá-lo localmente. Para muitas cargas de trabalho, o oposto é verdadeiro.

Seu laptop está executando um navegador, um cliente de chat, um IDE, sincronizações em segundo plano e tudo mais que você tem aberto. Quando um agente de IA executa um script intensivo em CPU localmente, ele compete com tudo isso por recursos. Um container na nuvem recebe recursos dedicados. Ele não compartilha CPU com seu Spotify.

Para tarefas que se beneficiam do paralelismo — processando múltiplos arquivos, executando operações em lote, executando suítes de testes — containers na nuvem podem ser iniciados em paralelo. Cinco containers processando cinco conjuntos de dados simultaneamente terminarão mais rápido do que um laptop processando-os sequencialmente.

A instalação de dependências é outra vantagem. Uma configuração local exige que você instale pacotes Python, módulos Node ou bibliotecas de sistema na sua máquina. Um container na nuvem pode usar uma imagem pré-construída com dependências comuns já instaladas. Sem espera para pip install. Sem conflitos de versão com seu ambiente existente.

A sobrecarga de latência de enviar uma tarefa para a nuvem e receber os resultados de volta é real, mas geralmente é medida em milissegundos a poucos segundos — insignificante em comparação com o tempo de execução da maioria das tarefas significativas.

Limitações: o que a execução em sandbox não pode fazer

Ser honesto sobre os limites é mais importante do que exagerar a capacidade.

Acesso a nível de sistema. Se sua tarefa requer modificar configurações do sistema, interagir com hardware local (dispositivos USB, impressoras, GPUs conectadas à sua máquina) ou ler arquivos que existem apenas no seu sistema de arquivos local e não podem ser carregados, uma sandbox na nuvem não pode ajudar. Essas tarefas requerem execução local por definição.

Interações de latência extremamente baixa. Para tarefas que requerem tempos de resposta sub-milisegundo ou integração apertada com o loop de eventos de um aplicativo local, a ida e volta da rede para um container na nuvem adiciona latência que pode não ser aceitável. Isso se aplica a um conjunto restrito de casos de uso — processamento de áudio em tempo real, scripting de motores de jogo, loops de controle de hardware — mas é uma limitação real.

Mudanças persistentes no sistema. Se seu objetivo é instalar software na sua máquina, modificar sua configuração de shell ou mudar seu ambiente de desenvolvimento local, uma sandbox que é destruída após a execução é a ferramenta errada. A sandbox é projetada para produzir saídas, não para modificar o host.

Para a grande maioria das tarefas de agentes de IA — execução de código, processamento de dados, geração de arquivos, interações com API, operações em lote, análises — a execução em sandbox não é apenas adequada. É melhor. Você obtém a mesma capacidade de execução de código sem nenhum risco.

Como a LikeClaw usa o E2B

A LikeClaw executa cada tarefa de execução de código em uma sandbox do E2B. Isso não é uma configuração de segurança opcional. É a arquitetura.

Quando seu agente de IA precisa executar código, um container é criado. Seus arquivos de trabalho são montados como somente leitura, a menos que a tarefa exija acesso de gravação. Suas chaves de API são armazenadas criptografadas e injetadas como variáveis de ambiente em tempo de execução — nunca escritas em disco dentro do container, nunca armazenadas em texto simples. O código é executado. Os resultados retornam. O container é destruído.

É assim que você obtém o poder de agentes de IA autônomos — execução real de código, processamento real de arquivos, automação real — sem o modelo de segurança que fez com que a Kaspersky, Cisco e Snyk emitissem avisos.

A execução em sandbox não é uma funcionalidade. É a fundação.