Toward Securing AI Agents Like Operating Systems

Este artículo sostiene que asegurar agentes de IA basados en LLM requiere aplicar principios de seguridad de sistemas operativos, demostrando mediante un análisis de arquitectura unificada y un estudio de caso que, aunque algunos riesgos son inherentes, muchas vulnerabilidades pueden mitigarse mediante técnicas establecidas de sistemas operativos como el aislamiento de recursos y la separación de privilegios.

Lo esencial

Imagina que has contratado a un asistente personal súper inteligente e increíblemente entusiasta llamado "Agente". Este asistente puede leer tus correos electrónicos, gestionar tu calendario, reservar vuelos e incluso escribir código por ti. Es como tener un empleado mágico que nunca duerme.

Pero aquí está el truco: le diste a este empleado las llaves de toda tu casa, tu cuenta bancaria y tu diario. Si un ladrón astuto engaña al asistente haciéndole creer que es tú, o lo convence de abrir la puerta trasera, el ladrón obtiene todo.

Este es el problema central que aborda el artículo. Los autores argumentan que estamos construyendo estos agentes de IA como si fueran criaturas mágicas totalmente nuevas, pero en realidad deberíamos tratarlos como Sistemas Operativos (el software que ejecuta tu computadora, como Windows o macOS).

Aquí está el desglose de sus hallazgos, utilizando analogías simples:

1. La Gran Idea: El Agente es el Sistema Operativo

Los autores dicen: "Deja de pensar en la IA solo como un chatbot. Piensa en ella como el SO de tu vida digital".

• La IA (LLM) es el Usuario: En una computadora, el usuario escribe comandos. En un agente de IA, el Modelo de Lenguaje Grande (el "cerebro") es quien escribe los comandos. Pero al igual que un usuario humano puede ser engañado por un correo de phishing, una IA puede ser engañada por un prompt de "jailbreak".
• Las Herramientas son Llamadas al Sistema: Cuando haces clic en "Imprimir" en tu computadora, el SO verifica si tienes permiso. Cuando una IA quiere "enviar un correo electrónico", eso es una herramienta. El artículo argumenta que estas herramientas deben tratarse como llamadas al sistema estrictas, no como comandos sin restricciones.
• El Entorno de Ejecución es el Núcleo: La parte del software que realmente ejecuta el código es el "Núcleo". En una computadora segura, el Núcleo es el jefe. Decide quién tiene acceso a qué. En los agentes de IA actuales, el "Núcleo" suele ser demasiado amable y permite que el "Usuario" (la IA) haga lo que quiera, incluso si es peligroso.

2. El Problema: La Fiesta de "Casa Abierta"

El artículo examina agentes de IA populares (como OpenClaw y sus parientes) y descubre que están construidos como una casa abierta donde cualquiera puede entrar y tocar cualquier cosa.

• Sin Muros: En una computadora segura, los diferentes programas están aislados. Si un virus infecta tu aplicación de calculadora, no debería poder leer tus archivos bancarios. Pero en estos agentes de IA, la "calculadora" (una herramienta) y los "archivos bancarios" (memoria) están todos en la misma habitación. Si la IA se confunde, puede mezclarlos accidentalmente (o maliciosamente).
• La Falacia del "Confía en Mí": Estos agentes dependen de que la IA "recuerde" ser segura. Tienen reglas como "No borres archivos", pero están escritas simplemente en inglés. Si un hacker susurra un truco a la IA, esta olvida la regla. Es como pedirle a un guardia que haga la guardia pero decirle: "Solo usa tu mejor criterio".
• El Riesgo de "Terceros": Estos agentes te permiten instalar "habilidades" (como aplicaciones). Imagina que pudieras descargar una "Aplicación del Clima" que secretamente tuviera una puerta trasera a tu cuenta bancaria. El artículo encontró que muchos de estos agentes te permiten instalar estas habilidades sin verificar si son seguras.

3. El Experimento: Rompiendo los Agentes

Los investigadores tomaron cuatro agentes de IA populares e intentaron romperlos, actuando como un hacker con un nivel modesto de habilidad. No necesitaban ser genios; solo necesitaban saber cómo estaba construida la "casa".

Lo que encontraron:

• OpenClaw (El Agente "Vanilla"): Este era el más popular. Fue vulnerable a cada uno de los ataques que probaron los investigadores. Fue como dejar la puerta delantera, la puerta trasera y las ventanas abiertas de par en par.
• IronClaw (El Agente de "Seguridad"): Este intentó ser más seguro. Puso algunas herramientas en una "caja de arena" (sandbox) (una caja de vidrio donde no pueden tocar el resto de la casa). Lo hizo mejor, pero los investigadores aún encontraron formas de engañarlo o romper el vidrio.
• Nanobot (El Agente "Mínimo"): Este tenía muy poco código, esperando que menos código significara menos errores. Pero incluso con una base de código pequeña, aún carecía de los "muros" básicos necesarios para mantener los datos separados.
• NemoClaw (El Agente "Envoltorio"): Este puso todo el agente dentro de un contenedor seguro (como un contenedor de envío). Fue el más difícil de romper, pero los investigadores aún encontraron una manera de echar un vistazo dentro o engañarlo.

El Resultado Aterrador: Incluso las versiones "seguras" fallaron en cosas básicas, como evitar que un usuario lea las notas privadas de otro usuario, o impedir que el agente envíe mensajes a extraños.

4. La Solución: Tomando Prestado del Pasado

La conclusión principal del artículo es simple: No necesitamos inventar nueva magia para solucionar esto. Solo necesitamos usar las reglas de seguridad que hemos conocido durante 50 años.

Los sistemas operativos han resuelto exactamente estos problemas antes. Los autores sugieren aplicar estas reglas antiguas a la IA:

• Aislamiento: Pon cada herramienta en su propia caja de vidrio (sandbox) para que no pueda tocar otras herramientas o tus archivos privados a menos que se permita explícitamente.
• Mínimo Privilegio: Solo porque el agente puede leer tu correo electrónico no significa que deba. Dale solo las llaves que necesita para la tarea específica en cuestión.
• Registro Endurecido: Mantén un registro de todo lo que hace el agente, pero asegúrate de que el agente no pueda borrar ni cambiar esos registros (como una cámara de seguridad a prueba de manipulaciones).
• Límites Estrictos: No permitas que la IA decida qué es seguro. El "Núcleo" (el sistema) debe hacer cumplir las reglas, no el "cerebro" de la IA.

Resumen

El artículo argumenta que los agentes de IA se construyen actualmente como fronteras salvajes y sin regulación. Son poderosos pero peligrosos porque mezclan datos sensibles con instrucciones no confiables.

Los autores dicen: "Deja de intentar hacer que la IA sea 'más inteligente' para ser segura. En su lugar, construye el sistema a su alrededor como un Sistema Operativo seguro". Si tratamos a la IA como un usuario que necesita ser vigilado y restringido por un guardia de seguridad estricto (el SO), podemos hacer que estas herramientas poderosas sean seguras para usar en nuestros hogares y empresas.

La Conclusión: Estamos construyendo empleados digitales con llaves maestras para nuestras vidas, pero aún no hemos construido las cerraduras, las vallas ni los guardias de seguridad. Es hora de tomar prestados los planos de los expertos en seguridad informática que han estado construyendo esas cerraduras durante décadas.

Resumen técnico

Resumen Técnico: Hacia la Seguridad de Agentes de IA como Sistemas Operativos

Declaración del Problema

Los agentes autónomos basados en Modelos de Lenguaje Grande (LLM) están evolucionando desde asistentes especializados hacia sistemas de propósito general capaces de planificar y ejecutar tareas complejas con acceso a datos sensibles del usuario, archivos locales y servicios externos. Aunque sistemas como OpenClaw ofrecen una utilidad significativa mediante el uso de herramientas y habilidades de terceros, introducen riesgos de seguridad sustanciales. La investigación actual a menudo se centra estrechamente en la inyección de prompts, sin embargo, la superficie de ataque más amplia —que comprende la extensibilidad en tiempo de ejecución, el estado persistente y el acceso no mediado a funcionalidades privilegiadas— permanece subanalizada. Los mecanismos de protección existentes en implementaciones populares de agentes son a menudo insuficientes, fallando en prevenir la exfiltración de datos, la escalada de privilegios o el acceso no autorizado al sistema incluso bajo capacidades de atacante modestas. El artículo argumenta que los desafíos de seguridad que enfrentan los agentes de IA son estructuralmente similares a los resueltos históricamente por los sistemas operativos (SO), sin embargo, los diseños actuales de agentes violan frecuentemente principios fundamentales de seguridad de los SO, como el aislamiento, la separación de privilegios y la mediación.

Metodología

Los autores emplean una metodología de tres vertientes para investigar la seguridad de los agentes:

1. Analogía Conceptual y Derivación de Arquitectura: El artículo establece una analogía estructural entre los agentes de IA y los sistemas operativos. Mapea los componentes del agente a conceptos de SO: el LLM actúa como un usuario no confiable, las herramientas y habilidades corresponden a llamadas al sistema y programas, el tiempo de ejecución del agente funciona como el kernel, y el contexto del agente se asemeja a la memoria del proceso. Basándose en esta analogía, los autores derivan una arquitectura unificada para agentes estilo OpenClaw, identificando componentes clave (núcleo de tiempo de ejecución, núcleo del agente, pasarelas, estado persistente/efímero) y límites de confianza.

2. Mapeo Sistemático de Defensas: Los autores realizan un sondeo de mecanismos de seguridad de SO establecidos (por ejemplo, aislamiento de procesos, sandboxing, principio de menor privilegio, filtrado de red, Prevención de Ejecución de Datos) y los mapean a sus contrapartes agénticas. Analizan qué mecanismos se transfieren directamente, cuáles requieren adaptación y qué capacidades del agente permanecen inseguras por diseño.

3. Estudio de Caso Empírico: Para validar su análisis, los autores evalúan cuatro agentes de estilo OpenClaw de código abierto y ampliamente utilizados que representan diferentes filosofías de diseño:

   • OpenClaw: Una variante "vanilla" enfocada en la amplitud de características.
   • IronClaw: Una variante de "seguridad" que prioriza el aislamiento y el sandboxing.
   • Nanobot: Una variante "minimalista" con una base de código reducida.
   • NemoClaw: Una variante "envoltorio" que ejecuta un agente dentro de un contenedor seguro.

   La evaluación utiliza un entorno controlado (máquinas virtuales Debian 13.4) con monitoreo basado en eBPF para observar llamadas al sistema, acceso a archivos y tráfico de red. Los autores definen un modelo de amenazas donde el atacante tiene conocimiento completo del código fuente pero no acceso directo al hardware o al nivel del host, tratando al LLM como un componente completamente no confiable susceptible a manipulación. Ejecutan una serie de escenarios de ataque realistas dirigidos a interfaces de hardware, aislamiento de procesos, sandboxing, filtrado de red y registro del sistema.

Contribuciones Clave

• Perspectiva de Seguridad de SO en Agentes de IA: El artículo establece una analogía formal entre agentes de IA y sistemas operativos, proporcionando un marco para razonar sobre la seguridad de los agentes utilizando conceptos establecidos como aislamiento, separación de privilegios y mediación.
• Arquitectura Unificada de Agentes: Deriva una arquitectura consolidada para agentes estilo OpenClaw que define explícitamente componentes, límites de confianza y canales de comunicación, facilitando un análisis sistemático de seguridad.
• Transferencia Sistemática de Defensas de SO: Los autores mapean los mecanismos de defensa de SO al dominio agéntico, categorizándolos por su aplicabilidad e identificando brechas donde los diseños actuales de agentes fallan en hacer cumplir principios básicos de seguridad.
• Evaluación Empírica: El estudio proporciona una evaluación empírica exhaustiva de cuatro tiempos de ejecución de agentes populares, demostrando que los mecanismos de protección actuales a menudo fallan en la práctica y que las vulnerabilidades pueden explicarse y mitigarse utilizando técnicas a nivel de SO.

Resultados

El estudio de caso revela que ninguno de los cuatro agentes evaluados puede defenderse contra todos los vectores de ataque probados. Los hallazgos clave incluyen:

• Vulnerabilidades Generalizadas: Incluso los agentes diseñados con la seguridad en mente (por ejemplo, IronClaw) son susceptibles a ataques específicos, como la manipulación de configuración o la extracción de prompts del sistema, a menudo debido a una implementación incompleta del sandboxing o la separación de privilegios.
• Fallo del Aislamiento: Un hallazgo crítico es que los cuatro agentes alimentan datos confiables y no confiables en un contexto compartido de LLM, violando el principio de aislamiento de procesos. Esto permite que las salidas intermedias de una herramienta influyan en herramientas posteriores, habilitando ataques como la inyección de comandos de shell.
• Violaciones de la Separación de Privilegios: El control de acceso a archivos a menudo se hace cumplir al mismo nivel de privilegio que el procesamiento de entrada, en lugar de ser mediado por un monitor de referencia con privilegios más bajos.
• Sandboxing Ineficaz: Aunque el sandboxing (por ejemplo, WebAssembly en IronClaw, contenedores en NemoClaw) puede bloquear efectivamente ciertos vectores de ataque, implementaciones parciales o mal configuradas dejan brechas significativas. Por ejemplo, NemoClaw fue vulnerable a la extracción de prompts del sistema a pesar de su diseño en contenedores.
• Debilidades Universales: Se observaron dos clases de debilidades en todos los agentes: exfiltración de datos entre usuarios (falta de aislamiento de procesos a nivel de usuario) y envío de mensajes no autorizado (falta de filtrado estricto de salida).
• Independencia del LLM: El estudio confirma que estas vulnerabilidades provienen de la arquitectura del agente y el diseño del tiempo de ejecución, más que de capacidades específicas de razonamiento del LLM, ya que los ataques tuvieron éxito en diferentes modelos (Qwen, Gemini, GPT).

Significancia y Afirmaciones

El artículo afirma que asegurar los agentes de IA es una tarea desalentadora debido a su vasta y heterogénea superficie de ataque, pero que se puede lograr un progreso significativo aprovechando décadas de investigación en seguridad de sistemas operativos. Los autores argumentan que:

1. El Análisis Retrospectivo es Valioso: Muchos desafíos de seguridad en los agentes de IA no son enteramente nuevos, sino manifestaciones de problemas clásicos de SO. Revisar los enfoques establecidos de SO proporciona un marco principiado para asegurar sistemas agénticos.
2. Se Requiere Defensa en Profundidad: Confiar únicamente en defensas centradas en el LLM (como la mitigación de inyección de prompts) es insuficiente. La operación segura requiere conocimiento detallado del sistema, configuración cuidadosa e implementación de defensas en capas que incluyen aislamiento, separación de privilegios y mediación.
3. Los Defectos de Diseño son Inherentes a los Sistemas Actuales: Algunas capacidades agénticas permanecen inseguras por diseño porque violan principios fundamentales como el menor privilegio y el aislamiento de procesos. Sin embargo, muchas vulnerabilidades pueden mitigarse utilizando técnicas de SO bien comprendidas.
4. Pasos Accionables Inmediatos: Los autores concluyen que simplemente consolidar los mecanismos de seguridad parciales ya desplegados en diferentes implementaciones (por ejemplo, combinando sandboxing, filtrado de red y registro) produciría mejoras significativas en la seguridad sin requerir investigación novedosa.

El artículo se posiciona no como una solución final, sino como un paso necesario hacia la estructuración de la superficie de ataque de los agentes de IA y la guía del diseño futuro hacia un estado más seguro fundamentado en los principios de seguridad de los SO.