Por que Agentes de IA em Sandbox são o Futuro da IA Autônoma

A transição de chatbots para agentes não é uma previsão. Está acontecendo. As empresas querem IA que vá além do chat — IA que execute código, automatize fluxos de trabalho, monitore sistemas e atue de forma autônoma.

A questão não é mais se agentes de IA autônomos se tornarão comuns. É se a arquitetura atual pode suportá-los sem queimar tudo.

As evidências dizem que não.

OpenClaw provou a demanda. Também provou o problema.

OpenClaw é o projeto de código aberto que mais cresce na memória recente. Mais de 150.000 estrelas no GitHub em 10 semanas. Mais de 416.000 downloads no npm em um único período de 30 dias. Cobertura da CNBC, CNN, Fortune e TechCrunch. O projeto — que passou por cinco mudanças de nome em três meses, incluindo uma disputa de marca com a Anthropic — demonstrou algo importante: as pessoas realmente querem agentes de IA que façam coisas, não apenas falem sobre fazê-las.

Então, os relatórios de segurança começaram a chegar.

Os resultados da auditoria de segurança foram devastadores — malware no mercado de habilidades, injeção de prompts em mais de um terço das habilidades analisadas e exfiltração de dados demonstrada pela equipe de segurança da Cisco.

A resposta da comunidade de segurança foi unânime: o modelo de acesso bruto é fundamentalmente falho.

A demanda era real. A execução não estava pronta.

O que deu errado: o modelo de acesso bruto ao sistema

A arquitetura do OpenClaw dá ao agente de IA acesso total à máquina hospedeira. Comandos de shell, leituras e gravações de sistema de arquivos, execução de scripts, automação de navegador — tudo rodando com as permissões do usuário no hardware do usuário.

Isso é poderoso. Também é a causa raiz de quase todos os problemas de segurança que o projeto encontrou.

A plataforma também tem problemas arquitetônicos — armazenamento de credenciais em texto simples, vulnerabilidades documentadas de execução remota de código e um registro de habilidades aberto sem processo de verificação. Sem sandboxing. Sem isolamento entre o ambiente de execução do agente e os dados pessoais do usuário.

A questão fundamental não é um bug que pode ser corrigido. É uma decisão arquitetônica. Quando o agente de IA e o usuário compartilham o mesmo ambiente de execução, o raio de impacto de qualquer erro — habilidade maliciosa, injeção de prompt, comando alucinado — é o sistema inteiro do usuário.

A arquitetura que funciona: execução em sandbox

A alternativa é o isolamento baseado em contêiner, e não é uma ideia nova. O E2B (abreviação de “environment to browser”) pioneiro na abordagem para cargas de trabalho de IA: criar um contêiner leve para cada tarefa, dar ao agente um ambiente de execução restrito dentro desse contêiner e destruir o contêiner quando a tarefa for concluída.

Veja como isso funciona na prática:

• Contêiner por tarefa. Cada execução de código, cada invocação de habilidade, cada ação autônoma roda em seu próprio contêiner isolado. O contêiner tem seu próprio sistema de arquivos, suas próprias restrições de rede e seus próprios limites de recursos.
• Criado e destruído. O contêiner existe apenas durante a duração da tarefa. Quando a tarefa termina, o contêiner é excluído. Nenhum estado persistente vaza entre as execuções. Nenhuma acumulação de superfície de ataque ao longo do tempo.
• Sem acesso ao host. O agente não pode ler ou gravar no sistema de arquivos do host. Ele não pode acessar a rede do host. Não pode ver os dados de outros usuários. Se o agente executar um comando malicioso, o dano é confinado a um contêiner que está prestes a ser coletado como lixo.
• Armazenamento de credenciais criptografado. Chaves de API e segredos vivem em armazenamento criptografado, injetados no contêiner em tempo de execução e limpos na destruição. Não ficam em um arquivo de configuração em texto simples na área de trabalho do usuário.

Este é o mesmo modelo de isolamento usado por todos os principais provedores de nuvem para cargas de trabalho multi-inquilino. AWS Lambda, Google Cloud Run, Cloudflare Workers — todos usam alguma forma de contêiner ou limite de isolamento para garantir que o código de um cliente não possa afetar o de outro. Aplicar o mesmo princípio à execução de agentes de IA já está atrasado.

Por que cloud-native supera local-first para cargas de trabalho de agentes

O modelo local-first tem uma história de privacidade convincente: seus dados permanecem no seu hardware. Mas para cargas de trabalho de agentes de IA especificamente, as compensações favorecem a execução cloud-native.

Espaços de trabalho persistentes sem risco local. Um espaço de trabalho na nuvem dá ao agente um sistema de arquivos persistente para arquivos, histórico de conversas e configurações — sem que nenhum desses dados viva no seu laptop. Seu espaço de trabalho sobrevive entre sessões. Sua máquina local permanece limpa.

Zero configuração. A própria comunidade do OpenClaw relata mais de 3 dias para uma configuração funcional. Gerenciamento de dependências, configuração de permissões, adaptadores de canal, gerenciamento de chaves de API do provedor de modelo. Uma plataforma cloud-native reduz isso a uma aba do navegador e um endereço de e-mail. O benchmark que vimos para plataformas de agentes de IA cloud-native é de menos de 60 segundos desde a inscrição até a execução da primeira tarefa.

Execução de tarefas em segundo plano. Agentes autônomos precisam rodar quando você não está assistindo. Monitorando sua caixa de entrada às 3 da manhã, processando um pipeline de dados durante a noite, executando automações agendadas. Um agente local requer uma máquina dedicada sempre ligada. Um agente na nuvem roda em uma infraestrutura projetada exatamente para isso.

Roteamento multi-modelo. Plataformas de nuvem podem direcionar tarefas para diferentes LLMs com base no tipo de tarefa — Claude para código, GPT-4 para raciocínio geral, DeepSeek para cargas de trabalho sensíveis a custo — através de uma única interface. Sem gerenciar quatro chaves de API separadas e quatro contas de cobrança separadas.

A compensação honesta: se você precisa que seu agente de IA interaja com hardware local ou software exclusivo local, um sandbox na nuvem não funcionará para isso. Para os outros 99% dos casos de uso de agentes — execução de código, processamento de dados, automação web, gerenciamento de e-mails, tarefas agendadas — o modelo de nuvem é estritamente melhor em segurança, confiabilidade e sobrecarga operacional.

O mercado de habilidades feito da maneira certa

ClawHub tem milhares de habilidades construídas pela comunidade — e problemas de segurança documentados que escalam com sua popularidade. O registro de habilidades é a maior superfície de ataque no ecossistema OpenClaw, e foi projetado assim de propósito: baixa fricção, alta velocidade, mínimo controle.

Um mercado verificado sacrifica velocidade por confiança. Cada habilidade passa por verificação automática de código, testes em sandbox e revisão humana antes de ser publicada. Isso é mais lento. Significa menos habilidades disponíveis no lançamento. Mas também significa zero malware de roubo no catálogo do macOS, o que parece uma compensação razoável.

O caminho de importação também importa. Muitos usuários do OpenClaw construíram ou personalizaram habilidades das quais dependem. Uma plataforma alternativa responsável deve fornecer uma maneira de trazer essas habilidades — após passá-las pelo mesmo pipeline de revisão de segurança. A migração sem verificação apenas importaria o problema.

Previsibilidade de custos: a questão de segurança oculta

OpenClaw é um software gratuito. Os custos da API não são. Os usuários relatam custos mensais de API imprevisíveis sem controles de gastos embutidos.

Isso também é um problema de segurança, não apenas um problema de orçamento. Custos descontrolados de um agente comprometido, um ataque de injeção de prompt que aciona chamadas de modelo caras em um loop, ou uma habilidade maliciosa que queima tokens intencionalmente — todos esses são vetores de ataque que exploram a ausência de barreiras de custo.

Tiers de preços fixos com limites de uso abordam isso diretamente. Limites rígidos em execuções de sandbox, rastreamento de uso de tokens visível para o usuário e estrangulamento automático quando os limites se aproximam. O usuário sabe o que pagará antes de pagar. E um atacante não pode transformar o sistema de cobrança em uma arma.

Para onde isso está indo

O mercado de IA agente está crescendo rapidamente, e esse crescimento não acontecerá em arquiteturas onde o agente tem acesso irrestrito à máquina do usuário e o mercado de habilidades é um canal de distribuição de malware não verificado.

A transição para execução em sandbox já está em andamento. O E2B está se tornando um bloco de construção padrão para plataformas de agentes de IA. A Cloudflare construiu o Moltworker especificamente para rodar o OpenClaw em um ambiente contêinerizado. O NanoClaw, um fork da comunidade, roda em contêineres da Apple por questões de segurança. O ecossistema está convergindo para o isolamento como um requisito, não uma característica.

O OpenClaw demonstrou o mercado. A próxima geração de plataformas de agentes de IA será definida pela capacidade de entregar as mesmas funcionalidades — execução de código, ação autônoma, acesso multi-modelo, habilidades extensíveis — dentro de uma fronteira de segurança que realmente funcione.

Nós construímos o LikeClaw para ser essa plataforma. Execução em sandbox, habilidades verificadas, preços previsíveis, zero configuração. Se você quer ver como isso funciona na prática, o caso de uso de execução de código é um bom lugar para começar.

O futuro dos agentes de IA é autônomo. Também é em sandbox. Essas não são ideias concorrentes. Elas são pré-requisitos uma para a outra.