Seguridad y gobierno práctico de la IA — Artículo 2 de 5
Un agente de IA necesita su propia identidad, y menos permisos
Un agente que usa las credenciales de un gerente tiene más autoridad de la que su tarea necesita, antes de que el modelo cometa cualquier error. Dale su propia identidad y un conjunto de permisos más acotado.
Imagina un agente de soporte al cliente que usa las credenciales de un gerente. Puede leer tickets, emitir reembolsos, exportar registros de clientes y cambiar la configuración de cuentas, porque el gerente puede hacer las cuatro cosas. La tarea real del agente es mucho más acotada: resumir un ticket y preparar una respuesta.
El problema existe antes de que el modelo cometa un error. La integración le otorgó más autoridad de la que la tarea requiere.
OWASP describe la agencia excesiva como un riesgo que surge cuando una aplicación de IA tiene demasiada funcionalidad, demasiados permisos o demasiada autonomía. Reducir esa exposición implica examinar lo que la aplicación puede ejecutar, no solo mejorar las instrucciones que se le dan al modelo. OWASP: Excessive Agency
Empieza por separar tres conceptos. La identidad establece qué actor de software hace una solicitud. La autorización determina si esa solicitud está permitida. La rendición de cuentas identifica a las personas y equipos responsables de operar el sistema. Asociar un agente a un responsable no significa que ese responsable haya aprobado personalmente cada acción.
Un buen diseño de acceso le da al agente una identidad propia y gestionada, y le otorga permisos para su flujo de trabajo específico. Cuando actúa en nombre de un usuario, conserva ese contexto de delegación sin copiar el conjunto completo de permisos del usuario. El acceso efectivo debe respetar tanto los límites de la aplicación como el alcance permitido al usuario.
En nuestro ejemplo de soporte, permitiría al agente leer el ticket asignado y crear un borrador interno. Las exportaciones de datos de clientes y los cambios de cuenta no estarían disponibles. Un flujo de reembolsos usaría una herramienta aparte, definida de forma acotada, con verificaciones en el servidor sobre el ticket, el cliente, el monto y la aprobación.
Esta distinción importa porque permitir el nombre de una herramienta no basta. Una operación permitida de "leer cliente" podría pedir el registro del cliente equivocado. Aplica los límites de recurso y de tenant en el servicio dueño de los datos, aunque un gateway también haga verificaciones.
Las credenciales deben gestionarse fuera de los prompts y de los archivos de configuración comunes, con un gestor de secretos adecuado o un mecanismo de identidad de carga de trabajo. Prefiere credenciales de alcance limitado y corta duración cuando la integración lo permite. Una duración corta reduce la exposición, pero no garantiza por sí sola una revocación inmediata.
En la autorización MCP sobre HTTP, valida los tokens para el recurso al que están destinados. La guía de seguridad de MCP rechaza explícitamente el reenvío de tokens: aceptar un token destinado a otro servicio y reenviarlo hacia abajo rompe los límites de autorización. El acceso a los servicios posteriores necesita su propio esquema de autorización, bien diseñado. Guía de seguridad de MCP
Los roles de cada producto también merecen precisión. Cisco describe Duo como soporte para la identidad y el ciclo de vida de los agentes, y Secure Access como el que aplica políticas de acceso detalladas a través de su arquitectura de gateway MCP. Son funciones complementarias; registrar una identidad no basta para tener un control completo. Solution brief de Cisco
Por último, prueba quitar el acceso. Desactiva el agente, cambia el rol de su responsable y ejercita sesiones antiguas y credenciales en caché en un entorno controlado. Mide cuándo se detiene realmente el acceso, incluidos los trabajos en cola y las conexiones posteriores. Actualizar un directorio es un evento; una revocación exitosa es un resultado observado.
Un registro de acceso sencillo puede reunir el agente, el responsable, la acción permitida, el alcance de recursos, las condiciones, la duración de las credenciales, el requisito de aprobación y el mecanismo de revocación.
La pregunta que hay que hacerse es concreta: si este agente malinterpretara hoy su tarea, ¿qué le impediría hacer la infraestructura?