Nadie gobierna la acción

Un agente de IA con herramientas no es un chat. Es un proceso que abre ficheros, ejecuta órdenes, llama a servicios de terceros y, cada vez más, encarga trabajo a otros agentes. En cuanto tiene efectos, deja de ser un problema de calidad del texto y pasa a ser un problema de permisos.

Este documento describe dónde está el hueco, qué encontramos al auditar nuestra propia plataforma multiagente, y cuatro patrones que lo cierran. No hay producto que comprar en ninguna de estas páginas: los cuatro patrones se pueden implementar en cualquier sistema, y en la última página decimos qué hacemos nosotros por si alguien prefiere no implementarlos solo.

2 · Qué puede hacer de verdad un agente

Antes de gobernar nada conviene enumerar la superficie. Un agente con herramientas tiene cinco clases de efecto, y cada una falla distinto:

1. 1

   Ejecución

   Órdenes en el sistema donde corre. Es la más peligrosa y la que más se subestima, porque suele entrar como «una herramienta que ejecuta un script».

2. 2

   Ficheros

   Leer y escribir en el disco del cliente. El alcance rara vez está acotado: si el agente puede leer un directorio, normalmente puede leer su padre.

3. 3

   Red

   Salida a internet. Es el canal de exfiltración por defecto: cualquier dato que el agente haya visto puede salir en una petición legítima.

4. 4

   Herramientas externas

   Servidores de herramientas, hoy normalmente por MCP. El agente ejecuta código que no escribiste tú, con los permisos que tenga el proceso que lo lanza.

5. 5

   Otros agentes

   Delegación. El permiso viaja con la tarea, y en cuanto hay dos niveles ya nadie sabe con qué autoridad se ejecutó el último paso.

Sobre esas cinco superficies, tres formas de fallar que aparecen una y otra vez: permisos excesivos concedidos «para que funcione» y nunca retirados; inyección de instrucciones, donde el contenido que el agente lee se convierte en órdenes que obedece; y exfiltración por herramienta, donde el dato sale por un canal que estaba autorizado para otra cosa.

4 · Cuatro patrones de gobernanza de la acción

Ninguno de los cuatro exige una tecnología concreta. Se pueden implementar sobre cualquier runtime de agentes, y conviene implementarlos en este orden.

1. 1

   Compuerta denegada por defecto

   Toda acción con efectos pasa por un único punto que empieza diciendo que no. No es una lista de cosas prohibidas —esa lista nunca está completa—, sino una lista de cosas permitidas, y todo lo que no esté en ella se rechaza. Se comprueba así: escribe una acción que nadie haya previsto y verifica que se deniega sin que nadie la haya tenido que anticipar.

2. 2

   Aprobación con alcance por rol

   Quién puede aprobar qué, declarado como reglas y no como criterio de quien esté mirando la consola. El operador que aprueba leer un directorio no es necesariamente el que puede aprobar una escritura en producción. Se comprueba así: coge una acción de alto impacto e intenta aprobarla con el rol más bajo que exista.

3. 3

   Sello encadenado

   Cada acción queda registrada encadenada a la anterior por una firma, de modo que borrar o editar un asiento rompe el encadenado y el verificador lo señala. La diferencia con un log normal es exactamente esa: no hay que confiar en el registro, se comprueba. Se verifica así: edita a mano un asiento intermedio y comprueba que el sistema lo detecta y dice cuál.

4. 4

   Cierre a cero

   Cuando el sistema de permisos no se puede resolver —está caído, hay una regla ambigua, falta un dato— el agente cierra a cero herramientas en vez de seguir adelante con lo que tenga. Es el patrón que más se omite, porque contradice la intuición de que el sistema debe seguir funcionando. Se comprueba así: tira el servicio de permisos con un agente a mitad de tarea.