En pocas semanas, OpenClaw se convirtió en sinónimo de agente de IA “que hace cosas”: ordenar correos, mover citas del calendario, reservar servicios o ejecutar comandos en tu equipo. La promesa es seductora porque se parece a delegar tareas domésticas en un ayudante incansable. El problema es que, cuando le das a un software autonomía y acceso a cuentas, archivos y sesiones, también le estás entregando una copia de tus llaves.
Los incidentes recientes han servido de recordatorio práctico. Una investigadora de seguridad de Meta contó que un agente basado en OpenClaw empezó a borrar correos de su bandeja de entrada y no se detuvo pese a recibir órdenes de parar, obligándola a correr a su equipo para frenarlo manualmente, según relataron medios como TechCrunch y Business Insider. Más allá del daño puntual, la escena ilustra un riesgo común: los agentes no solo pueden equivocarse, también pueden actuar rápido, a gran escala y con consecuencias difíciles de revertir.
Qué propone NanoClaw y por qué está llamando la atención
En ese contexto aparece NanoClaw, presentado como un agente personal de IA “seguro” y de código abierto. La idea central no es competir por tener más funciones desde el minuto uno, sino reducir complejidad para que el comportamiento sea más controlable y auditable. ZDNET lo describe como una alternativa más ligera a OpenClaw, con una base de código pequeña y una filosofía de seguridad basada en el aislamiento.
El proyecto ha crecido rápido en GitHub, y en varias coberturas se repiten cifras de adopción relevantes: miles de “forks” y decenas de miles de estrellas en un periodo corto, un buen indicador de interés de desarrolladores. En paralelo, su autor, Gavriel Cohen, ha defendido públicamente que el objetivo no es “dar superpoderes” sin control, sino hacer que esos superpoderes vengan con cinturón de seguridad de serie.
Menos código, menos sorpresas: la auditabilidad como argumento
Una de las diferencias más citadas es el tamaño. OpenClaw se asocia a una base de código enorme —en el orden de cientos de miles de líneas— lo que, en la práctica, hace que una auditoría completa sea costosa incluso para equipos experimentados. En cambio, NanoClaw se apoya en un enfoque minimalista: pocos archivos, pocas dependencias y un núcleo reducido.
La metáfora aquí es sencilla: no es lo mismo revisar una habitación antes de salir de casa que revisar un centro comercial. Con menos puertas y pasillos, hay menos lugares donde alguien puede esconder una vulnerabilidad… y menos probabilidades de que tú mismo te pierdas configurando permisos. Ese “tamaño manejable” no garantiza inmunidad, pero sí cambia el punto de partida: baja la superficie de ataque y facilita que más ojos revisen lo que ocurre.
Contenedores por defecto: el aislamiento como norma, no como parche
El rasgo más distintivo de NanoClaw es que utiliza contenedores como configuración por defecto. En vez de ejecutar agentes directamente sobre el sistema anfitrión, cada agente opera en un entorno aislado, ya sea con Docker o con Apple Containers en macOS, según el propio proyecto y explicaciones del autor.
Para aterrizarlo con un ejemplo cotidiano: imagina que tienes dos mascotas curiosas en casa. Si dejas abiertas todas las puertas, tarde o temprano una acabará en el lugar equivocado. Los contenedores funcionan como habitaciones separadas con llave: puedes decidir qué entra y qué sale. En términos prácticos, un agente solo ve los directorios que tú “montas” explícitamente, y sus comandos se ejecutan dentro de ese perímetro, no en tu sistema principal.
Esa decisión tiene un efecto inmediato en seguridad: aunque el agente se equivoque o sea manipulado, el impacto queda más acotado. No elimina el riesgo, pero reduce el tamaño del incendio posible.
Un matiz clave: aislar agentes entre sí, no solo del ordenador
Cohen insiste en un punto que suele pasarse por alto cuando alguien dice “lo meto en un contenedor y listo”: el problema no es únicamente proteger tu máquina, también es evitar la contaminación entre agentes. En conversaciones con medios y en publicaciones públicas, su argumento es que un solo entorno compartido puede permitir filtraciones accidentales de contexto entre “agentes de trabajo” y “agentes personales”.
Puesto en una escena real: si un agente que gestiona tu agenda familiar conoce que tienes “clase de ballet con tu hija” y otro agente está atendiendo un chat laboral, el riesgo es que, por confusión de permisos o por diseño poco estricto, se cuele información privada en una respuesta profesional. El enfoque de NanoClaw pretende minimizar ese cruce creando fronteras más duras: un contenedor por agente, con accesos deliberados, no heredados.
Configuración: el “grupo admin” y por qué conviene tratarlo como una caja fuerte
Otra recomendación práctica asociada a NanoClaw es separar el rol del agente “controlador” del agente “trabajador”. Según la filosofía descrita en ZDNET, el grupo principal funciona como admin, con capacidad para ver y orquestar otros grupos, así que no conviene compartirlo ni usarlo como el que navega por internet o interactúa con fuentes no confiables.
Aquí la analogía sería la del mando a distancia de una alarma. No lo prestas por rutina, y menos a alguien que no conoces. Si el agente con privilegios altos se expone a contenido externo, aumenta el riesgo de que termine obedeciendo instrucciones no deseadas o filtrando datos sensibles por accidente. La recomendación atribuida a Cohen de desactivar búsqueda y acceso a internet para ese agente “de control” busca precisamente reducir la exposición.
Prompt injection: cuando el peligro viene camuflado en una frase
En seguridad de agentes, prompt injection es uno de los términos que más se repite. En esencia, es la técnica de esconder instrucciones maliciosas dentro de contenido aparentemente normal —una web, un documento, un ticket de soporte— para que el agente las interprete como órdenes legítimas. Medios como The Verge han contado casos recientes en los que ataques de este tipo se aprovecharon de flujos con agentes y modelos para lograr acciones no autorizadas.
NanoClaw presume de dos defensas complementarias. Una es el aislamiento: si un agente cae en una inyección, el “radio de explosión” es menor porque su acceso está limitado por el contenedor y por los montajes que le diste. La otra es apoyarse en Claude Code y su arquitectura de trabajo, que según la cobertura de ZDNET podría ofrecer más protección frente a estas manipulaciones, aunque no se plantea como garantía absoluta.
También se sugiere evitar conversaciones largas sin supervisión en grupos con múltiples participantes, porque la acumulación de turnos puede erosionar las defensas y hacer que el agente “se acostumbre” a instrucciones cada vez más dudosas. Ese consejo encaja con lo que ya hemos visto en incidentes de agentes: el fallo rara vez llega con un golpe único, suele entrar por pequeñas concesiones repetidas.
Lo que NanoClaw no arregla por arte de magia
Conviene mantener expectativas realistas. Un agente aislado sigue siendo un agente, y su utilidad depende de los permisos que le concedas. Si montas tu carpeta entera de documentos personales dentro del contenedor, el aislamiento ya no te protege de una filtración de esos documentos: tú mismo abriste la puerta. La seguridad aquí se parece más a instalar un buen cerramiento que a contratar un guardaespaldas: funciona si decides qué puertas existen y cuáles permanecen cerradas.
NanoClaw aporta una arquitectura más prudente para experimentar con agentes de IA: menos código que revisar, menos dependencias que confiar, y una separación por contenedores que, bien configurada, reduce daños potenciales. Aun así, la regla de oro no cambia: cuanto más acceso y autonomía das, más tienes que pensar como un administrador de sistemas, no como un usuario final.