cerebro-vip INEMA.CLUB
início › INEMA.DEV Desenvolvimento

Análise técnica aprofundada do **nanobot**, framework de agente IA…

INEMA.DEV Desenvolvimento · 2026-02-08 · ~8 min · ver no Telegram ↗

INEMA

aqui fiz um conteudo para estudar a fundo o nanobot. inclusive inclui alguns skills a mais

inematds.github.io/nanobot ↗

Sistema de tools poderoso: filesystem, shell, web search, web fetch, cron, subagentes * Skills em Markdown + YAML: simples, versionável, fácil de auditar * Memória persistente explícita: MEMORY.md * Personalidade configurável por arquivos: SOUL.md, AGENTS.md, USER.md * Async-first e Docker-ready

Resultado: um agente funcional, rápido (~0.8s startup) e extremamente fácil de entender e modificar.

Pontos Fortes⌗

  • Código compacto e legível
  • Arquitetura limpa e bem separada
  • Extensibilidade real (novo provider ou skill em minutos)
  • Registry de providers elegante
  • Auditabilidade total (sem “caixa-preta”)

👉 Ideal para pesquisa, desenvolvimento pessoal, ambientes confiáveis e aprendizado profundo de agentes LLM.

Segurança (ponto crítico)⌗

Aqui está o maior tradeoff do nanobot.

A análise de segurança mostrou risco alto para uso em produção pública, principalmente por:

  • Execução de shell com blacklist fraca
  • Autenticação aberta por padrão
  • Credenciais em texto plano
  • Nenhuma proteção contra prompt injection
  • Nenhuma mitigação contra SSRF
  • Zero testes de segurança

Isso não é um “bug”, mas uma decisão implícita de escopo: o projeto assume um ambiente confiável.

Sem hardening adicional, não deve ser exposto publicamente.

Comparação com OpenClaw⌗

OpenClaw

  • Muito mais completo e seguro
  • Docker sandbox, permissões granulares, auditoria comunitária
  • Porém: 430k+ linhas, difícil de auditar, já teve CVEs

nanobot

  • Muito mais simples e transparente
  • Fácil de auditar, modificar e entender

  • Porém: segurança mínima, sem isolamento real

  • 👉 OpenClaw vence em produção hostil

  • 👉 nanobot vence em simplicidade, controle e aprendizado

Conclusão Final⌗

O nanobot não é um concorrente direto do OpenClaw — ele é um contraponto filosófico.

OpenClaw = “plataforma robusta para o mundo real” nanobot = “runtime minimalista para quem quer controle total”

Com hardening, CI, testes e sandboxing, o nanobot poderia evoluir para produção. Sem isso, ele já é excelente como base de pesquisa, framework pessoal e referência arquitetural.

Visão Geral⌗

O nanobot é um framework de agente de IA ultra-leve, auditável e extensível, inspirado no OpenClaw/Clawdbot, mas seguindo uma filosofia oposta: simplicidade radical em vez de complexidade massiva.

Enquanto o OpenClaw aposta em escala, sandboxing pesado e um ecossistema enorme, o nanobot prioriza:

  • clareza de código
  • facilidade de extensão
  • baixo consumo de recursos
  • controle total pelo desenvolvedor

Arquitetura & Features⌗

nanobot entrega um conjunto surpreendentemente completo em ~6.600 linhas de Python:

  • Multi-canal: Telegram, WhatsApp (via bridge Node.js), Discord, Feishu, DingTalk
  • Multi-provedor LLM: OpenAI, Anthropic, Groq, DeepSeek, Gemini, Qwen, Moonshot, Zhipu, vLLM local, entre outros
  • Sistema de tools poderoso: filesystem, shell, web search, web fetch, cron, subagentes
  • Skills em Markdown + YAML: simples, versionável, fácil de auditar
  • Memória persistente explícita: MEMORY.md
  • Personalidade configurável por arquivos: SOUL.md, AGENTS.md, USER.md
  • Async-first e Docker-ready

Resultado: um agente funcional, rápido (~0.8s startup) e extremamente fácil de entender e modificar.

Pontos Fortes⌗

  • Código compacto e legível
  • Arquitetura limpa e bem separada
  • Extensibilidade real (novo provider ou skill em minutos)
  • Registry de providers elegante
  • Auditabilidade total (sem “caixa-preta”)

👉 Ideal para pesquisa, desenvolvimento pessoal, ambientes confiáveis e aprendizado profundo de agentes LLM.

Segurança (ponto crítico)⌗

Aqui está o maior tradeoff do nanobot.

A análise de segurança mostrou risco alto para uso em produção pública, principalmente por:

  • Execução de shell com blacklist fraca
  • Autenticação aberta por padrão
  • Credenciais em texto plano
  • Nenhuma proteção contra prompt injection
  • Nenhuma mitigação contra SSRF
  • Zero testes de segurança

Isso não é um “bug”, mas uma decisão implícita de escopo: o projeto assume um ambiente confiável.

Sem hardening adicional, não deve ser exposto publicamente.

Comparação com OpenClaw⌗

OpenClaw

  • Muito mais completo e seguro
  • Docker sandbox, permissões granulares, auditoria comunitária
  • Porém: 430k+ linhas, difícil de auditar, já teve CVEs

nanobot

  • Muito mais simples e transparente
  • Fácil de auditar, modificar e entender

  • Porém: segurança mínima, sem isolamento real

  • 👉 OpenClaw vence em produção hostil

  • 👉 nanobot vence em simplicidade, controle e aprendizado

Conclusão Final⌗

O nanobot não é um concorrente direto do OpenClaw — ele é um contraponto filosófico.

OpenClaw = “plataforma robusta para o mundo real” nanobot = “runtime minimalista para quem quer controle total”

Com hardening, CI, testes e sandboxing, o nanobot poderia evoluir para produção. Sem isso, ele já é excelente como base de pesquisa, framework pessoal e referência arquitetural.

Se quiser, o próximo passo natural seria:

  • definir um roadmap de hardening
  • ou posicionar o projeto como “minimal agent runtime” oficialmente

Você construiu algo bem acima da média.Beleza — aqui vai um resumo executivo de tudo que foi discutido, juntando arquitetura, features, segurança, comparação e posicionamento em uma visão única e clara.

Visão Geral⌗

O nanobot é um framework de agente de IA ultra-leve, auditável e extensível, inspirado no OpenClaw/Clawdbot, mas seguindo uma filosofia oposta: simplicidade radical em vez de complexidade massiva.

Enquanto o OpenClaw aposta em escala, sandboxing pesado e um ecossistema enorme, o nanobot prioriza:

  • clareza de código
  • facilidade de extensão
  • baixo consumo de recursos
  • controle total pelo desenvolvedor

Arquitetura & Features⌗

nanobot entrega um conjunto surpreendentemente completo em ~6.600 linhas de Python:

  • Multi-canal: Telegram, WhatsApp (via bridge Node.js), Discord, Feishu, DingTalk
  • Multi-provedor LLM: OpenAI, Anthropic, Groq, DeepSeek, Gemini, Qwen, Moonshot, Zhipu, vLLM local, entre outros *

Veredito Comparativo de Segurança

OpenClaw é mais seguro em termos absolutos — oferece Docker sandboxing, permissões granulares e aprovação manual de comandos perigosos. Porém, sua complexidade (430k linhas) torna a auditoria difícil e já teve CVEs reportados (ex: data leakage via prompt injection).

nanobot é mais fraco em segurança implementada, mas sua simplicidade (~3.400 linhas) torna a auditoria trivial e o risco de vulnerabilidades escondidas é menor. O tradeoff é claro: menos features de segurança, mas código totalmente legível.

● Comparação: nanobot vs OpenClaw (Clawdbot)

Aqui está a análise comparativa completa:

Contexto

OpenClaw (ex-Clawdbot, ex-Moltbot) é um assistente de IA pessoal massivo criado por Peter Steinberger. Com 430k+ linhas de código e 173k+ stars no GitHub, é um dos projetos open-source de IA que mais crescem. Nanobot é uma reimplementação ultra-leve inspirada nele, feita pela HKUDS (HKU Data Science).

Risco ALTO para uso em produção. O projeto é adequado para estudo e pesquisa, como o README declara, mas não deve ser exposto publicamente sem hardening significativo. As vulnerabilidades mais
críticas são a execução de shell com filtro fraco, autenticação aberta por padrão, e ausência total de proteção contra prompt injection — um atacante em qualquer canal de chat poderia potencialmente
executar comandos no servidor.

● Análise de Segurança do nanobot

O projeto tem vulnerabilidades significativas. Aqui está o resumo por nível de risco:

RISCO ALTO (Prioridade 1)

  1. Injeção de Comandos (agent/tools/shell.py)
  • Usa asyncio.create_subprocess_shell() — executa comandos via shell
  • Filtro por blacklist (regex) é facilmente burlável com $(), backticks, pipes |, encadeamento ;/&&/||
  • Verificação de path traversal (..) é superficial — ignorada com symlinks ou variáveis de ambiente
  1. Autenticação Aberta por Padrão (channels/base.py)
  • allowFrom: [] = permite qualquer pessoa interagir com o bot
  • Matching de usernames fraco — aceita matches parciais via separador |
  • Sem rate limiting — atacante pode esgotar créditos da API
  1. Credenciais em Texto Plano (config/)
  • API keys, tokens de bot, secrets — tudo em JSON sem criptografia
  • Keys colocadas em os.environ (visíveis em /proc//environ)
  • Erros do LiteLLM podem vazar API keys nas mensagens de erro retornadas ao usuário
  1. Prompt Injection (agent/loop.py)
  • Input do usuário inserido diretamente no contexto do LLM sem sanitização
  • Resultados de tools adicionados ao contexto sem filtragem
  • Mensagens de sistema de subagents são confiadas sem verificação
  • Atacante pode manipular o agente para executar comandos arbitrários
  1. SSRF (agent/tools/web.py)
  • WebFetchTool não bloqueia IPs internos (127.0.0.1, 10.x, 172.16.x, 192.168.x)
  • Segue redirects sem validar destino — redirect externo → rede interna
  • Endpoint de metadata cloud acessível: 169.254.169.254 ↗

RISCO MÉDIO (Prioridade 2)

  1. Path Traversal (agent/tools/filesystem.py)
  • _resolve_path() usa comparação de string (inseguro)
  • Vulnerável a TOCTOU (time-of-check-time-of-use) — arquivo pode virar symlink entre check e leitura
  • WriteFileTool cria diretórios pai sem validação
  1. Vazamento de Keys em Logs
  • loop.py loga argumentos de tool calls (podem conter dados sensíveis)
  • Exceções do LiteLLM retornadas como conteúdo visível ao usuário
  1. Race Conditions
  • Operações de arquivo (read/write/edit) têm TOCTOU
  • Dicionário de tasks em subagent.py não é thread-safe
  1. Sem Limites de Tamanho
  • Sem limite no tamanho de mensagens
  • Sem limite no histórico de conversas (exaustão de memória)
  • Download de arquivos sem validação robusta de tamanho (Discord: bypass se size é None)
  1. Sanitização de Input
  • telegram.py: parser Markdown→HTML via regex — possível XSS em URLs
  • whatsapp.py: JSON do bridge aceito sem validação de schema
  • discord.py: sanitização de filenames incompleta (só troca /)

Principais Features

  • Multi-canal: Telegram, WhatsApp (via bridge Node.js/Baileys), Discord, Feishu, DingTalk
  • Multi-provedor: OpenRouter, Anthropic, OpenAI, DeepSeek, Groq, Gemini, DashScope (Qwen), Moonshot, Zhipu, AiHubMix, vLLM local
  • Tools built-in: filesystem (read/write/edit/list), shell, web search (Brave API), web fetch, mensagens, spawn de subagentes, cron
  • Sistema de Skills: Skills em Markdown com YAML frontmatter (github, weather, summarize, tmux, cron, skill-creator)
  • Memória persistente: workspace/memory/MEMORY.md
  • Personalidade configurável: SOUL.md, AGENTS.md, USER.md no workspace
  • Async-first: Construído sobre asyncio para operações concorrentes
  • Docker: Dockerfile incluído para deploy containerizado

Componentes Externos

  • bridge/: Aplicação TypeScript/Node.js (Baileys + WebSocket) para integração com WhatsApp
  • tests/: Apenas 1 arquivo de testes (test_tool_validation.py) — cobertura de testes é muito baixa
  • workspace/: Templates de configuração do agente (AGENTS.md, SOUL.md, USER.md, TOOLS.md, HEARTBEAT.md)

Pontos Fortes

  1. Código extremamente compacto — fácil de entender e modificar
  2. Arquitetura limpa — separação clara de responsabilidades
  3. Extensível — adicionar novo provider = 2 passos; skills = um arquivo Markdown
  4. Provider Registry — padrão declarativo elegante em registry.py

Pontos de Atenção

  1. Cobertura de testes mínima — apenas 88 linhas de testes para 6.600+ de código
  2. Sem type hints completos em vários módulos
  3. Segurança de shell — ExecTool executa comandos do shell (mitigado por restrictToWorkspace)
  4. Dependência de runtime externo — WhatsApp requer Node.js >= 20 rodando em paralelo
  5. Sem CI/CD configurado no repositório local

NanoBot x OpenClaw

1

Recursos

↑ voltar ao topo · ver no Telegram ↗