Permisos para agentes que actúan: medir el radio de acción antes de entregar las llaves

El modelo de seguridad de un agente no es el de un usuario, y tampoco es el de un servicio. Un servicio hace un conjunto fijo de cosas con credenciales fijas. Un usuario es responsable y se le puede explicar una política. Un agente tiene las credenciales de un servicio y el conjunto abierto de instrucciones de un usuario, y sus instrucciones pueden llegar dentro de los datos que está procesando.

Esa última parte es toda la restricción de diseño. Da por hecho que cualquier agente que lea contenido externo recibirá, en algún momento, una orden de ese contenido. Y mide entonces qué pasa después.

Empieza por el conjunto alcanzable, no por la lista de herramientas

La pregunta útil no es «qué herramientas tiene» sino «cuál es la unión de todo lo que esas herramientas pueden tocar». Un agente con una única herramienta run_query contra un rol de almacén que puede leer todos los esquemas tiene como conjunto alcanzable los datos de toda la empresa, con una sola herramienta.

Escríbelo por agente: qué sistemas, qué registros, lectura o escritura, y cuál es la peor acción individual. En la mayoría de revisiones que hacemos ese documento no existe, y producirlo cambia dos o tres cosas de inmediato, casi siempre una credencial que era cómoda durante el prototipo y nunca se estrechó.

Identidad propia, siempre

Nunca dejes que un agente tome prestada la sesión de una persona ni una clave de administrador compartida. Dale un principal de servicio dedicado, su propio rol IAM, sus propias claves de API. De ahí salen tres cosas que no se consiguen de ninguna otra forma: el registro de auditoría atribuye las acciones al agente, puedes revocarlo sin fastidiar a nadie, y puedes aplicarle una política que sería inaceptable en una cuenta humana.

Cuando el agente actúa en nombre de un usuario concreto, propaga la identidad de ese usuario en lugar de aplanarla: el rol del agente debería poder hacer menos que quien le llama, nunca más. Un agente que puede leer documentos que su solicitante no puede leer es una fuga de datos con interfaz de chat, y es el error de diseño más habitual que encontramos en los asistentes internos.

Lectura y escritura son dos sistemas distintos

El control más eficaz es aburrido: dos credenciales. El agente razona con un rol de solo lectura; las escrituras pasan por un camino aparte, estrecho y determinista, que valida contra reglas que escribiste tú.

En concreto, en operación cloud: el agente recibe un ReadOnlyAccess menos las acciones que leen secretos, y todo lo que cambia estado es un plan de Terraform propuesto o una acción encolada que aplica una tubería. La salida del agente es una pull request, no una llamada a la API. Eso convierte cada capacidad peligrosa en un artefacto revisable y cuesta muy poco en utilidad: lo desarrollamos en agentes en la operación cloud.

Acota las escrituras que sí permitas

Cuando una acción tiene que ocurrir sin persona delante, acótala por tres lados:

Alcance: la escritura solo puede tocar recursos que encajen en un filtro que el agente no puede cambiar. Etiquetas, un prefijo de proyecto, un identificador de cliente tomado de la petición y no de la salida del modelo.

Magnitud: una herramienta de devoluciones sin máximo tiene como máximo el saldo de tu banco. Toda herramienta de escritura necesita un límite expresado en unidades del negocio.

Frecuencia: un tope por hora aplicado fuera del agente. El caso de inyección y el del bucle desbocado se ven igual desde fuera: muchas acciones, deprisa. Un solo contador caza los dos.

Registra la intención, no solo la llamada

Una traza de auditoría que dice POST /clientes/4471 no te cuenta nada del porqué. Registra la llamada a la herramienta junto con la razón declarada del modelo, el hash del prompt, el identificador de la ejecución y el usuario por el que actuaba. Cuando algo salga mal —y el primer incidente interesante siempre incluye una acción individualmente autorizada y colectivamente equivocada— esto es la diferencia entre una investigación de dos horas y una de dos días.

La cadencia de revisión

Los permisos de los agentes se pudren más rápido que los de los servicios, porque las capacidades se añaden experimentando y no se quitan nunca. Mete el documento del conjunto alcanzable en una revisión trimestral con la misma seriedad que una revisión de accesos privilegiados, y usa herramientas de análisis de accesos para comparar lo concedido con lo usado: el mínimo privilegio a partir del uso real aplica aquí más que en ningún sitio, porque los agentes usan una fracción pequeña de lo que se les da.

Qué hacer esta semana

Coge tu agente interno más usado y responde a una pregunta: si un atacante pudiera escribir instrucciones arbitrarias en su entrada, ¿qué es lo peor que podría hacer en los próximos sesenta segundos? Si la respuesta incluye datos de clientes o infraestructura de producción, el arreglo no es un prompt mejor. Es un rol más pequeño.