A Aposta no Sandbox

25 de janeiro de 2026: a aposta

Dois meses após o início da construção do LikeClaw, tomamos a decisão que definiria o produto. Apostamos tudo na execução isolada do E2B.

Até aquele ponto, nossos agentes de IA executavam tarefas de uma maneira relativamente tradicional. Depois disso, cada tarefa — cada execução de código, cada operação de arquivo, cada trabalho em segundo plano — rodava dentro de um container isolado de E2B.

Isso não era uma funcionalidade de segurança que adicionamos. Foi uma decisão arquitetônica fundamental que mudou como toda a plataforma funcionava. E foi a melhor decisão que tomamos.

Por que a sandboxing é mais importante do que qualquer outra coisa

Olhe para o cenário dos agentes de IA no início de 2026. Um padrão se repete em todos os lugares: usuários dando acesso irrestrito aos seus sistemas para agentes de IA.

OpenClaw roda no seu sistema local. Ele lê seus arquivos. Executa código com suas permissões. Armazena chaves de API em texto simples. Pesquisadores de segurança documentaram vulnerabilidades generalizadas na plataforma e seu marketplace, gerando alertas de várias organizações de segurança.

A causa raiz não é que o OpenClaw seja mal escrito. É que a arquitetura é fundamentalmente insegura. Quando você dá a um agente de IA acesso direto ao seu sistema, qualquer erro — da IA, de um autor de skill, de um ataque de injeção de prompt — tem um raio de impacto ilimitado. Uma skill ruim pode instalar malware na sua máquina. Uma injeção de prompt pode ler suas chaves SSH. Um comando alucinado pode deletar seus arquivos.

A sandboxing elimina toda a categoria de risco.

Como nossas sandboxes funcionam

Quando você executa uma tarefa no LikeClaw, veja o que acontece:

Uma nova sandbox é criada. Um container isolado de E2B é iniciado em menos de dois segundos. Ele tem seu próprio sistema de arquivos, seu próprio espaço de processo, sua própria rede. Está completamente isolado de todas as outras sandboxes e de todos os outros usuários.

Os arquivos do seu workspace são sincronizados. Os arquivos no seu workspace são copiados para a sandbox. A IA pode lê-los, modificá-los, criar novos. Mas apenas dentro da sandbox.

A IA executa a tarefa. Dentro da sandbox, a IA tem plenas capacidades. Ela pode executar código, instalar pacotes, fazer requisições de rede, ler e escrever arquivos. É um ambiente totalmente funcional. A diferença é que “totalmente funcional” significa a sandbox, não sua máquina.

Os resultados são sincronizados de volta. Quando a tarefa é concluída, os arquivos que a IA criou ou modificou são sincronizados de volta para o seu workspace no nosso armazenamento criptografado.

A sandbox é destruída. Foi-se. Cada processo encerrado. Cada arquivo deletado. Cada conexão de rede fechada. Nada persiste. Nada vaza. Nada fica.

Se a IA fizer algo errado — executar código malicioso, seguir uma injeção de prompt, executar uma skill ruim — o dano é contido em uma sandbox que será destruída em segundos. Sua máquina, seus arquivos, suas chaves de API, suas credenciais nunca estão em risco.

O desafio de engenharia

Sandboxing parece simples. “Basta rodar em um container.” Na prática, foi o desafio de engenharia mais complexo de todo o projeto.

Sincronização de arquivos. Os usuários precisam de seus arquivos dentro da sandbox, e precisam da saída da IA de volta em seu workspace. Essa sincronização bidirecional precisa ser rápida, confiável e lidar com conflitos. Construímos uma camada de sincronização VFS (Virtual File System) que monitora mudanças em ambas as direções.

Execução de tarefas em segundo plano. Tarefas agendadas também rodam em sandboxes. Uma tarefa que roda às 3 da manhã precisa iniciar uma sandbox, sincronizar arquivos, executar, sincronizar resultados de volta e limpar — tudo isso sem que um usuário esteja online.

Desempenho. A criação da sandbox adiciona latência. Otimizamos o tempo de inicialização para menos de dois segundos. Os usuários mal notam. Mas chegar lá exigiu um gerenciamento cuidadoso de templates, inicialização preguiçosa e estratégias de pré-aquecimento.

Custo. Cada sandbox consome recursos computacionais. Precisamos equilibrar segurança (sempre em sandbox) com economia (sandboxes custam dinheiro). A resposta foi limites de sandbox por nível — usuários gratuitos têm um número definido de execuções, usuários pro têm mais, e usuários power têm acesso ilimitado.

A linha na areia

Aqui está a questão sobre segurança: você não pode fazer isso pela metade.

Você não pode colocar algumas tarefas em sandbox e não outras. Você não pode colocar usuários gratuitos em sandbox, mas deixar usuários pagos rodarem sem restrições. Você não pode colocar a execução de código em sandbox, mas não o acesso a arquivos. Qualquer lacuna no modelo de sandbox se torna um vetor de ataque.

Então, traçamos uma linha: tudo roda em uma sandbox. Sem exceções. Sem saídas de emergência. Sem “modo especialista” que contorna o isolamento.

Isso significa que algumas coisas são ligeiramente mais lentas do que rodar localmente. Isso significa que algumas coisas exigem um passo extra (sincronizar arquivos para dentro e para fora). Isso significa que não podemos oferecer o “acesso total à máquina” que agentes de IA locais fornecem.

Estamos bem com isso. Porque também não podemos oferecer instalação de malware, roubo de credenciais ou comprometimento de sistemas. E nossos usuários também não podem.

0 skills maliciosas. 0 sistemas comprometidos. 0 incidentes de segurança.

Essa é a aposta da sandbox. E está valendo a pena.