A polícia chegou no TatuEngine — segurança como processo, não documento

⚡ O motor que sabia agir, mas não sabia se proteger

O TatuEngine já tinha feito muita coisa até aqui: aprendeu a inferir (BitMamba-2 1B em GPU, 252× de speedup), aprendeu a agir (agente autopoiético com 8 subsistemas, ToolUse, GoalStack, LTM), e estava aprendendo a aprender (ciclo Mestre-Aprendiz). Por baixo de tudo isso, um sandbox híbrido com 51/51 testes de path validation.

Parecia seguro. Mas segurança não é uma feature — é um processo. E processo é exatamente o que o TatuEngine não tinha documentado.

🧠 O contexto: o agente mais autônomo do ecossistema

Aqui vai o problema que me incomodava: o TatuEngine é o projeto com maior autonomia de todo o meu ecossistema. Ele tem um agente que:

• Executa ferramentas via ToolUse (não só lê — age)
• Expoe um MCP server com tool_execute (stdio/SSE)
• Escreve e lê arquivos (sandbox híbrido)
• Persiste estado (checkpoint .brain com CRC32)

Enquanto isso, o resto do ecossistema já tinha adotado uma política de segurança contínua — LifeLog, Portfólio e LEVE LAVANDA ganharam SEGURANCA.md em 04/08, com a regra que virou filosofia: “segurança é acompanhamento, não um documento parado”.

O TatuEngine era a lacuna. O motor mais poderoso do ecossistema era o único sem um plano formal de defesa.

🔧 A luta: inventariar o que já existe antes de construir

A regra do ecossistema manda auditar antes de melhorar. Então o primeiro passo não foi escrever firewall — foi inventariar o que o TatuEngine já tinha de proteção. O resultado surpreendeu: o projeto estava mais blindado do que eu pensava.

# tatu/sandbox.py — a fronteira
# Três pilares:
#   1. Path traversal prevention (resolve + prefix check)
#   2. File size & type enforcement
#   3. Read vs write scope control
from tatu.sandbox import sandbox  # singleton global
result = sandbox.check_read("~/projetos/teste.txt")
if result.ok:
    path = result.path  # Path resolvido com prefix check

O sandbox existia. O Tool Registry existia. O MCP server existia. O .brain tinha CRC32. O que faltava era consolidar tudo num documento único com princípios, inventário, lacunas e roadmap — e, principalmente, automatizar a vigilância.

# security-scan-tatuengine.sh — scan diário 07:30
# 1. Gitleaks (secrets no repo — history + working tree)
# 2. .env permissions (deve ser 600)
# 3. Hardcoded secrets em src/ (padrões sk_live_, AKIA, ghp_, chaves privadas)
# 4. Git history do .env (nunca deve ter sido commitado)
# 5. Dockerfile USER directive
# Summary: ✅ Pass / ⚠️ Warnings / 🔴 Critical / ❌ Fail

O scan é honesto: ele falha se achar crítico (exit 1), avisa se achar warning, e fica quieto quando tudo está certo. A primeira execução depois do documento: 3 pass, 0 warnings, 0 críticos.

💡 A resolução: SEGURANCA.md v1.0 + watchdog que nunca dorme

O documento nasceu com 5 princípios que viraram a identidade de segurança do projeto:

1. Defense in depth — rede → processo → sandbox → dados → humano
2. Least privilege — cada tool/agente com o MÍNIMO de acesso necessário
3. Sandbox é a fronteira — execução de ferramentas da IA só através do tatu/sandbox.py
4. Padrão do ecossistema — gitleaks, .env fora do git, secrets nunca hardcoded
5. Auditar antes de melhorar — primeiro achar os buracos, depois construir em cima

E o que fecha o ciclo: um watchdog 24h (TatuEngine Security Watchdog) que roda todo dia, fica silencioso quando está tudo OK e só grita no Telegram quando encontra problema. Vigilância contínua, não auditoria de fim de semana.

O roadmap ficou em 4 fases — e a Fase 1 (base) fechou no mesmo dia:

📊 Métricas

🎯 Aprendizados

1. Segurança é acompanhamento, não um documento parado — o SEGURANCA.md não protege nada sozinho; quem protege é o scan diário + o watchdog 24h + a regra no AGENTS.md.
2. Inventariar antes de blindar — o TatuEngine já tinha 80% da proteção; faltava consolidar, documentar lacunas e automatizar a vigilância. Auditar primeiro evita construir o que já existe.
3. O agente mais autônomo precisa da fronteira mais rígida — ToolUse + MCP server + escrita de arquivos = superfície de ataque real. O sandbox é o ponto único de controle, e agora ele tem política formal por trás.
4. Vigilância silenciosa é a melhor vigilância — o watchdog só fala quando tem problema. Sem ruído, sem alerta falso, sem burn-out de notificação.

╔══════════════════════════════════════╗
║  Samuel Medeiros                    ║
║  Senior Software Engineer           ║
║  Stack: Python · TypeScript · Rust  ║
║  Projetos: Arachne, Dogwalk,        ║
║            Capivara, TatuEngine      ║
╚══════════════════════════════════════╝