No início de fevereiro de 2026, o GitGuardian publicou um relatório que deveria ter alarmado todo desenvolvedor rodando um assistente pessoal de IA. Sua infraestrutura de varredura de segredos detectou mais de 200 credenciais vazadas diretamente ligadas a implantações do OpenClaw — chaves de API, senhas de banco de dados, tokens OAuth e credenciais de provedores de nuvem, espalhadas por repositórios públicos, arquivos de log e relatórios de erro. Algumas pertenciam a empresas de saúde. Outras a startups de fintech. Todas estavam ativas.
Poucos dias depois, a Northeastern University publicou um artigo com uma manchete que cortou mais fundo que qualquer número de CVE: "Por Que o Assistente de IA OpenClaw é um 'Pesadelo de Privacidade.'" Os pesquisadores não focaram em uma única vulnerabilidade. Focaram na arquitetura em si — na forma como o OpenClaw lida com dados, armazena credenciais e expõe informações do usuário por design, não por acidente.
Esses não foram incidentes isolados causados por usuários descuidados. Foram o resultado previsível de rodar agentes de IA em ambientes onde segredos, dados de usuários e código do agente compartilham o mesmo espaço de endereçamento sem isolamento entre eles.
Como Segredos Acabam nos Lugares Errados
A configuração típica do OpenClaw funciona assim: você instala na sua máquina, configura suas chaves de API em variáveis de ambiente e começa a conversar. O processo do agente roda como seu usuário, com suas permissões, lendo suas variáveis de ambiente. Cada skill que você instala roda no mesmo processo, com o mesmo acesso.
Isso significa que quando você pede ao seu assistente de IA para ajudar a debugar um script de deploy, o agente consegue ver suas credenciais da AWS. Quando uma skill processa seu email, ela consegue ler sua senha do banco de dados. Quando um erro ocorre e um stack trace é registrado no log, essas variáveis de ambiente podem acabar no arquivo de log. E quando esse arquivo de log é commitado em um repositório, ou enviado em um relatório de bug, ou sincronizado com um serviço de nuvem — seus segredos agora são públicos.
Os mais de 200 segredos vazados pelo GitGuardian não foram resultado de 200 erros separados. Foram resultado de um erro arquitetural repetido 200 vezes: colocar segredos no process.env onde qualquer código no processo pode lê-los.
O problema se agrava com skills e plugins. O sistema de skills do OpenClaw roda código de terceiros no mesmo processo que o agente principal. Uma skill maliciosa não precisa de um exploit para roubar suas credenciais — ela simplesmente lê o process.env. Uma skill mal escrita não precisa vazar seus dados intencionalmente — ela simplesmente inclui contexto de ambiente em um relatório de erro. A superfície de ataque não é uma vulnerabilidade a ser corrigida. É a própria arquitetura. ## O Que a Northeastern Acertou
Os pesquisadores da Northeastern identificaram algo que a comunidade de segurança vinha contornando: o problema de privacidade com assistentes de IA não é sobre criptografia ou autenticação. É sobre a questão fundamental do que o agente pode acessar e quais limites existem entre o mundo do agente e o seu.
Quando um agente de IA roda como seu usuário, com suas permissões, na sua máquina, não existe limite. O agente pode ler seus arquivos, suas credenciais, seu histórico de navegação, suas chaves SSH. Ele pode acessar tudo que você pode acessar. A única coisa que o impede de fazer algo prejudicial é o prompt — e ataques de injeção de prompt já demonstraram repetidamente que prompts não são uma fronteira de segurança.
É isso que a Northeastern quis dizer com "pesadelo de privacidade." Não que o OpenClaw estivesse roubando dados deliberadamente, mas que a arquitetura tornava impossível garantir que dados não vazariam. O acesso do agente era limitado apenas pelas permissões de usuário do sistema operacional, o que equivale a dizer que não era significativamente limitado.
Como o Isolamento por Container do NanoClaw Muda a Equação
O NanoClaw adota uma abordagem fundamentalmente diferente. Cada agente roda dentro do seu próprio container Linux — Apple Container no macOS, Docker no macOS e Linux. O container não é uma funcionalidade de conveniência ou uma opção de deploy. É o modelo de segurança.
Quando você envia uma mensagem para o NanoClaw, o processo host não roda o Claude diretamente. Ele cria um container, monta apenas os diretórios específicos que aquele agente precisa acessar e passa o contexto da conversa. O agente roda dentro do container com seu próprio sistema de arquivos, seu próprio espaço de processos e sua própria pilha de rede. Quando termina, o container é destruído.
É aqui que o tratamento de segredos fica interessante. O NanoClaw nunca carrega sua ANTHROPIC_API_KEY no process.env. Em vez disso, ele lê a chave do .env em tempo de execução e a passa para o processo do container via stdin como um payload JSON. Dentro do container, o agent-runner recebe a chave, usa para chamadas de API e nunca a grava em disco ou exporta para o ambiente.
Isso significa que mesmo se um prompt malicioso enganar o agente para rodar `printenv` ou `cat /proc/self/environ`, a chave de API não está lá. Ela existe apenas na memória do processo do agent-runner, pela duração daquele único turno de conversa. Um container comprometido não pode vazar o que não tem acesso.
O sistema de montagem adiciona outra camada. O NanoClaw mantém uma lista de permissões de diretórios que podem ser montados nos containers, armazenada fora da raiz do projeto. Cada grupo recebe seu próprio sistema de arquivos isolado — seu próprio arquivo de memória CLAUDE.md, seu próprio workspace gravável. A lista de permissões inclui detecção de escape por symlink, então um link simbólico forjado não consegue enganar o sistema de montagem para expor diretórios fora do conjunto permitido.
Os containers também rodam como usuário não-root, com o código-fonte do projeto montado como somente leitura. Um agente pode ler a base de código para entender o contexto, mas não pode modificar os arquivos do host. Caminhos graváveis são limitados por grupo e limpos quando o container encerra.
O Modelo de Isolamento por Grupo
O isolamento do NanoClaw vai além de apenas separar o agente do host. Cada grupo do WhatsApp recebe seu próprio container, sua própria memória e seu próprio sistema de arquivos. O Grupo A não consegue ver as conversas, arquivos ou memória CLAUDE.md do Grupo B — não por causa de controles de acesso no nível da aplicação, mas porque rodam em containers fisicamente separados com pontos de montagem separados.
Isso importa para um cenário que a maioria dos assistentes de IA ignora completamente: dispositivos compartilhados e configurações multiusuário. Se você usa o NanoClaw com sua família, as conversas e arquivos do seu grupo de trabalho são isolados das conversas e arquivos do seu grupo familiar no nível do container. Não existe bug de aplicação que possa vazar dados entre grupos, porque o isolamento é aplicado pelo runtime do container, não pela aplicação.
Seu canal principal do WhatsApp — a mensagem direta com o assistente — serve como interface de administração. É o único canal que pode gerenciar tarefas agendadas, modificar configuração e acessar estado entre grupos. Canais de grupo são restritos ao seu próprio sandbox por padrão. ## O Que a Indústria Deveria Aprender
O relatório do GitGuardian e a análise da Northeastern apontam para a mesma conclusão: agentes de IA são infraestrutura, e infraestrutura exige segurança de nível de infraestrutura. Rodar um agente de IA no mesmo processo que suas credenciais, com as mesmas permissões da sua conta de usuário, é o equivalente a rodar um servidor web como root sem firewall. Funciona até não funcionar, e quando não funciona, o raio de explosão é tudo.
Isolamento por container não é uma ideia nova. A indústria de hospedagem web descobriu isso duas décadas atrás — você não roda o código de múltiplos clientes no mesmo processo. A indústria de banco de dados descobriu isso ainda antes — você não dá a cada consulta acesso a todas as tabelas. Mas o ecossistema de agentes de IA ainda está na fase "rodar tudo como root", e os segredos vazados e pesadelos de privacidade são o resultado previsível.
A abordagem do NanoClaw não é a única forma de resolver esse problema, mas demonstra que o problema é solucionável sem sacrificar funcionalidade. Agentes rodando dentro de containers ainda podem pesquisar na web, navegar em páginas, ler e escrever arquivos e executar comandos shell. Eles apenas fazem isso dentro de um sandbox onde o raio de explosão de qualquer falha — seja um bug, uma injeção de prompt ou uma skill maliciosa — é limitado ao escopo daquele único container.
Os 200 segredos vazados que o GitGuardian encontrou não precisavam ter acontecido. Aconteceram porque a arquitetura os tornou inevitáveis. A correção não é melhor educação do usuário ou gerenciamento mais cuidadoso de credenciais. A correção é uma arquitetura onde segredos não podem vazar porque nunca estão em um lugar onde vazar é possível.