Ejecutar NanoClaw en un sandbox de Docker

• Gracias a la colaboración entre NanoClaw y Docker, ahora es posible ejecutar cada agente de IA en un sandbox aislado de Docker con un solo comando
• Cada agente funciona en un contenedor independiente dentro de una micro-VM, con un entorno completamente aislado y sin acceso al sistema host
• Mediante una arquitectura de doble perímetro de seguridad, incluso si ocurre un escape del contenedor, este queda bloqueado a nivel de VM, protegiendo archivos, credenciales y aplicaciones del host
• El modelo de seguridad de NanoClaw sigue un “diseño basado en la desconfianza”, que trata a los agentes como actores potencialmente maliciosos y adopta una estructura para minimizar daños
• A futuro, apunta a ampliar funciones para operar equipos grandes de agentes, como control de compartición de contexto, agentes persistentes, políticas de permisos granulares y procesos de aprobación humana

---

Resumen de la integración con sandbox de Docker

• NanoClaw, en colaboración con Docker, ofrece ejecución en sandbox con un solo comando
  • Compatible con macOS (Apple Silicon) y Windows (WSL), con Linux previsto próximamente
  • El script de instalación automatiza la clonación, configuración y preparación del sandbox
• Cada agente se ejecuta en un contenedor independiente dentro de una micro-VM
  • No se requiere hardware adicional ni configuraciones complejas
  • Cada contenedor tiene su propio kernel y demonio de Docker, y el acceso al host está bloqueado

Cómo funciona

• El sandbox de Docker proporciona aislamiento a nivel de hipervisor y tiene tiempos de arranque rápidos en milisegundos
• NanoClaw se adapta de forma natural a esta estructura
  • Cada agente cuenta con sistema de archivos, contexto, herramientas y sesión independientes
  • Ejemplo: un agente de ventas no puede acceder a mensajes personales, y un agente de soporte no puede acceder a datos del CRM
• La capa de micro-VM forma una segunda barrera de seguridad
  • Incluso si hay un escape del contenedor, la pared de la VM protege el sistema host

Modelo de seguridad: diseño basado en la desconfianza

• NanoClaw está diseñado bajo la premisa de una arquitectura que no confía en los agentes de IA
  • Considera riesgos impredecibles como prompt injection y fallos del modelo
  • Está diseñado para no colocar secretos ni credenciales dentro del entorno del agente
• La seguridad se impone desde fuera del agente, sin depender de que este actúe correctamente
• A diferencia de OpenClaw, NanoClaw ofrece aislamiento completo entre agentes
  • OpenClaw comparte el mismo entorno, por lo que datos personales y de trabajo pueden mezclarse
• Se enfatiza un principio de ingeniería de seguridad que considera a los agentes tanto colaboradores como posibles atacantes

Próximos pasos

• Se plantea la necesidad de construir nueva infraestructura y una capa de runtime para operar equipos grandes de agentes
• NanoClaw ya puede conectarse a varios canales de Slack para operar agentes independientes por función de trabajo
• Cuatro funciones clave propuestas para la siguiente etapa
  • Compartición controlada de contexto: combinar libre intercambio de información dentro del equipo con compartición selectiva entre equipos
  • Creación de agentes persistentes: en lugar de subagentes de un solo uso, miembros de equipo con ID, entorno y datos persistentes
  • Políticas de permisos granulares: control detallado como permitir solo lectura de correos, restringir acceso a ciertos repositorios o establecer límites de gasto
  • Procesos de aprobación humana: las acciones irreversibles se ejecutan tras revisión humana
• NanoClaw se presenta como una capa de runtime y orquestación centrada en la seguridad, y el sandbox de Docker como una base de infraestructura de nivel empresarial
• El objetivo es construir un stack de ejecución de agentes que ofrezca al mismo tiempo aislamiento por defecto, colaboración controlada y visibilidad y gobernanza a nivel organizacional

Resumen de NanoClaw

• NanoClaw es una capa open source de runtime y orquestación segura que permite operar agentes de IA por equipos
• El proyecto puede consultarse en GitHub y se puede apoyar con una estrella

[GN⁺]

Comentarios de Hacker News

• Parece un detalle pequeño, pero si varias nuevas decisiones de diseño se expanden por toda la industria, podrían traer cambios revolucionarios
  Como mencionó Karpathy, la clave está en ofrecer una skill (spec) sobre “cómo escribir integraciones”, en lugar de implementar directamente integraciones como Slack o Discord
  Podría llamarse “Claude native development”, y parece que el ecosistema se moverá del enfoque “batteries-included” al de “fork and customize”
  Aun así, quedan muchos retos por resolver, como cómo distribuir specs para pruebas, validación y seguridad
  Me pregunto si algo así también podría pasar a nivel de OS. Si cada instancia tuviera un sistema inmune fuerte, podría surgir un ecosistema heterogéneo más resistente a ataques

  • Como cada usuario tendría que repetir la misma tarea, parece que la eficiencia bajaría. Creo que es mejor implementarlo una vez y compartirlo entre todos
  • La fortaleza del open source está en la colaboración y el proceso de validación. Así como los LLM al principio generan muchos bugs, las personas también. Yo prefiero personalizar sobre una base ya validada
  • Me hace pensar que podríamos llegar a un mundo donde las funciones se implementen intercambiando archivos de especificación en Markdown en lugar de código

• Al hablar de herramientas de seguridad o sandboxing, siempre hay que dejar claro el modelo de amenazas (threat model)
  El riesgo está en que un agente de IA pueda ejecutar código arbitrario en un host que contiene datos secretos
  Por ejemplo, borrar un buzón, filtrar un calendario o hacer una transferencia equivocada no se evita solo con un sandbox
  Por eso, además del sandboxing, se necesita control de permisos granular por tarea y por herramienta. Ejemplo: “esta solicitud solo puede leer Gmail y no debe poder escribir ni borrar”

  • Totalmente de acuerdo. Además de eso, hacen falta seguimiento del flujo de datos entre herramientas (IFC) y atenuación de privilegios (ocap). Por ejemplo, tendría que poder expresarse una política como “prohibido enviar datos fuera del hilo de correo original”
  • Como decía el artículo “Don’t Trust AI Agents”, los agentes de IA deben diseñarse partiendo de la desconfianza. Hay que asumir fallas o prompt injection y construir estructuras que minimicen el daño
  • Yo hice el framework de agentes centrado en control de políticas smith-core y el gateway smith-gateway. Pero este tipo de debates sobre diseño de seguridad casi no recibe atención en la comunidad
  • Vi un texto interesante: como menciona OpenClaw Sandbox, los permisos son binarios, pero el comportamiento de los LLM es probabilístico, así que ambos conceptos chocan de fondo
  • En realidad ya existen sistemas de permisos tradicionales como IAM, WIF, Macaroons y Service Accounts. Si le preguntas al equipo de seguridad, seguramente ya hay soluciones dentro de la empresa que se pueden aprovechar

• Me gusta NanoClaw. OpenClaw era demasiado complejo, pero NanoClaw es mucho más simple
  Es el primer proyecto que veo que usa Claude Code como interfaz de configuración, y agregar funciones también es divertido y funciona bien

  • Mi instancia de OpenClaw se rompió hace poco. Una actualización arruinó la integración con OpenRouter y el código es demasiado complejo
    Además, el modelo de seguridad no encaja con mi entorno rootless de Kubernetes, así que siempre me causaba problemas
    Por eso me cambié a Nullclaw. También me resulta interesante para aprender, porque puedo depurar mientras aprendo Zig
  • Me da curiosidad qué tipo de workflow se puede hacer en Nanoclaw que no sea fácil de crear con Claude

• El sandbox de Docker es parecido al framework container de Apple
  En macOS sirve muy bien como un runtime nativo mucho más liviano que Docker
  Pero en Linux no quisiera usar un hipervisor. Con Linux namespace ya se puede aislar lo suficiente
  Me pregunto por qué OpenClaw o NanoClaw no ofrecen una imagen oficial de Docker bien configurada

  • Yo uso Apple Container en macOS y Podman en otros sistemas operativos
    Container tiene algunos bugs de red, pero igual vale mucho la pena. Solo hay que ajustar la configuración de DNS
    Me gusta porque no necesito instalar Claude Code ni Node.js en el host

• Más importante que si usa contenedores o no es qué se quiere hacer
  Hasta encontrar cómo gastar tokens en tareas realmente útiles, el runtime es secundario
  Desde el punto de vista de seguridad, no basta con meter un LLM en un contenedor. Lo importante es el alcance de la información accesible
  Si el agente puede acceder a todos los datos, ahí está el verdadero riesgo

  • El sandbox de Docker usa una MicroVM como capa adicional de aislamiento. No es solo un contenedor simple

• La clave está en los permisos finos y el control de políticas
  No se trata solo de qué herramientas puede usar, sino de qué puede hacer con ellas
  Ejemplo: solo leer correos, acceder solo a cierto repositorio, fijar un límite de gasto, etc.
  Con solo sandboxing en Docker, sigue dando desconfianza dejar activos sensibles como cuentas de mensajería en manos de un LLM

• El sandbox de Docker levanta una MicroVM dedicada y un daemon de Docker por cada agente, y además configura un proxy de egress flexible
  Lo estuve haciendo reverse engineering y la implementación es bastante interesante

• NanoClaw no es un producto terminado listo para usar
  Hay que agregar funciones como iMessage por cuenta propia mediante un agente de código
  En otras palabras, Claude hace el papel de compilador

  • Antes había una época en que uno revisaba directamente el ensamblador generado por el compilador
    Los agentes de código todavía están más o menos en ese nivel. Decir últimamente que “los agentes de código mejoraron muchísimo” es exagerado
    Todavía hay que repetirle a Claude cosas como “eso no quedó resuelto, hazlo otra vez”

• Estoy trabajando en una idea parecida a “claws”
  Pero en vez de integrar apps de mensajería, ofrece una TUI cifrada de extremo a extremo
  Ver wingthing.ai / repositorio de GitHub
  Estoy pensando cómo dar soporte para Docker, así que también voy a revisar este proyecto

• Me da curiosidad cuál es el caso de uso claro de Nano/Open-Claw. ¿Se supone que administra mi vida digital por mí?

  • En realidad es simple. Es un cronjob con LLM, o un conector de chat como Telegram o email. Lo primero puede hacerse con cron normal, y lo segundo también con código manual o Gemini Gems
  • Es útil para automatizar trabajo de conocimiento repetitivo como resúmenes de correo, recordatorios de agenda o documentos de briefing
  • La idea es conectarlo con una app de tareas y gestionarlo por mensajes con un bot. Ayuda a mejorar la productividad
  • Yo uso NanoClaw como coach de dieta y ejercicio. Se encarga de gestionar objetivos, planificar comidas, hacer listas del súper y registrar entrenamientos
    Lo pasé a Apple Container y además le agregué memoria a largo plazo basada en LanceDB. Ahora ya no tengo que repetirle siempre lo mismo