Asegurar los agentes IA como sistemas operativos: el plano del CISPA

What is this?

El 14 de mayo de 2026, Lukas Pirch y seis coautores del CISPA Helmholtz Center y la TU Berlín — entre ellos Thorsten Holz y Konrad Rieck — publicaron Toward Securing AI Agents Like Operating Systems en arXiv (2605.14932, cs.CR, licencia CC-BY 4.0). El artículo no anuncia una nueva clase de exploits. Hace algo más útil para quienes construyen: sostiene que los agentes LLM han reinventado los problemas de seguridad que los sistemas operativos resolvieron en los años setenta, y que la misma caja de herramientas — aislamiento de procesos, separación de privilegios, mediación de comunicaciones — es la salida realista.

Los autores respaldan la analogía con un estudio de caso práctico. Construyeron una arquitectura unificada que cubre las principales pilas de agentes de código abierto, proyectaron las superficies de ataque sobre ella y aplicaron el mismo modelo de amenaza a cuatro agentes tipo OpenClaw ampliamente desplegados. El resultado principal es contundente: dos clases de debilidades — exfiltración entre usuarios y salida de red no autorizada — rompen todos los agentes probados, con capacidades modestas del atacante.

How it works

El artículo representa un agente como cuatro piezas conectadas: un núcleo de planificación (el LLM), una capa de herramientas (skills, servidores MCP, navegadores, shells), una capa de memoria (contexto a corto plazo y almacenes a largo plazo) y un límite de sesión (estado por usuario). Cada pieza se mapea sobre un concepto de SO para el que la literatura ya tiene vocabulario.

Operating system              LLM agent
-----------------             -----------------
Process                  ≈    Session
Process isolation        ≈    Per-user state separation
User vs. kernel          ≈    Trusted plan vs. untrusted tool output
Capabilities / syscalls  ≈    Tool-call ACLs
File system permissions  ≈    Memory + RAG read/write policies
Network namespace        ≈    Egress policy for the agent process
IPC mediation            ≈    Inter-agent / inter-skill communication

A partir de este mapa, el artículo enumera dos familias de debilidades que sobrevivieron en todos los sistemas evaluados:

• PI-1 — Exfiltración entre usuarios. Los agentes que comparten un almacén de memoria de backend, una caché de herramientas o un índice de skills entre sesiones permiten que el contenido de un usuario (documentos, historial de conversación, secretos pegados anteriormente) sea recuperado por la sesión de otro, a veces con una sola consulta bien construida. El equivalente en SO es la ausencia de aislamiento de procesos por usuario: todas las sesiones leen del mismo espacio de direcciones.
• NF-1 — Envío de mensajes no autorizado. Incluso los agentes anunciados como “solo respuesta” salen al exterior con regularidad: peticiones HTTP que el desarrollador creía aisladas, servidores MCP que actúan de proxy hacia servicios upstream, skills que envían silenciosamente correos o publicaciones. No hay cortafuegos de egreso sobre el proceso del agente, y en cuanto una herramienta puede emitir cualquier petición saliente, las vías de exfiltración se multiplican.

El artículo documenta ambas debilidades con montajes reproducibles pero — siguiendo las buenas prácticas de divulgación — sin publicar payloads explotables. La tesis es estructural, no anecdótica: incluso con “capacidades modestas del atacante” (una sola cuenta de usuario, un único documento subido, una sola skill instalada), ambas fronteras caen.

El trabajo converge con resultados próximos de esta misma temporada. El advisory de Microsoft Security del 7 de mayo de 2026 sobre RCE en frameworks de agentes IA mostró que los prompts se convierten en shells cuando el runtime mezcla los privilegios del plan y de la ejecución. El OWASP GenAI Exploit Round-up Q1 2026, publicado el 14 de abril de 2026, observa lo mismo a escala de incidentes: las fallas ya no son solo sobre salidas del modelo, sino sobre identidades, capas de orquestación y cadenas de suministro. El artículo del CISPA aporta el encuadre de “seguridad de sistemas” que faltaba a esos informes.

Why it matters

Tres puntos generalizan más allá del propio artículo.

Primero, el fallo es arquitectónico, no conductual. Ni un mejor clasificador de seguridad, ni un prompt de sistema más estricto, ni un filtro de jailbreak más fino resuelven PI-1 o NF-1. Un modelo que siga perfectamente sus instrucciones igualmente fuga entre sesiones si estas comparten backend, y sigue marcando a casa si su capa de herramientas puede resolver nombres de host externos. Las defensas centradas solo en la salida del modelo apuntan a la capa equivocada.

Segundo, la literatura de SO es aquí inusualmente generosa. Aislamiento de procesos, capabilities (Capsicum, seL4), control de acceso obligatorio (SELinux, AppArmor), namespaces de red, mediación IPC: no son artefactos de investigación. Son treinta años de ingeniería auditada, desplegada y operativa. Las recomendaciones del artículo no piden a los constructores de agentes inventar primitivas; les piden usar las que ya existen.

Tercero, los ecosistemas tipo MCP amplifican el radio de impacto. Un único registro de skills compartido, un único almacén de memoria multiinquilino, un único servidor MCP con permisos amplios: el valor de estas arquitecturas reside precisamente en que comparten estado, y ese compartido se convierte en la superficie de ataque. El artículo conecta con la tendencia más amplia descrita en Careful Adoption of Agentic AI Services de CISA: las decisiones de adquisición y diseño de agentes son ahora decisiones de seguridad de primer orden.

Defenses

Las recomendaciones del artículo se traducen directamente en controles aplicables hoy.

1. Ejecute cada sesión en su propio proceso o contenedor. Sin rutas de escritura compartidas en el sistema de ficheros, sin memoria común, sin caché que mezcle contenidos de distintos usuarios. La garantía a nivel SO es la que detiene PI-1; todo lo que se haga por encima sigue siendo best-effort.
2. Deniegue por defecto la salida de red del proceso del agente. Liste explícitamente el pequeño conjunto de hosts que el agente debe alcanzar legítimamente (su pasarela de modelo, sus backends de herramientas). Trate cualquier otra resolución DNS o petición HTTP como violación de política, regístrela y corte el flujo antes de que la respuesta vuelva al modelo. Con un cortafuegos de egreso real, NF-1 desaparece.
3. Trate cada salida de herramienta como entrada no confiable. Aplique el mismo taint-tracking que aplicaría a datos enviados por un usuario: las respuestas de herramientas pueden transportar instrucciones, enlaces o cargas codificadas, y el LLM planificador no debe actuar sobre ellas sin confirmación fuera de banda en cualquier acción que modifique estado.
4. Acote cada llamada de herramienta con capabilities. Una herramienta “listar ficheros” no debe poder leer rutas arbitrarias. Una herramienta “obtener URL” no debe poder hacer POST. ACLs por herramienta, scopes de token por sesión y mínimo privilegio por defecto cierran la mayor parte del movimiento lateral descrito en el artículo.
5. Medie la comunicación entre agentes y entre skills. Trate las llamadas A → B y las cadenas skill → skill como IPC: esquema validado, rate limit, registro y revocabilidad. El artículo lo plantea como el equivalente agéntico de la mediación IPC del SO; y es precisamente la superficie que el análisis de Microsoft sobre RCE señaló como la vía de escalada más accesible.
6. Audite las cuatro capas en su propio agente. La arquitectura unificada del §3 del artículo es una plantilla útil: recorra las capas de planificación, herramientas, memoria y límite de sesión, y verifique que cada una tiene un responsable nombrado, una política escrita y un control que la aplique. Lo que quede implícito será el próximo post-mortem.

Status

Ítem	Referencia	Fecha	Notas
Artículo publicado	arXiv:2605.14932v1	2026-05-14	cs.CR, 17 páginas, CC-BY 4.0
Instituciones	CISPA Helmholtz Center, TU Berlín	2026-05-14	Equipo Holz / Rieck
Sistemas evaluados	4 agentes tipo OpenClaw	2026-05-14	Proveedores anonimizados en el artículo
Fallas universales	PI-1 (exfiltración entre usuarios), NF-1 (egreso no autorizado)	2026-05-14	100 % de los sistemas probados
Advisory cercano	Microsoft “Prompts become shells”	2026-05-07	RCE en frameworks de agentes IA
Corpus de incidentes cercano	OWASP GenAI Exploit Round-up Q1 2026	2026-04-14	Identidades, orquestación, cadena de suministro
Encuadre político cercano	CISA Careful Adoption of Agentic AI Services	2026	Controles desde la compra

Ninguna medida aislada elimina PI-1 o NF-1. La contribución del artículo del CISPA es nombrar una categoría de fallo — estamos operando sistemas multiusuario sin las primitivas de aislamiento que esos sistemas exigen — y señalar el estante de herramientas bien probadas que ya lo resuelven. En el marco de los autores, un despliegue de agente en 2026 cuyo modelo de amenaza se detenga en escáneres de inyección de prompts y filtros de salida es un sistema operativo sin aislamiento de procesos: aún no se equivoca sobre el comportamiento del modelo, pero ya se equivoca sobre el diseño del sistema.