NanoClaw, el fork de OpenClaw que aísla agentes de IA en contenedores para reducir riesgos

NanoClaw ejecuta agentes de IA en contenedores para aislar datos e integraciones

NanoClaw, el fork de OpenClaw que aísla agentes de IA en contenedores para reducir riesgos

Compartir:

{post_title}

NanoClaw, un nuevo proyecto open source impulsado por el ingeniero de software Gavriel Cohen, busca poner límites reales a los agentes autónomos con una decisión arquitectónica clave: ejecutar agentes de IA en contenedores por defecto, en lugar de confiar únicamente en controles a nivel de aplicación. La propuesta llega tras el auge reciente de OpenClaw y una serie de incidentes de seguridad que han vuelto a encender el debate sobre cuánto se puede confiar en agentes con acceso a herramientas, credenciales y datos.

El contexto no es menor: OpenClaw se popularizó como capa de orquestación para agentes (LLMs con acceso a tooling) y, con ello, aparecieron casos de comportamiento destructivo no intencional. El propio ecosistema ha evidenciado que un “agentic loop” sin restricciones puede borrar información, acceder a integraciones sensibles o ejecutar acciones fuera de lo previsto si el entorno no está adecuadamente aislado.

Agentes de IA en contenedores: el diferencial de NanoClaw

En entrevista, Cohen argumenta que encapsular una plataforma entera “en un contenedor” no resuelve el problema si dentro de ese mismo runtime conviven el agente y todas las integraciones, tokens y superficies de ataque. NanoClaw intenta reducir el radio de explosión ejecutando cada agente en su propio contenedor, con un entorno mínimo centrado en el bucle agente-herramientas, de forma que cada instancia solo vea los recursos estrictamente conectados a ese agente.

El ejemplo que pone es operativo: si un agente está conectado a una integración de mensajería, ese agente no debería tener acceso a todo el histórico o a todos los espacios, sino solo al subconjunto de datos necesarios para la tarea asignada. La idea de fondo es convertir el aislamiento en un “default”, no en una opción, y que el perímetro no dependa de que el agente “se comporte bien”.

Un core pequeño para auditar: miles de líneas frente a cientos de miles

Otro argumento central es la auditabilidad. Cohen sostiene que la base de código de OpenClaw ronda unas 400.000 líneas, lo que complica la revisión comunitaria y erosiona una de las promesas típicas del open source: que más ojos equivalen a menos fallos. NanoClaw, en cambio, se presenta con un “core engine” de alrededor de 4.000 líneas, una cifra que, según su creador, facilita comprender el modelo de seguridad, la arquitectura y los puntos sensibles donde un cambio podría introducir riesgo.

Andrej Karpathy, investigador influyente en el sector, amplificó esa lectura en redes al destacar precisamente el tamaño acotado del proyecto y su ejecución en contenedores “by default”, además de un enfoque de configurabilidad basado en “skills” en lugar de archivos de configuración tradicionales.

NanoClaw se apoya en Claude Code y el Agent SDK de Anthropic

Cohen afirma que empezó a desarrollar NanoClaw a finales de enero con ayuda de Claude Code, y que el proyecto se construye alrededor del Agent SDK de Anthropic para aprovechar optimizaciones ya implementadas en esa capa. En su planteamiento, NanoClaw evita “reinventar la rueda” y prioriza un wrapper más compacto y controlable alrededor de capacidades existentes, en lugar de multiplicar integraciones.

Este punto conecta con el cambio percibido por parte de muchos desarrolladores desde finales de 2025: la mejora en la calidad y coherencia de los modelos ha hecho que los coding agents funcionen con mayor fiabilidad en tareas largas. Aun así, el salto de capacidad también aumenta la urgencia por imponer límites técnicos al acceso a sistemas y datos, especialmente en escenarios de empresa.

De un “sales chief” autónomo a una plataforma: el giro de enfoque

Antes de centrarse en NanoClaw, Cohen explica que estaba construyendo junto a su hermano una agencia de marketing enfocada en IA. En ese trabajo conectaron un agente (en la etapa previa de la herramienta conocida como Clawdbot) a flujos de ventas y a datos operativos, y observaron valor comparable al de un empleado en tareas de seguimiento, recordatorios y gestión de pipeline. Pero, a la vez, dice haber detectado múltiples problemas de seguridad que le impidieron escalar el despliegue a más agentes con más responsabilidades.

Ese conflicto —valor real versus riesgo operativo— es el que NanoClaw intenta resolver con aislamiento por contenedor y una superficie de integraciones más reducida. El objetivo declarado ahora es convertir NanoClaw en una capa de orquestación para agentes que resulte atractiva para organizaciones con requisitos estrictos de control y seguridad.

Por qué el aislamiento importa en agentes con acceso a herramientas

En plataformas agentic, el riesgo no viene solo del modelo: viene del conjunto de permisos, conectores, shells, navegadores autenticados y credenciales persistentes que se ponen al alcance del agente. Separar cada agente en su propio contenedor pretende limitar daños ante errores de razonamiento, prompt injection, cadenas de herramientas mal diseñadas o simples malos entendidos del objetivo.

En términos de gobernanza técnica, el enfoque se alinea con principios de mínimo privilegio y segmentación, comunes en seguridad de infraestructura, pero aplicados a la ejecución de agentes autónomos.

Estado del proyecto y enlaces oficiales

NanoClaw se presenta como proyecto open source y su creador insiste en que mantendrá ese modelo para fomentar contribuciones y revisión externa. Mientras la industria intenta estandarizar cómo desplegar agentes de forma segura, el debate se desplaza desde “qué puede hacer el modelo” hacia “qué le dejamos tocar” y con qué aislamiento.

Con NanoClaw, el foco vuelve a una pregunta incómoda pero inevitable: si los agentes ya pueden operar como “empleados de software”, la seguridad no puede depender de su buen comportamiento. La apuesta por agentes de IA en contenedores coloca el aislamiento como línea base para que la automatización no se convierta en un nuevo vector de incidentes dentro de la propia organización.

Compartir:

Déjanos tu comentario

Scroll al inicio