Agent libOS: que la frontera de autoridad sea el runtime, no el wrapper de la herramienta

En la mayoría de los stacks de agentes actuales, el hecho de que el modelo vea una herramienta write_file es exactamente el mismo hecho de que el runtime tenga autoridad para escribir en disco. Un artículo del 2 de junio de 2026, Agent libOS (arXiv:2606.03895, cs.OS), sostiene que esa confusión es la razón estructural por la que la seguridad a nivel de wrapper sigue fallando, y esboza un runtime donde ambas cosas se separan deliberadamente.

¿Qué es esto?

Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents fue publicado en arXiv por Yingqi Zhang el 2 de junio de 2026. No es un nuevo ataque ni un nuevo modelo. Es un diseño de runtime: un sustrato inspirado en los library-OS que se asienta sobre un sistema operativo anfitrión convencional y trata a cada agente como un AgentProcess, un sujeto planificable con identidad de proceso, linaje padre-hijo, ciclo de vida, capacidades explícitas, memoria de objetos tipada, colas de aprobación humana, puntos de control y registros de auditoría.

La regla central del artículo cabe en una frase: las herramientas son wrappers tipo libc; las primitivas del runtime son la frontera de autoridad. Es decir, el esquema de herramienta expuesto al modelo es solo una superficie de comodidad, como una llamada a la biblioteca estándar de C. Si la operación subyacente puede realmente tocar un archivo, un objeto, el reloj, a un humano o el registro de herramientas se decide una capa más abajo, en la primitiva, bajo capacidades y políticas explícitas.

Cómo funciona

Agent libOS divide tres decisiones que un registro de herramientas convencional fusiona en silencio. La visibilidad —si el proceso puede ver el esquema de la herramienta— la gobierna una tabla de herramientas propia del proceso. La invocación —si el proceso puede enviar esa llamada— la verifica un broker. La autoridad —si la operación resultante puede alcanzar un recurso protegido— la verifica el gestor de primitivas. El invariante resultante es contundente: la visibilidad de una herramienta no implica autoridad sobre un recurso. Un proceso puede ver write_text_file y no tener autoridad de escritura sobre ninguna ruta.

La analogía con el SO se lleva hasta las operaciones de ciclo de vida. spawn crea un hijo con su propio namespace y una vista de memoria limitada al objetivo, no una copia de la transcripción del padre. fork atenúa la vista de memoria y el presupuesto del hijo y, en el prototipo, no hereda la autoridad de escritura de archivos del padre salvo concesión explícita. exec reemplaza la imagen y la tabla de herramientas de un agente pero conserva el identificador de proceso y no concede automáticamente las capacidades de la nueva imagen, por lo que no puede escalar. La memoria de objetos sigue la tradición object-capability: conocer el nombre de un objeto almacenado no permite leerlo sin la capacidad adecuada. Nada de esto es comportamiento diferenciable del modelo: es fontanería, aplicada de forma determinista.

El autor es explícito sobre el alcance. El prototipo es un sustrato en Python con planificación asíncrona, memoria de objetos local al namespace, aprobación humana integrada en el runtime, concesiones de permiso de un solo uso, herramientas Deno/TypeScript generadas al vuelo detrás de un broker de llamadas al sistema, y una batería de 123 pruebas de regresión que cubren contención, revocación, atenuación en fork/exec y la «pureza de los wrappers». No es aislamiento a nivel de kernel, ni verificación formal, ni un planificador que puntúe más alto en los benchmarks de tareas.

Por qué importa

El modelo de amenaza es la parte que conviene leer dos veces. Agent libOS apunta justo a los modos de fallo que el campo redescubre una y otra vez: la inyección de prompt que induce una herramienta de alto riesgo, la inyección a través de la salida de una herramienta que altera una decisión posterior, el escape de ruta fuera de un espacio de trabajo, la fuga de capacidades vía fork, las herramientas generadas que importan APIs peligrosas, y la «confusión entre pertenecer a la tabla de herramientas y tener autoridad sobre un recurso externo». Ese último punto es el Trío Letal y el problema del diputado confundido enunciados como un fallo de sistema y no de modelo.

Es importante señalar que el artículo no afirma resolver la inyección de prompt semántica. Un documento malicioso —del tipo sistematizado por primera vez por Greshake et al. en 2023— todavía puede persuadir al modelo de solicitar una acción peligrosa. La afirmación es más estrecha y más honesta: esa solicitud aun así choca contra un control de capacidad, una política, una aprobación humana si se requiere, y un registro de auditoría, en la frontera de la primitiva. Los contenedores y las microVM protegen al anfitrión del código no confiable, pero, como señala el artículo, no deciden por sí mismos qué acción dentro del sandbox está autorizada en nombre de qué usuario. Esa es la brecha que intenta cubrir Agent libOS, y es la brecha que benchmarks como AgentDojo muestran una y otra vez atravesada por las defensas a nivel de wrapper.

Defensas

El diseño se lee como una lista de verificación aplicable sin adoptar el prototipo.

1. Deje de tratar el registro de herramientas como una lista de control de acceso. Separe «el modelo puede ver esta herramienta» de «esta operación está autorizada». Si su única frontera es un wrapper que llama directamente al anfitrión, una instrucción inyectada que alcanza al planificador alcanza al anfitrión.
2. Coloque el control de política en la primitiva, no en el prompt. Las operaciones de archivo, red, shell, reloj, objeto y registro de herramientas deben pasar cada una por un gestor que consulte una capacidad explícita antes de actuar, en el mismo lugar donde auditaría, no en un cuadro de confirmación que envuelve una función.
3. Atenúe la autoridad en fork, spawn y generación de herramientas. Un hijo o una herramienta generada al vuelo debe empezar con menos autoridad que su padre, nunca con los derechos ambientales del padre por defecto. Es la versión agéntica de soltar privilegios.
4. Haga que los nombres no sean capacidades. Descubrimiento y autoridad son distintos: saber que un objeto, ruta o herramienta existe no debe conceder el derecho a usarlo.
5. Haga de la aprobación humana y la auditoría operaciones de primera clase, reanudables. La aprobación debe ser una primitiva bloqueante que el planificador reanude —no un callback pegado a una demo— y cada concesión, denegación y efecto secundario debe dejar constancia de qué autoridad lo permitió. Esto encaja de forma natural con tratar la salida de la herramienta como no confiable y con los controles de atomicidad sobre las llamadas que modifican estado.

Estado

Elemento	Referencia	Fecha	Notas
Artículo publicado	arXiv:2606.03895v1	2026-06-02	cs.OS, CC-BY 4.0, autor único (Yingqi Zhang)
Artefacto	Prototipo en Python	2026-06-02	Planificador asíncrono, memoria de objetos, broker de syscalls, herramientas JIT
Evaluación	123 pruebas de regresión	2026-06-02	Contención, revocación, atenuación fork/exec, pureza de wrappers
Regla de diseño	Herramientas = libc; primitivas = frontera de autoridad	2026-06-02	Visibilidad ≠ invocación ≠ autoridad
No-objetivo explícito	Inyección de prompt semántica	2026-06-02	El runtime contiene el efecto, no el engaño
Linaje	Inyección de prompt indirecta (Greshake et al.)	2023-02	Por qué la seguridad a nivel de wrapper es insuficiente

Agent libOS no impedirá que un modelo sea engañado. Lo que ofrece es un punto de apoyo para cuando el modelo sí lo es: un runtime donde la solicitud peligrosa todavía tiene que superar una capacidad que nunca se le concedió. Para los equipos que despliegan en 2026 agentes de larga duración que manejan herramientas, la contribución más útil del artículo es el vocabulario —visibilidad, invocación, autoridad— para advertir que los frameworks de hoy suelen colapsar los tres en uno solo.