Cómo gobernar las identidades de tus agentes de IA en producción
Un agente que hace algo útil necesita credenciales. Para leer tu CRM, escribir en una base de datos o lanzar un pago, alguien le ha dado una llave. Esa llave es una identidad, y la mayoría de equipos no la trata como tal: la mete en una variable de entorno, la comparte entre tres agentes y se olvida de ella.
La respuesta corta a cómo se gobierna una identidad de agente cabe en una frase. Cada agente tiene una identidad separada, con un dueño humano, con el permiso mínimo para su tarea, con credenciales que caducan solas y con una forma probada de apagarlo. Lo demás de este artículo es cómo llegar ahí sin frenar al equipo que está construyendo.
Qué ha cambiado
Hasta hace poco, el patrón normal era una clave de API por integración. La guardabas en el gestor de secretos, la rotabas de vez en cuando y listo. El agente cambia esa foto porque no es una integración fija: decide, llama a varias herramientas y encadena acciones, cada vez más sin que nadie mire en ese momento.
Los proveedores lo están formalizando. El 8 de octubre de 2026, Google Cloud presentó su agente de empresa dentro de Workspace con algo que llama la atención: el agente recibe su propia identidad en el puesto de trabajo, con dirección de correo incluida, y puede delegar en subagentes. Un script actuaba en nombre de un humano; un agente con identidad propia actúa por sí mismo dentro de la organización.
Eso resuelve un problema de trazabilidad y abre otro de gobierno. Si el agente es un actor, hay que saber quién es, qué puede tocar, quién responde por él y cómo se le retira el acceso. Son las mismas preguntas que te haces al dar de alta a una persona, solo que los agentes se crean en minutos y se multiplican sin pasar por Recursos Humanos.
El fallo que vas a encontrar antes
El problema no suele empezar con un ataque. Empieza con un atajo razonable un viernes por la tarde.
Un equipo conecta un agente a una herramienta interna para un piloto. Le da una clave con permisos amplios porque acotarlos habría llevado medio día y el piloto corría prisa. La clave no caduca. Nadie apunta quién es el dueño. El piloto funciona, el agente se queda en producción y la clave sigue ahí seis meses después, con acceso a datos de clientes, sin figurar en ningún inventario.
Multiplica esa escena por cada equipo que prueba agentes este trimestre. Acabas con un conjunto de identidades que nadie creó a propósito, con más permisos de los que necesitan, sin dueño y sin fecha de caducidad. Cuando por fin alguien intenta auditarlas, el trabajo se atasca en la primera pregunta: ¿de quién es esta cuenta y qué pasa si la quito? Nadie lo sabe, así que nadie la quita, y el acceso se queda vivo por si acaso.
La Cloud Security Alliance ha publicado material sobre este hueco de gobierno de identidades no humanas, y el patrón que describe coincide con lo que vemos en proyectos reales: el fallo rara vez está en la política. Casi nadie discute que el mínimo privilegio sea lo correcto. Lo que falta es el proceso para aplicarlo cuando las identidades aparecen a este ritmo.
El marco de decisión
No necesitas una plataforma nueva para empezar. Necesitas tratar cada agente como tratarías a un empleado con acceso a sistemas. Estos son los puntos que revisamos antes de poner un agente delante de datos que importan.
Una identidad por agente, nunca compartida
Si dos agentes comparten credencial, pierdes la capacidad de saber cuál hizo qué y de cortar a uno sin cortar al otro. Tampoco reutilices la identidad del humano que lanzó el agente: cuando esa persona cambie de rol o se vaya, o arrastras su acceso o rompes el agente. Una identidad por agente es más trabajo de alta y mucho menos trabajo el día que algo va mal.
Permiso mínimo por recurso y por acción
Amplio es cómodo y es la causa de la mitad de los sustos. Si el agente resume tickets de soporte, dale lectura sobre los tickets y poco más: no sobre el proyecto entero ni sobre la base de datos de facturación que vive en el mismo sistema. Cuesta más definirlo y hay que revisarlo cuando el agente gana funciones, pero es la diferencia entre un error contenido y uno que se lleva por delante datos que no debería haber tocado.
Credenciales de vida corta en lugar de llaves largas
Una clave estática en una variable de entorno es una llave que no caduca y que viaja en logs, en imágenes de contenedor y en copias de seguridad. Si tu backend corre en Cloud Run o en Kubernetes, la alternativa ya está en la plataforma: workload identity federation, que da al servicio un token efímero en vez de una credencial permanente. El agente pide acceso cuando lo necesita, el token vive minutos y no hay secreto que robar de un fichero. Montarlo cuesta una tarde la primera vez; a cambio, la lista de secretos que custodiar deja de crecer.
Un dueño con nombre y una fecha de revisión
Cada identidad de agente tiene que apuntar a una persona responsable y a una fecha en la que alguien decide si sigue viva. Sin dueño, la auditoría se atasca. Sin fecha, la identidad dura para siempre por omisión. Esto no cuesta tecnología: es un campo en una hoja o en tu sistema de identidades. Y es de lo primero que se salta cuando hay prisa.
Registro de qué hizo cada identidad
Si el agente actúa, queda registro de con qué identidad y sobre qué recurso. Lo necesitas para auditar, para depurar cuando el agente se comporta raro y para responder cuando el cliente pregunta qué datos tocó. Un agente sin rastro es un agente en el que confías a ciegas.
Revocación y apagado probados
El offboarding de un agente importa tanto como el de una persona, y se olvida más. Cuando apagues el agente, su identidad y sus permisos se van con él. Y antes de ponerlo en producción, prueba el botón de apagado de verdad: corta la credencial y confirma que el agente deja de poder actuar. Un kill switch que nunca se ha probado no sirve de nada el día que lo necesitas.
Cuándo no montar toda esta maquinaria
Un piloto de dos semanas con un agente que solo lee un dataset público no necesita federación de identidad ni revisiones trimestrales. Para eso, una credencial acotada y una nota con el dueño bastan.
La maquinaria completa empieza a pagar cuando se cruzan dos líneas: el agente toca datos que te dolerían si se filtran, y hay más de un equipo creando agentes sin hablar entre ellos. Antes de eso, montar un gobierno pesado es resolver un problema que todavía no tienes y frenar al equipo que intenta aprender qué sirve. El proceso hay que tenerlo listo antes de pasar de un agente a treinta, que es lo que ocurre en un par de trimestres sin que nadie lo decida.
Cómo lo abordamos nosotros
Cuando entramos en un proyecto donde ya hay agentes sueltos, no empezamos comprando una herramienta. Empezamos por el inventario, que suele ser la parte incómoda: qué agentes existen, con qué credenciales corren y a qué pueden llegar. Casi siempre aparece al menos una identidad que nadie recordaba y que podía más de lo que debía.
A partir de ahí, lo normal es mover las llaves estáticas a identidades efímeras sobre la infraestructura que ya tiene el cliente, recortar permisos al uso real de cada agente y dejar un dueño y una fecha de revisión por cada uno. En backends sobre Go y Cloud Run lo apoyamos en workload identity, que evita repartir secretos y encaja con el autoescalado sin añadir piezas nuevas que mantener. Es un trabajo que cuesta fricción al principio: pedir permisos acotados y credenciales de vida corta es menos cómodo que una clave que todo lo puede. Esa incomodidad es justo la que te ahorra la auditoría imposible del año que viene.
Llevamos desde 2011 construyendo producto, y lo que se repite es que la seguridad dejada para el final casi nunca llega. Con agentes el margen es más estrecho, porque se reproducen rápido y actúan solos. La identidad es donde ese control se concreta: quién es cada agente y qué puede tocar.
Si estás metiendo agentes en producción y no tienes claro quién es cada uno ni qué puede tocar, es buen momento para ordenarlo antes de que la lista crezca. Lo trabajamos tanto desde la integración de IA como desde el backend, que es donde viven las credenciales de verdad.
