No confíes en los agentes de IA

Cuando trabajas con agentes de IA, deberían tratarse como no confiables y potencialmente maliciosos. Ya sea que te preocupe la inyección de prompts, un modelo intentando escapar de su sandbox, o algo en lo que nadie ha pensado aún, independientemente de cuál sea tu modelo de amenazas, no deberías confiar en el agente. El enfoque correcto no son mejores controles de permisos ni listas de permitidos más inteligentes. Es una arquitectura que asume que los agentes se van a comportar mal y contiene el daño cuando lo hacen.

Ese es el principio sobre el que construí NanoClaw.

No confíes en el proceso

OpenClaw se ejecuta directamente en la máquina host por defecto. Tiene un modo de sandbox con Docker opcional, pero viene desactivado de fábrica, y la mayoría de los usuarios nunca lo activan. Sin él, la seguridad depende completamente de controles a nivel de aplicación: listas de permitidos, confirmaciones, un conjunto de comandos “seguros”. Estos controles parten de una confianza implícita en que el agente no va a intentar hacer algo indebido. Una vez que adoptas la mentalidad de que un agente es potencialmente malicioso, es evidente que los bloqueos a nivel de aplicación no son suficientes. No proporcionan seguridad hermética. Un agente determinado o comprometido puede encontrar formas de eludirlos.

En NanoClaw, el aislamiento por contenedores es una parte fundamental de la arquitectura. Cada agente se ejecuta en su propio contenedor, ya sea en Docker o en un Apple Container en macOS. Los contenedores son efímeros: se crean nuevos en cada invocación y se destruyen después. El agente se ejecuta como un usuario sin privilegios y solo puede ver los directorios que se han montado explícitamente. El límite del contenedor lo impone el sistema operativo.

No confíes en otros agentes

Incluso cuando el sandbox de OpenClaw está activado, todos los agentes comparten el mismo contenedor. Podrías tener un agente como asistente personal y otro para el trabajo, en diferentes grupos de WhatsApp o canales de Telegram. Todos están en el mismo entorno, lo que significa que la información puede filtrarse entre agentes que se supone acceden a datos distintos.

Los agentes no deberían confiar entre sí más de lo que tú confías en ellos. En NanoClaw, cada agente obtiene su propio contenedor, sistema de archivos y historial de sesión de Claude. Tu asistente personal no puede ver los datos de tu agente de trabajo porque se ejecutan en sandboxes completamente separados.

El límite del contenedor es la capa de seguridad dura: el agente no puede escapar de él independientemente de la configuración. Además, una lista de montajes permitidos en ~/.config/nanoclaw/mount-allowlist.json actúa como una capa adicional de defensa en profundidad: existe para evitar que el usuario monte accidentalmente algo que no debería estar expuesto, no para evitar que el agente escape. Las rutas sensibles (.ssh, .gnupg, .aws, .env, private_key, credentials) están bloqueadas por defecto. La lista de permitidos reside fuera del directorio del proyecto, por lo que un agente comprometido no puede modificar sus propios permisos. El código de la aplicación host se monta como solo lectura, así que nada de lo que haga un agente puede persistir después de que el contenedor se destruya.

Las personas en tus grupos tampoco deberían ser de confianza. Los grupos no principales son no confiables por defecto. Otros grupos, y las personas en ellos, no pueden enviar mensajes a otros chats, programar tareas para otros grupos ni ver los datos de otros grupos. Cualquiera en un grupo podría enviar una inyección de prompt, y el modelo de seguridad tiene eso en cuenta.

No confíes en lo que no puedes leer

OpenClaw tiene casi medio millón de líneas de código, 53 archivos de configuración y más de 70 dependencias. Esto rompe la premisa básica de la seguridad del código abierto. Chromium tiene más de 35 millones de líneas, pero confías en los procesos de revisión de Google. La mayoría de los proyectos de código abierto funcionan al revés: se mantienen lo suficientemente pequeños para que muchos ojos puedan revisarlos. Nadie ha revisado las 400,000 líneas de OpenClaw. Fue escrito en semanas sin un proceso de revisión adecuado. La complejidad es donde se esconden las vulnerabilidades, y el análisis de Microsoft lo confirmó: los riesgos de OpenClaw podrían surgir a través de llamadas API normales, porque ninguna persona podía ver el panorama completo.

NanoClaw es un solo proceso y un puñado de archivos. Dependemos en gran medida del Claude Agent SDK de Anthropic, el wrapper alrededor de Claude Code, para la gestión de sesiones, la compactación de memoria y mucho más, en lugar de reinventar la rueda. Un desarrollador competente puede revisar toda la base de código en una tarde. Esta es una restricción deliberada, no una limitación. Nuestras directrices de contribución solo aceptan correcciones de errores, correcciones de seguridad y simplificaciones.

La nueva funcionalidad llega a través de skills: instrucciones con una implementación de referencia completa y funcional que un agente de programación integra en tu base de código. Revisas exactamente qué código se va a añadir antes de que se aplique. Y solo añades las integraciones que realmente necesitas. Cada instalación termina siendo unos pocos miles de líneas de código adaptadas a los requisitos exactos del propietario.

Esta es la diferencia real. Con una base de código monolítica de 400,000 líneas, incluso si solo habilitas dos integraciones, el resto del código sigue ahí. Sigue cargado, sigue siendo parte de tu superficie de ataque, sigue siendo alcanzable por inyecciones de prompts y agentes descontrolados. No puedes separar lo que está activo de lo que está inactivo. No puedes auditarlo porque ni siquiera puedes definir el límite de lo que es “tu código”. Con los skills, el límite es obvio: son unos pocos miles de líneas, es todo código que elegiste añadir, y puedes leer cada línea. El núcleo en realidad se está haciendo más pequeño con el tiempo: el soporte de WhatsApp, por ejemplo, se está extrayendo y empaquetando como un skill.

Diseña para la desconfianza

Si una alucinación o un agente que se comporta mal puede causar un problema de seguridad, entonces el modelo de seguridad está roto. La seguridad tiene que imponerse fuera de la superficie agéntica, no depender de que el agente se comporte correctamente. Los contenedores, las restricciones de montaje y el aislamiento del sistema de archivos existen para que, incluso cuando un agente haga algo inesperado, el radio de explosión esté contenido.

Nada de esto elimina el riesgo. Un agente de IA con acceso a tus datos es inherentemente una situación de alto riesgo. Pero la respuesta correcta es hacer que esa confianza sea lo más estrecha y verificable posible. No confíes en el agente. Construye muros a su alrededor.

Puedes leer el código fuente y el modelo de seguridad completo de NanoClaw; son lo suficientemente cortos como para leerlos en una tarde.