Não confie em agentes de IA

Quando se trabalha com agentes de IA, eles devem ser tratados como não confiáveis e potencialmente maliciosos. Seja por preocupação com injeção de prompts, um modelo tentando escapar da sua sandbox, ou algo em que ninguém pensou ainda, independentemente do seu modelo de ameaças, você não deveria confiar no agente. A abordagem correta não são melhores verificações de permissão ou allowlists mais inteligentes. É uma arquitetura que assume que os agentes vão se comportar mal e contém o dano quando isso acontece.

Esse é o princípio sobre o qual eu construí o NanoClaw.

Não confie no processo

O OpenClaw roda diretamente na máquina host por padrão. Ele tem um modo de sandbox Docker opcional, mas vem desativado de fábrica, e a maioria dos usuários nunca o ativa. Sem ele, a segurança depende inteiramente de controles no nível da aplicação: allowlists, diálogos de confirmação, um conjunto de comandos “seguros”. Esses controles partem de uma confiança implícita de que o agente não vai tentar fazer algo errado. Uma vez que se adota a mentalidade de que um agente é potencialmente malicioso, fica óbvio que bloqueios no nível da aplicação não são suficientes. Eles não oferecem segurança hermética. Um agente determinado ou comprometido pode encontrar formas de contorná-los.

No NanoClaw, o isolamento por contêineres é parte central da arquitetura. Cada agente roda em seu próprio contêiner, seja no Docker ou em um Apple Container no macOS. Os contêineres são efêmeros: criados novos a cada invocação e destruídos depois. O agente roda como um usuário sem privilégios e só consegue ver diretórios que foram explicitamente montados. A fronteira do contêiner é imposta pelo sistema operacional.

Não confie em outros agentes

Mesmo quando a sandbox do OpenClaw está ativada, todos os agentes compartilham o mesmo contêiner. Você pode ter um agente como assistente pessoal e outro para o trabalho, em diferentes grupos de WhatsApp ou canais de Telegram. Todos estão no mesmo ambiente, o que significa que informações podem vazar entre agentes que deveriam acessar dados diferentes.

Agentes não devem confiar uns nos outros mais do que você confia neles. No NanoClaw, cada agente recebe seu próprio contêiner, sistema de arquivos e histórico de sessão do Claude. Seu assistente pessoal não consegue ver os dados do seu agente de trabalho porque eles rodam em sandboxes completamente separadas.

A fronteira do contêiner é a camada de segurança rígida — o agente não consegue escapar dela independentemente da configuração. Além disso, uma allowlist de montagens em ~/.config/nanoclaw/mount-allowlist.json atua como uma camada adicional de defesa em profundidade: ela existe para impedir que o usuário monte acidentalmente algo que não deveria ser exposto, não para impedir que o agente escape. Caminhos sensíveis (.ssh, .gnupg, .aws, .env, private_key, credentials) são bloqueados por padrão. A allowlist fica fora do diretório do projeto, então um agente comprometido não pode modificar suas próprias permissões. O código da aplicação host é montado como somente leitura, então nada que um agente faça pode persistir após a destruição do contêiner.

As pessoas nos seus grupos também não devem ser consideradas confiáveis. Grupos não principais são não confiáveis por padrão. Outros grupos, e as pessoas neles, não podem enviar mensagens para outros chats, agendar tarefas para outros grupos, ou visualizar dados de outros grupos. Qualquer pessoa em um grupo poderia enviar uma injeção de prompt, e o modelo de segurança leva isso em conta.

Não confie no que não pode ler

O OpenClaw tem quase meio milhão de linhas de código, 53 arquivos de configuração e mais de 70 dependências. Isso quebra a premissa básica da segurança do código aberto. O Chromium tem mais de 35 milhões de linhas, mas você confia nos processos de revisão do Google. A maioria dos projetos de código aberto funciona ao contrário: eles se mantêm pequenos o suficiente para que muitos olhos possam realmente revisá-los. Ninguém revisou as 400.000 linhas do OpenClaw. Foi escrito em semanas sem um processo de revisão adequado. A complexidade é onde as vulnerabilidades se escondem, e a análise da Microsoft confirmou isso: os riscos do OpenClaw poderiam surgir através de chamadas de API normais, porque nenhuma pessoa conseguia ver o quadro completo.

O NanoClaw é um único processo e um punhado de arquivos. Dependemos fortemente do Claude Agent SDK da Anthropic, o wrapper em torno do Claude Code, para gestão de sessões, compactação de memória e muito mais, em vez de reinventar a roda. Um desenvolvedor competente pode revisar toda a base de código em uma tarde. Essa é uma restrição deliberada, não uma limitação. Nossas diretrizes de contribuição aceitam apenas correções de bugs, correções de segurança e simplificações.

Novas funcionalidades chegam através de skills: instruções com uma implementação de referência completa e funcional que um agente de programação integra à sua base de código. Você revisa exatamente qual código será adicionado antes de ser aplicado. E você só adiciona as integrações de que realmente precisa. Cada instalação resulta em poucos milhares de linhas de código sob medida para os requisitos exatos do proprietário.

Essa é a diferença real. Com uma base de código monolítica de 400.000 linhas, mesmo que você habilite apenas duas integrações, o resto do código ainda está lá. Ainda está carregado, ainda faz parte da sua superfície de ataque, ainda é alcançável por injeções de prompts e agentes descontrolados. Não é possível separar o que está ativo do que está inativo. Não é possível auditar porque você nem consegue definir o limite do que é “o seu código”. Com skills, o limite é óbvio: são poucos milhares de linhas, é tudo código que você escolheu adicionar, e você pode ler cada linha. O núcleo está na verdade ficando menor com o tempo: o suporte ao WhatsApp, por exemplo, está sendo extraído e empacotado como um skill.

Projete para a desconfiança

Se uma alucinação ou um agente com mau comportamento pode causar um problema de segurança, então o modelo de segurança está quebrado. A segurança precisa ser imposta fora da superfície agêntica, e não depender do agente se comportar corretamente. Contêineres, restrições de montagem e isolamento do sistema de arquivos existem para que, mesmo quando um agente faz algo inesperado, o raio de explosão fique contido.

Nada disso elimina o risco. Um agente de IA com acesso aos seus dados é inerentemente uma situação de alto risco. Mas a resposta certa é tornar essa confiança o mais estreita e verificável possível. Não confie no agente. Construa muros ao redor dele.

Você pode ler o código-fonte e o modelo de segurança completo do NanoClaw; são curtos o suficiente para ler em uma tarde.