Executando o NanoClaw em sandboxes Docker

• Com a colaboração entre NanoClaw e Docker, agora é possível executar cada agente de IA em uma sandbox Docker isolada com um comando de uma linha
• Cada agente roda em um contêiner independente dentro de uma micro-VM, com um ambiente totalmente isolado e sem acesso ao sistema host
• Por meio de uma estrutura de dupla fronteira de segurança, mesmo em caso de escape do contêiner, o bloqueio ocorre no nível da VM, protegendo arquivos, credenciais e aplicações do host
• O modelo de segurança do NanoClaw adota um “design baseado em desconfiança”, tratando os agentes como potenciais atores maliciosos e adotando uma estrutura para minimizar danos
• No futuro, o objetivo é expandir com recursos para operar grandes equipes de agentes, como controle de compartilhamento de contexto, agentes persistentes, políticas de permissão granulares e processos de aprovação humana

---

Visão geral da integração com sandboxes Docker

• O NanoClaw oferece suporte à execução em sandbox com um comando de uma linha por meio de sua colaboração com a Docker
  • Compatível com macOS (Apple Silicon) e Windows (WSL), com Linux previsto em breve
  • O script de instalação automatiza clone, configuração e montagem da sandbox
• Cada agente é executado em um contêiner independente dentro de uma micro-VM
  • Não é necessário hardware adicional nem configuração complexa
  • Cada contêiner possui seu próprio kernel e daemon do Docker, e o acesso ao host é bloqueado

Como funciona

• A sandbox Docker fornece isolamento em nível de hipervisor, com inicialização rápida na escala de milissegundos
• O NanoClaw se encaixa naturalmente nessa estrutura
  • Cada agente possui filesystem, contexto, ferramentas e sessão independentes
  • Ex.: um agente de vendas não pode acessar mensagens pessoais, e um agente de suporte não pode acessar dados do CRM
• A camada de micro-VM forma uma segunda fronteira de segurança
  • Mesmo que haja escape do contêiner, a barreira da VM impede o avanço e protege o sistema host

Modelo de segurança: design baseado em desconfiança

• O NanoClaw foi projetado com a premissa de uma arquitetura que não confia em agentes de IA
  • Considera riscos imprevisíveis, como prompt injection e mau funcionamento do modelo
  • Foi projetado para não colocar segredos nem credenciais no ambiente do agente
• A segurança é imposta de fora do agente, sem depender de comportamento correto
• Diferentemente do OpenClaw, o NanoClaw oferece isolamento completo entre agentes
  • O OpenClaw compartilha o mesmo ambiente, o que pode misturar dados pessoais e corporativos
• Reforça o princípio de engenharia de segurança que trata o agente ao mesmo tempo como colaborador e potencial atacante

Direções futuras

• Aponta a necessidade de construir nova infraestrutura e uma camada de runtime para operar grandes equipes de agentes
• O NanoClaw já pode se conectar a vários canais do Slack para operar agentes independentes por função de trabalho
• Quatro recursos principais propostos para a próxima etapa
  • Compartilhamento controlado de contexto: combinar compartilhamento livre de informações dentro da equipe com compartilhamento seletivo entre equipes
  • Criação de agentes persistentes: em vez de subagentes descartáveis, membros de equipe com ID, ambiente e dados persistentes
  • Políticas de permissão granulares: controle detalhado, como permitir apenas leitura de e-mails, restringir acesso a determinados repositórios e definir limites de gastos
  • Processos de aprovação humana: ações irreversíveis são executadas após revisão humana
• O NanoClaw é apresentado como uma camada de runtime e orquestração com foco em segurança, enquanto as sandboxes Docker são a base de infraestrutura de nível empresarial
• O objetivo é construir uma stack de execução de agentes que ofereça ao mesmo tempo isolamento por padrão, colaboração controlada e visibilidade e governança em nível organizacional

Visão geral do NanoClaw

• O NanoClaw é uma camada open source de runtime e orquestração com foco em segurança para operar agentes de IA em equipe
• É possível conferir o projeto no GitHub e apoiar com uma estrela (star)

[GN⁺]

Comentários do Hacker News

• Parece um detalhe pequeno, mas algumas novas decisões de design, se se espalharem pelo setor, podem trazer mudanças revolucionárias
  Como o Karpathy comentou, o ponto central é oferecer uma skill (spec) sobre “como escrever integrações”, em vez de implementar diretamente integrações como Slack ou Discord
  Dá para chamar isso de “Claude native development”; em vez de frameworks “batteries-included”, o ecossistema talvez migre para um modelo de “fork and customize”
  Ainda assim, há muitos desafios a resolver, como distribuir specs de teste, validação e segurança
  Fico me perguntando se esse tipo de mudança também poderia acontecer no nível do sistema operacional. Se cada instância tiver um sistema imunológico forte, talvez surja um ecossistema heterogêneo mais resistente a ataques

  • Isso parece reduzir a eficiência, já que cada usuário teria de repetir o mesmo trabalho. Acho melhor implementar uma vez e compartilhar com todos
  • A força do open source está na colaboração e no processo de validação. Assim como LLMs produzem muitos bugs no começo, humanos também. Eu prefiro customizar em cima de uma base já validada
  • Às vezes penso que poderíamos chegar a um mundo em que funcionalidades são implementadas trocando arquivos de especificação em Markdown em vez de código

• Ao discutir ferramentas de segurança ou sandboxing, é obrigatório explicitar o modelo de ameaça (threat model)
  O perigo é que um agente de IA possa executar código arbitrário em um host que contém dados sigilosos
  Por exemplo, apagar uma caixa de e-mail, vazar um calendário ou fazer uma transferência errada não são coisas que uma sandbox sozinha consegue impedir
  Portanto, além da sandbox, é preciso haver controle granular de permissões por tarefa e por ferramenta. Ex.: “esta solicitação só pode ler o Gmail, e não deve poder escrever nem apagar”

  • Concordo totalmente. Além disso, são necessários rastreamento de fluxo de dados entre ferramentas (IFC) e atenuação de privilégios (ocap). Por exemplo, deveria ser possível expressar políticas como “proibido enviar dados para fora da thread de e-mail original”
  • Como o texto “Don’t Trust AI Agents” diz, agentes de IA devem ser projetados partindo da desconfiança. É preciso uma estrutura que assuma mau funcionamento ou prompt injection e minimize os danos
  • Eu criei o framework de agentes com foco em controle por políticas smith-core e o gateway smith-gateway. Mas esse tipo de discussão sobre design de segurança quase não recebe atenção da comunidade
  • Vi um texto interessante que, como menciona o OpenClaw Sandbox, permissões são binárias, mas o comportamento dos LLMs é probabilístico, então os dois conceitos entram em conflito na essência
  • Na prática, já existem sistemas de permissões legados como IAM, WIF, Macaroons e Service Accounts. Se você perguntar ao time de segurança, provavelmente haverá soluções que também podem ser usadas dentro da empresa

• Gostei do NanoClaw. O OpenClaw era complexo demais, mas o NanoClaw é muito mais enxuto
  É o primeiro projeto que usa o Claude Code como interface de configuração, e adicionar recursos é divertido e funciona bem

  • Minha instância de OpenClaw quebrou recentemente. Uma atualização estragou a integração com o OpenRouter, e o código é complexo demais
    O modelo de segurança também não combina com meu ambiente rootless de Kubernetes, então sempre dá problema
    Por isso migrei para o Nullclaw. Também é interessante do ponto de vista de aprendizado, porque posso debugar enquanto aprendo a linguagem Zig
  • Fico curioso sobre que tipo de workflow não dá para criar facilmente com Claude no Nanoclaw

• A sandbox Docker é parecida com o framework container da Apple
  No macOS, ela serve bem como um runtime nativo mais leve do que Docker
  Mas no Linux eu não quero usar hipervisor. Só com Linux namespace já dá para isolar o suficiente
  Fico me perguntando por que OpenClaw ou NanoClaw não oferecem uma imagem Docker oficial bem configurada

  • No macOS eu uso Apple Container; em outros sistemas operacionais, uso Podman
    O Container tem alguns bugs de rede, mas ainda assim vale a pena. Basta ajustar a configuração de DNS
    Gosto de não precisar instalar Claude Code nem Node.js no host

• Mais importante do que ser ou não um contêiner é o que se quer fazer
  Enquanto não houver um jeito de gastar tokens em tarefas úteis, o runtime é secundário
  Do ponto de vista de segurança, colocar um LLM dentro de um contêiner não basta. O importante é o alcance das informações acessíveis
  Se o agente pode acessar todos os dados, esse é o verdadeiro risco

  • A sandbox Docker usa uma MicroVM como camada adicional de isolamento. Não é um contêiner simples

• O essencial é ter permissões granulares e controle por políticas
  Não basta definir quais ferramentas podem ser usadas; é preciso definir o que pode ser feito
  Ex.: só leitura de e-mail, acesso apenas a um repositório específico, limite de gastos etc.
  Só o sandboxing com Docker não dá confiança suficiente para entregar ao LLM ativos sensíveis, como contas de mensageria

• A sandbox Docker sobe uma MicroVM e um daemon Docker dedicados para cada agente, além de configurar um proxy de egress flexível
  Fiz engenharia reversa e é uma implementação bem interessante

• O NanoClaw não é um produto final pronto para uso
  Você precisa adicionar por conta própria recursos como iMessage por meio de um agente de código
  Em outras palavras, o Claude faz o papel de compilador

  • Houve uma época em que as pessoas conferiam diretamente o assembly gerado pelo compilador
    Os agentes de código ainda estão nesse nível. Dizer que “os agentes de código ficaram muito melhores” ultimamente é exagero
    Ainda é preciso repetir para o Claude: “isso ainda não foi resolvido, faz de novo”

• Estou trabalhando em uma ideia parecida com “claws”
  Em vez de integração com apps de mensagem, a proposta é oferecer uma TUI com criptografia de ponta a ponta
  Veja wingthing.ai / repositório no GitHub
  Estou pensando em como dar suporte a Docker, então também vou olhar este projeto

• Fico curioso sobre o caso de uso claro de Nano/Open-Claw. É para tocar minha vida digital por mim?

  • Na verdade é simples. Ou é um cronjob com LLM, ou um conector de chat como Telegram ou e-mail. O primeiro pode ser feito com cron comum; o segundo, com código manual ou Gemini Gems
  • É útil para automatizar trabalho intelectual repetitivo, como resumos de e-mail, alertas de agenda e documentos de briefing
  • Dá para conectar a um app de tarefas e gerenciar tudo por mensagem com um bot. Isso ajuda na produtividade
  • Eu uso o NanoClaw como coach de dieta e exercícios. Ele cuida de metas, planejamento alimentar, lista de compras e registro de treinos
    Migrei para Apple Container e também adicionei uma memória de longo prazo baseada em LanceDB. Agora não preciso repetir as mesmas coisas o tempo todo