📦 WASM Sandbox vs Docker vs VM
El aislamiento de ejecución es la defensa más importante cuando la IA ejecuta código real. Tres niveles de aislamiento, cada uno con diferentes trade-offs de seguridad, complejidad y rendimiento.
📌 Comparativa de aislamiento
Elección basada en tu caso de uso:
- •WASM: aislamiento máximo, sin acceso a FS/red, overhead mínimo — para evaluación de código
- •Docker: buen aislamiento, acceso controlado mediante volúmenes y poca sobrecarga; uso general
- •VM: aislamiento total con hipervisor, alto overhead; para cumplimiento normativo y datos críticos
- •Ninguno: solo blocklist + audit — para uso estrictamente personal en una máquina dedicada
💡 Consejo práctico
Para un asistente personal en desarrollo, Docker con volúmenes read-only es el equilibrio perfecto: seguridad razonable con máxima practicidad.
🚦 Gates de aprobación — 3 niveles
Las puertas de aprobación son el intervención humana en el proceso de IronClaw. Definen cuándo Jarvis actúa por su cuenta y cuándo necesita tu confirmación explícita.
📌 Los 3 niveles de autonomía
Cada nivel define qué acciones requieren aprobación:
- •Nivel 1 - Solo lectura: solo lee datos, nunca escribe. Sin confirmación. Para uso público.
- •Nivel 2 - Supervisado: cualquier escritura o ejecución requiere confirmación por Telegram. Para uso personal estándar.
- •Nivel 3 - Autónomo: las acciones preaprobadas se ejecutan sin confirmación, pero con auditoría completa. Para tareas rutinarias bien definidas.
💡 Consejo práctico
Usa el Nivel 2 como predeterminado. Para tareas específicas y bien definidas (p. ej., una copia de seguridad diaria), crea una lista de permitidos de acciones que operen en el Nivel 3.
🗺 El stack completo de IronClaw
IronClaw no es una feature: es una arquitectura. Cinco capas independientes que trabajan en conjunto para crear una protección real y auditable.
📌 Las 5 capas en detalle
Cada capa tiene una única responsabilidad:
- •L1 Lista de bloqueo: rechaza de inmediato los comandos prohibidos — costo O(1)
- •L2 Detección de inyección: analiza patrones de manipulación — costo O(n) en el texto
- •L3 Puerta de aprobación: consulta a una persona para acciones de alto impacto — costo ~5s de latencia
- •L4 Sandbox: ejecuta en un entorno aislado — costo de sobrecarga de 50-200ms
- •L5 Auditoría: registra todo de forma inmutable — costo O(1) para agregar registros
💡 Consejo práctico
IronClaw añade ~200-300ms de latencia total con todas las capas activas. Para las conversaciones, es imperceptible. Para los loops de automatización rápida, considera deshabilitar L3 con una allowlist granular.
📊 Monitoreo y alertas
La seguridad sin monitoreo es una defensa ciega. El audit_analyzer.py procesa el registro periódicamente y envía alertas cuando detecta patrones sospechosos.
📌 Patrones monitoreados
Anomalías que activan alertas:
- •5+ intentos de inyección en 1 hora: posible ataque activo
- •Acceso a una ruta fuera del sandbox: intento de bypass
- •Más de 100 ejecuciones de tool en 10 minutos — posible bucle malicioso
- •Costo de API por encima del umbral — posible DoS por facturación
- •Cualquier action='deny' repetida: intento persistente de bypass
💡 Consejo práctico
Configura alertas por Telegram para que el propio Jarvis te notifique de anomalías. Es recursivo, pero funciona: usa un canal separado para las alertas de seguridad.
🧪 Pon a prueba tus defensas
Las defensas que no se prueban no son defensas: son una esperanza. Red team del propio Jarvis valida que cada capa funcione como se espera frente a ataques reales.
📌 Suite de pruebas de seguridad
Pruebas obligatorias después de cada cambio:
- •test_blocklist.py: prueba más de 50 variantes de comandos peligrosos
- •test_injection.py: 20 patrones de inyección conocidos
- •test_path_traversal.py: traversal simple, doble codificación, symlinks
- •test_approval_gate.py: valida que las acciones de alto riesgo requieren confirmación
- •test_audit.py: verifica que el registro captura todas las acciones
💡 Consejo práctico
Ejecuta la suite de seguridad como CI/CD. Cualquier cambio en el código que haga fallar una prueba de seguridad debe bloquearse automáticamente.
📝 Playbook de seguridad
Los incidentes ocurren. Un playbook documentado antes del incidente marca la diferencia entre una respuesta controlada y el pánico.
📌 Los 6 pasos del playbook
Respuesta al incidente en orden:
- •1. KILL SWITCH: python -m intelecto stop — desactiva de inmediato
- •2. PRESERVAR: cp ~/.intelecto/audit.log /secure/backup/incident-$(date).log
- •3. ANALIZAR: python audit_analyzer.py --mode forensic --output report.txt
- •4. REVOCAR: revocar todas las claves API posiblemente comprometidas
- •5. RESTAURAR: python setup.py --restore /secure/clean-backup
- •6. POST-MORTEM: documentar qué pasó, cómo se detectó y qué cambió
💡 Consejo práctico
Practica el playbook en un entorno de prueba antes de necesitar usarlo en producción. No querrás aprender los comandos durante un incidente real.
✅ Resumen del Módulo 3.4
Siguiente:
Ruta 4: Integraciones