SECURITY / RUST / AI AGENTS

IronClaw: Agente AI con Seguridad Reforzada por un Co-Autor del Transformer

Una reimplementación en Rust de OpenClaw por Illia Polosukhin, co-autor de "Attention Is All You Need." 12k estrellas. Sandbox WASM por herramienta, vaults de credenciales cifrados con AES-256-GCM, soporte TEE y verificación criptográfica de todos los inputs, outputs y estado.

Por Jose Nobile | 2026-07-26 | 14 min de lectura

¿Qué es IronClaw?

IronClaw es una reimplementación en Rust enfocada en seguridad del framework de agentes AI OpenClaw, desarrollada por Illia Polosukhin y el equipo de NEAR AI. Polosukhin es uno de los ocho co-autores del paper de 2017 "Attention Is All You Need," que introdujo la arquitectura Transformer que sustenta los modelos de lenguaje modernos. Con 12k estrellas en GitHub y licencia dual Apache-2.0 y MIT, IronClaw trae seguridad de grado empresarial al espacio de agentes AI. La última versión es v1.0.0-rc.1 (20 de julio de 2026), una rearquitectura desde cero: un nuevo binario ironclaw con configuración guiada (ironclaw onboard), web UI embebida, 12 extensiones de primera parte, un catálogo de 26 proveedores de modelos, almacenamiento libSQL en archivo con PostgreSQL opcional y gestión de servicios nativa del SO (launchd en macOS, systemd en Linux). No hay ruta de migración desde la configuración, bases de datos ni secretos de v1 — trátalo como una instalación nueva.

La tesis central de IronClaw es que los agentes AI que manejan datos sensibles — credenciales, información financiera, comunicaciones personales — necesitan el mismo rigor de seguridad que el software bancario. Cada herramienta corre en su propio sandbox WASM, las credenciales se almacenan en vaults cifrados con AES-256-GCM, y todos los inputs, outputs y transiciones de estado están firmados criptográficamente para auditabilidad.

Este enfoque de seguridad primero viene del trasfondo de NEAR AI en infraestructura blockchain, donde los ambientes adversariales y las arquitecturas zero-trust son la norma. IronClaw aplica estos principios a sistemas de agentes AI: asumir que cada herramienta, cada respuesta LLM y cada input de usuario podría ser malicioso, y construir defensas en consecuencia.

Modelo de Seguridad

ISOLATION

Sandbox WASM por Herramienta

Cada ejecución de herramienta corre dentro de su propio sandbox WebAssembly con un espacio de memoria dedicado, límite de tiempo de CPU y superficie de system calls restringida. Una herramienta comprometida no puede acceder a la memoria de otras herramientas, al sistema de archivos del host ni a la red a menos que se le otorgue explícitamente. El runtime WASM (Wasmtime) provee rendimiento casi nativo con aislamiento enforced por hardware.

ENCRYPTION

Vaults de Credenciales Cifrados (AES-256-GCM)

Todas las credenciales (API keys, tokens, contraseñas) se almacenan en un vault cifrado usando cifrado autenticado AES-256-GCM. Las credenciales nunca se exponen al agente o herramientas en texto plano. En cambio, el límite del host inyecta credenciales en las instancias WASM de herramientas en tiempo de ejecución, y los valores de credenciales se borran de la memoria inmediatamente después de que la llamada API se completa.

SANDBOXING

Inyección de Credenciales por Herramienta

Cada herramienta declara qué credenciales necesita en su manifiesto. En tiempo de ejecución, el límite del host valida la solicitud, recupera la credencial del vault, la descifra, la inyecta en la memoria lineal de la instancia WASM y la borra después de la ejecución. Las herramientas nunca ven credenciales que no declararon, y el loop del agente nunca tiene acceso a ninguna credencial.

TEE

Soporte de Trusted Execution Environment

IronClaw puede correr dentro de Intel SGX o AMD SEV Trusted Execution Environments, donde todo el proceso del agente está protegido del sistema operativo del host. Esto significa que incluso un SO o hipervisor comprometido no puede acceder a la memoria, credenciales o datos de conversación del agente. El soporte TEE es opcional y requiere hardware compatible.

SCANNING

22 Patrones Regex de Fuga de Credenciales

IronClaw escanea todos los mensajes salientes, outputs de herramientas y respuestas LLM en busca de fugas de credenciales usando 22 patrones regex que cubren claves AWS, tokens GitHub, claves Stripe, JWTs, claves privadas, cadenas de conexión a bases de datos y más. Si se detecta un patrón de credencial, el output se bloquea y se genera una alerta. Esto previene la exposición accidental de secretos a través de alucinaciones LLM o output de herramientas.

CRYPTO

Verificación Criptográfica

Cada input, output y transición de estado en IronClaw está firmado criptográficamente usando Ed25519. Esto crea un rastro de auditoría inmutable: puedes verificar que una herramienta específica produjo un output específico dado un input específico, y que ningún estado intermedio fue alterado. Esto es particularmente valioso para deployments sensibles a cumplimiento en finanzas, salud y dominios legales.

El modelo de seguridad de IronClaw es el más completo en el ecosistema OpenClaw. La combinación de sandboxing WASM, vaults cifrados, inyección de credenciales en el límite del host y verificación criptográfica crea defensa en profundidad que ninguna otra alternativa ofrece. El trade-off es complejidad operacional — desplegar IronClaw requiere entender sus primitivas de seguridad.

Arquitectura

DATABASE

PostgreSQL 15+ con pgvector

IronClaw usa PostgreSQL 15+ con la extensión pgvector para almacenamiento híbrido de memoria. Historial de conversaciones, logs de ejecución de herramientas y memoria semántica se almacenan en la misma base de datos. La búsqueda híbrida combina similitud vectorial (distancia coseno) con matching de palabras clave usando Reciprocal Rank Fusion para calidad de retrieval que supera a cualquiera de los dos enfoques por separado.

COMPONENTS

Arquitectura Multi-Componente

IronClaw corre como cuatro componentes coordinados: el loop del agente (interacción LLM y dispatch de herramientas), el scheduler (cron jobs y triggers de eventos), el orquestador (coordinación multi-agente y descomposición de tareas), y el gateway web (API HTTP/WebSocket y adaptadores de canal). Cada componente puede escalar independientemente.

MEMORY

Búsqueda Reciprocal Rank Fusion

El sistema de memoria combina búsqueda por similitud vectorial (pgvector) con búsqueda full-text por palabras clave (tsvector) usando Reciprocal Rank Fusion. Esto significa que las consultas encuentran resultados que son tanto semánticamente similares como relevantes por palabras clave, evitando los modos de falla de búsqueda vectorial pura (perder coincidencias exactas) y búsqueda por palabras clave pura (perder contenido semánticamente relacionado).

RUNTIME

Rust + Runtime Asíncrono Tokio

Construido en Rust con el runtime asíncrono Tokio para operación de alta concurrencia y baja latencia. El agente puede manejar cientos de conversaciones concurrentes con uso mínimo de recursos. El modelo de ownership de Rust previene data races en tiempo de compilación, lo cual es crítico para un sistema enfocado en seguridad donde el acceso concurrente a credenciales debe estar estrictamente controlado.

La arquitectura multi-componente difiere del enfoque de binario único de ZeroClaw y el diseño de proceso único de Nanobot. IronClaw está diseñado para equipos y organizaciones, no para desarrolladores individuales. La sobrecarga operacional de correr cuatro componentes se justifica por las garantías de seguridad y la escalabilidad independiente que cada componente provee.

Funcionalidades

SCHEDULING

Rutinas Programadas por Cron

Define tareas recurrentes usando expresiones cron o schedules basados en intervalos. Las rutinas pueden encadenar múltiples ejecuciones de herramientas, incluir lógica condicional y producir outputs que se envían a canales configurados. El scheduler corre como un componente separado con su propia recuperación de fallos y lógica de reintentos.

EVENTS

Triggers de Eventos

Define triggers que se disparan cuando ocurren eventos específicos: un nuevo mensaje en un canal monitoreado, un payload de webhook que coincide con un patrón, un cambio de archivo en un directorio monitoreado, o una actualización de fila en la base de datos. Los triggers pueden invocar cualquier herramienta o rutina, habilitando comportamiento reactivo del agente sin polling.

WEBHOOKS

Handlers de Webhooks

El gateway web expone endpoints de webhook configurables que aceptan requests HTTP de servicios externos (GitHub, Stripe, herramientas de monitoreo). Cada handler de webhook valida la firma del request, extrae el payload y lo rutea a la rutina del agente apropiada. Esto habilita integración bidireccional con cualquier servicio que soporte webhooks.

VERIFICATION

Verificación Criptográfica de I/O

Cada input y output de IronClaw está firmado con Ed25519. La cadena criptográfica cubre mensajes de usuario, respuestas LLM, inputs de herramientas, outputs de herramientas y transiciones de estado. Esto crea un log de auditoría a prueba de manipulación que puede ser verificado independientemente por terceros — esencial para industrias reguladas.

Bugs Conocidos

El enfoque en seguridad de IronClaw hace que sus bugs sean particularmente notables. Los siguientes son los issues recientes más notables a junio de 2026. Los dos issues CRÍTICOS del flujo de aprobación (#1485, #1486) fueron corregidos y cerrados a fines de marzo de 2026; los issues arquitectónicos siguen abiertos:

CRITICAL

#1485: Secuestro de Hilo de Aprobación Cross-Canal

Cuando un agente corre a través de múltiples canales (ej: Telegram y Discord), una solicitud de aprobación enviada a un canal puede ser respondida desde el otro canal por un usuario diferente. Esto significa que un usuario con acceso al canal de Discord podría aprobar acciones que estaban destinadas a revisión por un admin de Telegram. La causa raíz es que los hilos de aprobación están indexados por ID de agente en lugar de canal + ID de usuario. La corrección se publicó y el issue se cerró el 31 de marzo de 2026.

CRITICAL

#1486: Race Condition TOCTOU en Hilo de Aprobación

Una condición de carrera time-of-check-to-time-of-use (TOCTOU) existe en el flujo de aprobación. Entre el momento en que un usuario aprueba una acción y el momento en que la acción se ejecuta, los parámetros subyacentes pueden ser modificados por una solicitud concurrente. Esto podría permitir a un atacante obtener aprobación para una acción benigna y luego intercambiarla por una maliciosa. La corrección introdujo semánticas atómicas de aprobación-y-ejecución; el issue se cerró el 31 de marzo de 2026.

MEDIUM

#1249: Lógica de Telegram Infla ExtensionManager

Lógica específica de Telegram para formateo de mensajes, manejo de teclados inline y procesamiento de media se ha filtrado al ExtensionManager central, aumentando su tamaño y complejidad. Esto hace al ExtensionManager más difícil de mantener y testear. La corrección planeada es extraer toda la lógica específica de Telegram a un módulo dedicado de adaptador de canal.

MEDIUM

#1248: Lógica de Canal Hardcodeada Viola la Arquitectura

Varios módulos centrales contienen lógica específica de canal hardcodeada (límites de mensaje de Telegram, formateo de embeds de Discord, IDs de threads de Slack) que debería estar abstraida detrás de la interfaz del adaptador de canal. Esto viola el principio arquitectónico declarado de IronClaw de lógica central agnóstica al canal y hace que agregar nuevos canales sea más difícil de lo que debería.

LOW

#1078: Fallback del Agente Llama routine_delete Sin Nombre

Cuando el handler de error fallback del agente intenta limpiar una rutina fallida, llama a routine_delete sin pasar el parámetro de nombre de rutina. Esto resulta en un no-op (el delete falla silenciosamente) en lugar de la limpieza esperada. Las rutinas fallidas se acumulan en el scheduler hasta que se eliminan manualmente. La corrección fue una adición de parámetro de una línea; el issue se cerró en marzo de 2026.

Los dos bugs CRÍTICOS (#1485 y #1486) eran serios porque socavaban el flujo de aprobación — una funcionalidad de seguridad central. El equipo de IronClaw trató ambos como prioridad P0 y los corrigió a fines de marzo de 2026; si tu deployment depende de aprobación human-in-the-loop, asegúrate de correr una versión de abril de 2026 o posterior. Los issues MEDIUM y LOW son preocupaciones de calidad arquitectónica que no afectan la seguridad o funcionalidad para la mayoría de los usuarios.

Más Guías