📦 WASM Sandbox vs Docker vs VM
O isolamento de execução é a defesa mais importante quando a IA executa código real. Três níveis de isolamento, cada um com trade-offs diferentes de segurança, complexidade e performance.
📌 Comparativo de Isolamento
Escolha baseada no seu caso de uso:
- •WASM: isolamento máximo, sem acesso a FS/rede, overhead mínimo — para code evaluation
- •Docker: bom isolamento, acesso controlado via volumes, overhead baixo — uso geral
- •VM: isolamento total com hypervisor, overhead alto — para compliance e dados críticos
- •Nenhum: apenas blocklist + audit — para uso estritamente pessoal em máquina dedicada
💡 Dica Prática
Para assistente pessoal em desenvolvimento, Docker com volumes read-only é o equilíbrio perfeito: segurança razoável com praticidade máxima.
🚦 Gates de Aprovação — 3 Níveis
Gates de aprovação são o human-in-the-loop do IronClaw. Definem quando o Jarvis age sozinho e quando precisa de sua confirmação explícita.
📌 Os 3 Níveis de Autonomia
Cada nível define quais ações requerem aprovação:
- •Nível 1 - Read-only: só lê dados, nunca escreve. Sem confirmação. Para uso público.
- •Nível 2 - Supervisionado: qualquer escrita/execução requer confirmação via Telegram. Para uso pessoal padrão.
- •Nível 3 - Autônomo: ações pré-aprovadas executam sem confirmação, mas com audit completo. Para tarefas de rotina bem definidas.
💡 Dica Prática
Use Nível 2 como padrão. Para tarefas específicas e bem definidas (ex: backup diário), crie uma allowlist de ações que operam em Nível 3.
🗺 O Stack Completo do IronClaw
IronClaw não é uma feature — é uma arquitetura. Cinco camadas independentes que trabalham em conjunto para criar proteção real e auditável.
📌 As 5 Camadas em Detalhe
Cada camada tem responsabilidade única:
- •L1 Blocklist: rejeita imediatamente comandos proibidos — custo O(1)
- •L2 Injection Detection: analisa padrões de manipulação — custo O(n) no texto
- •L3 Approval Gate: pergunta ao humano para ações de alto impacto — custo ~5s de latência
- •L4 Sandbox: executa em ambiente isolado — custo 50-200ms overhead
- •L5 Audit: registra tudo de forma imutável — custo O(1) append
💡 Dica Prática
O IronClaw adiciona ~200-300ms de latência total com todas as camadas ativas. Para conversas, imperceptível. Para loops de automação rápida, considere desabilitar L3 com allowlist granular.
📊 Monitoramento e Alertas
Segurança sem monitoramento é defesa cega. O audit_analyzer.py processa o log periodicamente e envia alertas quando detecta padrões suspeitos.
📌 Padrões Monitorados
Anomalias que disparam alertas:
- •5+ tentativas de injection em 1 hora — possível ataque ativo
- •Acesso a path fora do sandbox — tentativa de bypass
- •Mais de 100 execuções de tool em 10 minutos — possível loop malicioso
- •Custo de API acima do threshold — possível DoS por billing
- •Qualquer action='deny' repetida — tentativa persistente de bypass
💡 Dica Prática
Configure alertas via Telegram para o próprio Jarvis notificá-lo de anomalias. É recursivo mas funciona — use um canal separado para alertas de segurança.
🧪 Testando Suas Defesas
Defesas não testadas não são defesas — são esperança. Red team do próprio Jarvis valida que cada camada funciona como esperado com ataques reais.
📌 Suite de Testes de Segurança
Testes obrigatórios após cada mudança:
- •test_blocklist.py: testa 50+ variações de comandos perigosos
- •test_injection.py: 20 padrões de injection conhecidos
- •test_path_traversal.py: traversal simples, duplo-encoding, symlinks
- •test_approval_gate.py: valida que ações de alto risco requerem confirmação
- •test_audit.py: verifica que o log captura todas as ações
💡 Dica Prática
Execute a suite de segurança como CI/CD. Qualquer mudança no código que quebre um teste de segurança deve ser bloqueada automaticamente.
📝 Security Playbook
Incidentes acontecem. Um playbook documentado antes do incidente é a diferença entre uma resposta controlada e pânico.
📌 Os 6 Passos do Playbook
Resposta a incidente em ordem:
- •1. KILL SWITCH: python -m intelecto stop — desativa imediatamente
- •2. PRESERVAR: cp ~/.intelecto/audit.log /secure/backup/incident-$(date).log
- •3. ANALISAR: python audit_analyzer.py --mode forensic --output report.txt
- •4. REVOGAR: revogar todas as chaves API possivelmente comprometidas
- •5. RESTAURAR: python setup.py --restore /secure/clean-backup
- •6. POST-MORTEM: documentar o que aconteceu, como foi detectado, o que mudou
💡 Dica Prática
Pratique o playbook em um ambiente de teste antes de precisar usar em produção. Você não quer aprender os comandos durante um incidente real.
✅ Resumo do Módulo 3.4
Próximo:
Trilha 4: Integrações