Vault pone tres filtros entre tu agente de IA y tus credenciales

El acceso del usuario puede ser demasiado amplio para una tarea

Una persona puede administrar un sistema y pedirle a un agente que consulte un único informe. Delegar esa tarea no exige entregarle toda su capacidad de administración. Vault documenta una forma de recortar el acceso combinando los permisos del usuario, el límite del agente y lo autorizado para esa sesión.

El anuncio de IBM del 27 de octubre reúne Agent Identity y Vault 2.2, ambos con disponibilidad general, para conectar identidad y control de credenciales. Conviene separar ese estado del de las funciones de descubrimiento y contención de agentes de watsonx Orchestrate, que siguen en tech preview.

Lo útil para un AI Engineer está en cómo se decide cada acceso. Identificar al agente permite reconocerlo; la autorización determina qué puede hacer en una ejecución concreta. La integración descrita requiere una licencia adecuada de Vault Enterprise o un clúster HCP Vault Dedicated.

Tres permisos que deben coincidir

En el flujo delegado, conocido como on-behalf-of, Vault combina tres controles. Las políticas del usuario fijan su acceso de partida. Las políticas del registro del agente establecen su techo de permisos. Las restricciones de la sesión concretan qué puede solicitar durante ese trabajo. El permiso efectivo es la intersección: una capa puede recortar a las otras, pero no ampliarlas.

Las restricciones detalladas viajan en el token OAuth mediante Rich Authorization Requests, o RAR. Vault permite limitar rutas, operaciones y parámetros. El servidor de autorización emite ese token y Vault valida sus condiciones; escribir una instrucción equivalente en el prompt no establece esos controles.

RAR está definido en el RFC 9396, publicado en mayo de 2023 como Proposed Standard de la IETF. Es una extensión de OAuth que esta implementación aprovecha para agentes, no un protocolo inventado este octubre. Los tipos de autorización y sus reglas deben ser entendidos por los sistemas que los aplican.

Un agente de informes sin acceso a todos los informes

En este ejemplo sintético, el usuario puede leer los informes A y B y administrar A. El agente está registrado solo para leer A y B. La sesión se autoriza exclusivamente para leer A. Pedir B supera el alcance de la sesión; administrar A supera el del agente, aunque el usuario sí pueda hacerlo.

Si la sesión solicita leer C, tampoco obtiene acceso: el usuario no lo tenía. Esta última comprobación evita que un token con una petición más amplia se convierta en una elevación de privilegios. La regla de intersección se ha comprobado con conjuntos de permisos en un ejemplo local; no es una prueba de una instalación de Vault.

Para el sistema que entrega el informe, la decisión debe llegar desde la identidad y las políticas verificadas. El nombre del recurso escrito por el modelo no demuestra que esté autorizado. Si además se entrega una credencial para otro servicio, ese servicio necesita aplicar su propio alcance.

Caducar pronto y poder retirar el acceso resuelven problemas distintos

Vault asocia sus secretos dinámicos a un lease, un registro con duración y condiciones de renovación. Un tiempo de vida corto reduce cuánto puede durar el acceso concedido. La revocación permite retirarlo antes. Guardar una API key estática en el almacén KV de Vault no la convierte por sí solo en una credencial dinámica con lease.

Hay un detalle operativo importante: la API de revocación puede encolar la operación. El parámetro sync permite esperar a que se complete. Para afirmar que se ha cortado el acceso, interesa comprobar el resultado en el servicio de destino, no solo que se aceptó una solicitud de revocación.

Una tarea que termina en dos minutos no necesita conservar hasta el final de la jornada sus credenciales. Ese plazo es una decisión del ejemplo, no un valor recomendado para todos los agentes. La duración debe cubrir el trabajo previsto y su renovación debe respetar el alcance vigente. Retirar una credencial tampoco deshace una acción que ya se ejecutó.

NIST apunta al mismo problema, sin darlo por estandarizado

El 27 de octubre, NIST publicó una propuesta inicial de diez principios para gestionar identidades de agentes. Incluye identidad diferenciada, vínculo con quien delega, reducción de autoridad al pasar a otros agentes y autorizaciones breves y revocables. También separa el razonamiento del sistema que decide el acceso.

Es una orientación de diseño publicada en un blog y vinculada al trabajo del NCCoE, no una nueva obligación ni una certificación que un producto obtenga por usar tokens. El propio texto reconoce que los estándares y la tecnología actuales todavía no satisfacen todos los principios en cualquier despliegue.

Dónde merece la pena dedicar el trabajo de integración

Este enfoque cobra valor cuando varios agentes acceden a sistemas con permisos distintos o actúan por encargo de diferentes personas. Permite revisar qué acceso pertenece al usuario, cuál al agente y cuál a esa sesión. Exige mantener esas políticas y comprobar que no existe otra credencial más amplia que permita saltárselas.

Lo probaría con la misma tarea y dos usuarios de distinto alcance. Después retiraría la autorización a mitad del recorrido y comprobaría qué llamadas dejan de funcionar. El resultado esperado es una decisión verificable del servicio, incluso si el agente sigue proponiendo acciones. No hace falta cambiar de modelo para corregir un acceso que nunca debió recibir.

Fuentes