Gobernanza en runtime: el modelo propone, el runtime decide

De 6.300 filas registradas en un banco de pruebas de agentes, 79 acabaron con una acción de riesgo colándose por el camino cuando la única barrera era el prompt. En las 2.100 filas que pasaron por una capa de control en tiempo de ejecución, esa cifra fue cero. Ese contraste es el corazón de Aegis, un paper publicado en arXiv el 19 de agosto que ataca un problema que ya dejó de ser teórico.

El planteamiento de partida merece atención porque reencuadra qué significa seguridad en sistemas agénticos. Un agente que solo genera texto puede decir algo inapropiado. Un agente con herramientas escribe ficheros, manda mensajes, lanza jobs y cambia el estado de un workflow. El daño deja de ser semántico y pasa a ser operativo. Y ahí, sostienen los autores, la gobernanza por prompt tiene un límite estructural: puede moldear el comportamiento del modelo, pero no crea una frontera de ejecución. Un system prompt no es un permiso.

El modelo propone, el runtime decide

Aegis invierte el orden habitual. Trata cada salida del modelo como una propuesta de acción, no como una orden, y la pasa por una capa de decisión de confianza antes de que la herramienta llegue a ejecutarse. Esa capa hace cuatro cosas:

1. Evalúa la propuesta contra el estado de política activo, no contra una política congelada dentro del prompt.
2. Resuelve la procedencia (provenance) en servidor, de modo que el origen de una acción no dependa de lo que el propio modelo diga sobre sí mismo.
3. Falla en cerrado ante la incertidumbre: si no puede decidir, no ejecuta.
4. Enruta ciertos casos por lo que llaman Senate style settlement, una vía de autorización por quórum pensada para que ninguna acción sensible sea unilateral.

Los tres primeros puntos son ingeniería de sistemas clásica aplicada a un contexto nuevo. El cuarto es el más interesante y también el más discutible: añade coste y latencia a cambio de que ninguna acción crítica dependa de un único juicio.

Lo que mide y lo que no

El montaje experimental es un corpus de sandbox repetido: cinco familias de ejecución, 42 tareas, tres condiciones y diez repeticiones por familia. De ahí salen las 6.300 filas totales y las 2.100 gobernadas por Aegis, con cero aplicaciones de mock tool gobernadas y cero efectos secundarios de riesgo completados. El resumen público se corta justo al detallar los 1.832 intentos gobernados, así que ese tramo hay que ir a buscarlo al PDF.

Conviene no leer ese cero como una garantía. Es un sandbox, con tareas definidas por los propios autores, y un sistema que falla en cerrado tiende a puntuar bien en seguridad por construcción. La pregunta que el abstract no responde es cuánto trabajo legítimo bloquea de más y cuánta latencia añade el quórum. Sin la cifra de falsos positivos, el cero es la mitad de la historia.

Por qué nos importa aquí

Si montas agentes con Claude Code, esto describe algo que ya tienes a mano a medias. Los hooks de PreToolUse son exactamente el punto donde se puede interponer una decisión antes de que la herramienta corra, y el sistema de permisos del CLI es una política real, no una sugerencia escrita en el contexto. Lo que el paper aporta es rigor sobre tres detalles que solemos saltarnos: que la política viva fuera del contexto del modelo, que la procedencia se resuelva en el lado del servidor y que el comportamiento por defecto ante la duda sea no ejecutar.

Nuestra experiencia montando servidores MCP e integraciones para clientes va en esa dirección. El fallo típico no es un modelo que se porta mal, es un agente que se porta bien con un permiso demasiado ancho. Aegis no resuelve eso por sí solo, pero pone números a algo que hasta ahora se defendía por intuición: instrucción y permiso son capas distintas, y confundirlas sale caro.