A principios de febrero de 2026, GitGuardian publicó un informe que debería haber alarmado a todo desarrollador que ejecuta un asistente personal de IA. Su infraestructura de escaneo de secretos había detectado más de 200 credenciales filtradas directamente vinculadas a despliegues de OpenClaw — claves API, contraseñas de bases de datos, tokens OAuth y credenciales de proveedores cloud, dispersas en repositorios públicos, archivos de log e informes de errores. Algunas pertenecían a empresas de salud. Otras a startups fintech. Todas estaban activas.
Unos días después, la Universidad de Northeastern publicó un artículo con un titular que calaba más hondo que cualquier número de CVE: "Por qué el asistente de IA OpenClaw es una 'pesadilla de privacidad'." Los investigadores no se centraron en una única vulnerabilidad. Se centraron en la arquitectura en sí — la forma en que OpenClaw maneja datos, almacena credenciales y expone información del usuario por diseño, no por accidente.
No fueron incidentes aislados causados por usuarios descuidados. Fueron el resultado predecible de ejecutar agentes de IA en entornos donde secretos, datos de usuario y código del agente comparten el mismo espacio de direcciones sin aislamiento entre ellos.
Cómo los secretos acaban donde no deben
La configuración típica de OpenClaw funciona así: lo instalas en tu máquina, configuras tus claves API en variables de entorno y empiezas a chatear. El proceso del agente se ejecuta como tu usuario, con tus permisos, leyendo tus variables de entorno. Cada skill que instalas se ejecuta en el mismo proceso, con el mismo acceso.
Esto significa que cuando le pides a tu asistente de IA que te ayude a depurar un script de despliegue, el agente puede ver tus credenciales de AWS. Cuando un skill procesa tu correo, puede leer tu contraseña de base de datos. Cuando ocurre un error y se registra un stack trace, esas variables de entorno pueden acabar en el archivo de log. Y cuando ese archivo de log se commitea a un repositorio, o se sube a un informe de bug, o se sincroniza con un servicio en la nube — tus secretos son ahora públicos.
Los más de 200 secretos filtrados que encontró GitGuardian no fueron el resultado de 200 errores separados. Fueron el resultado de un único error arquitectónico repetido 200 veces: poner secretos en process.env donde cada pieza de código en el proceso puede leerlos.
El problema se multiplica con los skills y plugins. El sistema de skills de OpenClaw ejecuta código de terceros en el mismo proceso que el agente principal. Un skill malicioso no necesita un exploit para robar tus credenciales — simplemente lee process.env. Un skill mal escrito no necesita filtrar tus datos intencionalmente — simplemente incluye contexto del entorno en un informe de error. La superficie de ataque no es una vulnerabilidad que parchear. Es la arquitectura en sí.
Lo que Northeastern acertó
Los investigadores de Northeastern identificaron algo que la comunidad de seguridad había estado esquivando: el problema de privacidad con los asistentes de IA no tiene que ver con cifrado o autenticación. Tiene que ver con la pregunta fundamental de a qué puede acceder el agente y qué límites existen entre el mundo del agente y el tuyo.
Cuando un agente de IA se ejecuta como tu usuario, con tus permisos, en tu máquina, no hay límite. El agente puede leer tus archivos, tus credenciales, tu historial de navegación, tus claves SSH. Puede acceder a todo lo que tú puedes acceder. Lo único que le impide hacer algo dañino es el prompt — y los ataques de inyección de prompt han demostrado repetidamente que los prompts no son una frontera de seguridad.
Esto es lo que Northeastern quiso decir con "pesadilla de privacidad." No que OpenClaw estuviera robando datos deliberadamente, sino que la arquitectura hacía imposible garantizar que los datos no se filtrarían. El acceso del agente estaba limitado únicamente por los permisos de usuario del sistema operativo, lo que equivale a decir que no estaba limitado de forma significativa en absoluto.
Cómo el aislamiento por contenedores de NanoClaw cambia la ecuación
NanoClaw adopta un enfoque fundamentalmente diferente. Cada agente se ejecuta dentro de su propio contenedor Linux — Apple Container en macOS, Docker en macOS y Linux. El contenedor no es una funcionalidad de conveniencia ni una opción de despliegue. Es el modelo de seguridad.
Cuando envías un mensaje a NanoClaw, el proceso host no ejecuta Claude directamente. Lanza un contenedor, monta solo los directorios específicos a los que ese agente necesita acceso, y pasa el contexto de la conversación. El agente se ejecuta dentro del contenedor con su propio sistema de archivos, su propio espacio de procesos y su propia pila de red. Cuando termina, el contenedor se destruye.
Aquí es donde el manejo de secretos se pone interesante. NanoClaw nunca carga tu ANTHROPIC_API_KEY en process.env. En su lugar, lee la clave del .env en tiempo de ejecución y la pasa al proceso del contenedor vía stdin como un payload JSON. Dentro del contenedor, el agent-runner recibe la clave, la usa para las llamadas a la API, y nunca la escribe en disco ni la exporta al entorno.
Esto significa que incluso si un prompt malicioso engaña al agente para ejecutar `printenv` o `cat /proc/self/environ`, la clave API no está ahí. Existe solo en la memoria del proceso agent-runner, durante la duración de ese único turno de conversación. Un contenedor comprometido no puede filtrar lo que no tiene acceso.
El sistema de montaje añade otra capa. NanoClaw mantiene una lista blanca de directorios que pueden montarse en los contenedores, almacenada fuera del directorio raíz del proyecto. Cada grupo obtiene su propio sistema de archivos aislado — su propio archivo de memoria CLAUDE.md, su propio espacio de trabajo con permisos de escritura. La lista blanca incluye detección de escape por enlaces simbólicos, para que un enlace simbólico manipulado no pueda engañar al sistema de montaje para exponer directorios fuera del conjunto permitido.
Los contenedores también se ejecutan como usuario no-root, con el código fuente del proyecto montado en modo solo lectura. Un agente puede leer el código base para entender el contexto, pero no puede modificar los archivos del host. Las rutas con permisos de escritura están limitadas por grupo y se limpian cuando el contenedor se cierra.
El modelo de aislamiento por grupo
El aislamiento de NanoClaw va más allá de simplemente separar al agente del host. Cada grupo de WhatsApp obtiene su propio contenedor, su propia memoria y su propio sistema de archivos. El Grupo A no puede ver las conversaciones, archivos o memoria CLAUDE.md del Grupo B — no por controles de acceso a nivel de aplicación, sino porque se ejecutan en contenedores físicamente separados con puntos de montaje separados.
Esto importa para un escenario que la mayoría de los asistentes de IA ignoran por completo: dispositivos compartidos y configuraciones multiusuario. Si usas NanoClaw con tu familia, las conversaciones y archivos de tu grupo de trabajo están aislados de las conversaciones y archivos de tu grupo familiar a nivel de contenedor. No hay ningún bug de aplicación que pueda filtrar datos entre grupos, porque el aislamiento lo aplica el runtime del contenedor, no la aplicación.
Tu canal principal de WhatsApp — el mensaje directo con el asistente — sirve como interfaz de administración. Es el único canal que puede gestionar tareas programadas, modificar la configuración y acceder al estado entre grupos. Los canales de grupo están restringidos a su propio sandbox por defecto.
Lo que la industria debería aprender
El informe de GitGuardian y el análisis de Northeastern apuntan a la misma conclusión: los agentes de IA son infraestructura, y la infraestructura requiere seguridad de nivel infraestructura. Ejecutar un agente de IA en el mismo proceso que tus credenciales, con los mismos permisos que tu cuenta de usuario, es el equivalente a ejecutar un servidor web como root sin firewall. Funciona hasta que deja de funcionar, y cuando deja de funcionar, el radio de explosión es todo.
El aislamiento por contenedores no es una idea nueva. La industria del hosting web lo descubrió hace dos décadas — no ejecutas el código de múltiples clientes en el mismo proceso. La industria de bases de datos lo descubrió aún antes — no le das a cada consulta acceso a todas las tablas. Pero el ecosistema de agentes de IA todavía está en su fase de "ejecutar todo como root", y los secretos filtrados y las pesadillas de privacidad son el resultado predecible.
El enfoque de NanoClaw no es la única forma de resolver este problema, pero demuestra que el problema tiene solución sin sacrificar funcionalidad. Los agentes ejecutándose dentro de contenedores pueden seguir buscando en la web, navegando páginas, leyendo y escribiendo archivos, y ejecutando comandos de shell. Simplemente lo hacen dentro de un sandbox donde el radio de explosión de cualquier fallo — ya sea un bug, una inyección de prompt o un skill malicioso — se limita al alcance de ese único contenedor.
Los 200 secretos filtrados que encontró GitGuardian no tenían por qué ocurrir. Ocurrieron porque la arquitectura los hacía inevitables. La solución no es mejor educación del usuario ni una gestión más cuidadosa de credenciales. La solución es una arquitectura donde los secretos no pueden filtrarse porque nunca están en un lugar donde la filtración sea posible.