La identidad de los agentes de IA ya es un problema de IAM: y llega con auditoría, privilegios y revocación

La discusión útil sobre agentes de IA no es si “van a transformar la empresa”. Eso ya lo sabemos. La pregunta seria es otra: cuando un agente consulta un CRM, lanza una orden en un ERP, accede a un repositorio de código o dispara un workflow de pagos, ¿quién es exactamente ese actor dentro de tu modelo de identidades? Si la respuesta hoy es “una service account compartida”, tienes un problema técnico, y bastante probablemente uno de cumplimiento.

En 2026, el frente nuevo de IAM no está en los empleados ni siquiera en los terceros. Está en las identidades no humanas: agentes de IA, cuentas de servicio, secrets embebidos en pipelines, tokens de API, claves efímeras mal gobernadas, identidades de workload y credenciales que sobreviven bastante más que el proyecto que las creó. El detalle incómodo es que estos actores ya no se limitan a mover datos entre sistemas. Empiezan a tomar decisiones operativas, encadenar acciones y generar efectos materiales. Ahí la trazabilidad deja de ser un lujo de auditoría y pasa a ser control básico.

El NIST AI Risk Management Framework no prescribe un esquema cerrado de IAM para agentes, pero sí deja una señal clara: la gobernanza de la IA exige asignación de responsabilidades, gestión de riesgos a lo largo del ciclo de vida, documentación, supervisión y controles verificables. Si se cruza eso con NIST CSF 2.0, con ISO/IEC 27001:2022 y con el paquete regulatorio europeo aplicable a entidades financieras, el mensaje se vuelve mucho menos abstracto. Un agente de IA con acceso real a sistemas es una identidad con riesgo real. Y debe tratarse como tal.

Para un CISO o un responsable de cumplimiento, el error de diseño más común ahora mismo es este: desplegar agentes como si fueran funcionalidad, cuando en realidad son sujetos operativos con permisos, dependencias, credenciales, logs y necesidad de revocación. Dicho sin rodeos, mucha organización ha puesto copilotos, bots y automatizaciones “inteligentes” encima de un modelo de acceso heredado del año en que aún se pasaban Excel por correo.

El cambio de fondo: del usuario humano a la identidad ejecutora

IAM siempre ha gestionado más que empleados. Cuentas técnicas, procesos batch y service accounts existen desde hace décadas. Lo nuevo no es la identidad no humana en sí. Lo nuevo es su nivel de autonomía, su capacidad para encadenar herramientas y la opacidad operativa que introduce un agente cuando actúa a través de varias capas: modelo, orquestador, plugin, API gateway, cuenta de servicio y sistema destino.

Un ejemplo sencillo lo deja claro. Un agente interno de soporte recibe una incidencia, consulta la CMDB, busca en la base de conocimiento, abre un ticket en ITSM, reinicia un recurso cloud y notifica al usuario. En apariencia es “un solo agente”. En realidad, hay al menos cinco acciones sujetas a autorización distinta, varios tokens, posiblemente un secreto almacenado en un vault, un proveedor SaaS, registros en sistemas diferentes y una decisión automatizada que puede afectar a disponibilidad o integridad. Si uno de esos pasos usa una credencial compartida, pierdes atribución. Si además el agente puede actuar fuera de un contexto aprobado, pierdes control. Si no puedes revocar de forma inmediata, pierdes tiempo. Y el tiempo, cuando hay incidente, suele ser exactamente lo que no sobra.

Esto conecta directamente con NIST CSF 2.0. La función Govern exige integrar la ciberseguridad en la gobernanza de riesgos; Identify obliga a entender activos, dependencias y roles; Protect entra de lleno en gestión de identidades, autenticación y control de acceso. No hace falta retorcer el marco para que encaje: la identidad de agentes de IA cae de lleno ahí. Si una entidad ha inventariado modelos y casos de uso, pero no ha inventariado las identidades técnicas y permisos con los que esos agentes operan, su evaluación está incompleta.

El AI RMF de NIST va por el mismo camino. Sus funciones Govern, Map, Measure y Manage exigen definir responsabilidades, entender contexto de uso, evaluar impactos y aplicar mitigaciones. La identidad del agente forma parte del contexto y del control, no de la decoración documental. Un agente sin identidad gobernada es un riesgo mal descrito.

El agujero que muchos no ven: no todas las identidades no humanas son iguales

Uno de los errores más caros en 2026 es meter bajo la misma etiqueta “NHI” todo lo que no respira. No es lo mismo un token de acceso efímero emitido por una workload identity federada que una service account persistente con privilegios heredados, ni es lo mismo un agente de IA que propone acciones sujeto a aprobación humana que otro capaz de ejecutarlas directamente sobre sistemas de producción.

Para gobernar bien, conviene separar al menos cinco categorías operativas:

Agentes con capacidad de lectura. Consultan datos, indexan documentos, resumen expedientes o responden preguntas. Su principal riesgo está en confidencialidad, minimización y acceso indebido a datos personales o información sensible.

Agentes con capacidad de escritura limitada. Crean tickets, actualizan registros no críticos o publican respuestas en sistemas definidos. Aquí entra en juego la integridad de la información y el control de cambios.

Agentes con capacidad de ejecución. Lanzan scripts, activan pipelines, modifican configuración o desencadenan acciones en cloud y sistemas core. Este grupo exige segregación de funciones, aprobación y límites temporales de permisos.

Identidades de integración y tooling. APIs, conectores, plugins, middleware, RPA con funciones de soporte al agente. No “piensan”, pero son la manguera por la que fluye el acceso real.

Credenciales de soporte. Secrets, certificados, claves de firma, tokens refresh, credenciales de vault. Sin ellas, el agente no opera; con ellas mal gobernadas, cualquiera podría operar como el agente.

Esta distinción importa porque las obligaciones y evidencias cambian. Si un agente solo resume documentación pública, la exigencia de revisión previa o de just-in-time access puede ser menor. Si puede instruir pagos, tocar una política de red o desactivar un control, el umbral sube de inmediato. Y no por una cuestión filosófica sobre la IA, sino porque cualquier auditor competente te preguntará qué permisos exactos tenía, durante cuánto tiempo, bajo qué aprobación y con qué registro de acciones.

Autenticación: si el agente se autentica como “shared-bot-prod”, ya vas tarde

La primera disciplina que se rompe con los agentes de IA es la autenticación. Muchas implementaciones siguen usando credenciales estáticas asociadas a una cuenta técnica genérica, a veces compartida entre varias automatizaciones. Eso era mala práctica antes. Con agentes multiacción es peor, porque elimina trazabilidad fina y complica contención.

El principio operativo debería ser este: cada agente o instancia ejecutora relevante necesita una identidad propia, emitida por un sistema central o federado, con autenticación fuerte adaptada a su naturaleza técnica. No se trata de poner MFA a un bot como si fuese un comercial. Se trata de usar mecanismos robustos para workloads: certificados de corta duración, federación de identidad entre plataformas, tokens efímeros emitidos bajo confianza verificable, credenciales almacenadas en un vault con rotación automática y, donde proceda, atestación de entorno.

En entornos cloud modernos, esto suele materializarse en workload identity federation y eliminación de secretos de larga duración. En pipelines CI/CD, en OIDC para intercambiar identidad temporal con el proveedor cloud. En Kubernetes, en service accounts vinculadas a políticas granularmente definidas y no en secretos estáticos reciclados durante meses. En APIs internas, en OAuth 2.0 o mTLS con expiraciones cortas y claims que identifiquen al agente, al entorno y al caso de uso.

La razón no es puramente técnica. Si el regulador o el auditor te pide demostrar quién accedió a un sistema y por qué, “fue el bot” ya no sirve. Hay que poder demostrar qué agente concreto, bajo qué identidad, desde qué entorno, con qué cadena de autorización y en qué ventana temporal. Esa evidencia no aparece por generación espontánea seis meses después.

ISO/IEC 27001:2022 va bastante más al grano de lo que a veces se reconoce. El Anexo A incluye controles sobre gestión de identidades, información de autenticación, derechos de acceso, acceso privilegiado y revisión de accesos. No menciona “agentes de IA” porque las normas serias suelen envejecer mejor que la moda terminológica, pero encaja plenamente con controles como A.5.15 sobre control de acceso, A.5.16 sobre gestión de identidades, A.5.17 sobre información de autenticación y A.5.18 sobre derechos de acceso. Si una entidad crea agentes que actúan sobre sistemas sin aplicar estos controles, no está innovando; está abriendo una excepción no documentada.

Autorización: mínimo privilegio, pero de verdad

El mínimo privilegio se invoca con entusiasmo en las presentaciones y se incumple con disciplina en la operación. Con agentes de IA el riesgo se multiplica porque la tendencia natural del negocio es pedir capacidades amplias “para que funcione bien”. Un agente que solo puede consultar dos tablas y abrir tickets parece menos vistoso que uno con acceso transversal a CRM, ERP, correo, archivos y herramientas de administración. También es bastante menos peligroso.

Aquí conviene abandonar el modelo binario de “puede/no puede” y pasar a una autorización por tareas, contexto y tiempo. Un agente no debería recibir permisos permanentes de administración solo porque una vez al mes ejecuta una acción sensible. Lo razonable es conceder acceso temporal, con aprobación previa o con una condición verificable, y limitarlo al recurso exacto y a la operación exacta.

Esto es especialmente relevante en banca, seguros y pagos, donde la mezcla de automatización e identidad mal resuelta choca con varias piezas regulatorias al mismo tiempo. DORA exige un marco sólido de gestión del riesgo de las TIC y controles de seguridad de la información, incluido el control de accesos. El Reglamento (UE) 2022/2554 no desarrolla IAM con el detalle de un estándar técnico, pero sí fija la obligación de contar con mecanismos, políticas y procedimientos para proteger activos de información y TIC. El artículo 9, sobre el marco de gestión del riesgo relacionado con las TIC, y el artículo 10, sobre sistemas, protocolos y herramientas TIC, apuntan a controles de acceso y autenticación como parte de la higiene mínima exigible. Si un agente de IA accede a sistemas críticos mediante cuentas sobredimensionadas, el problema no es solo de arquitectura: encaja mal con la expectativa supervisora de resiliencia operativa.

La relación con NIS2 también es directa para entidades esenciales e importantes fuera o dentro del sector financiero. El artículo 21 de la Directiva (UE) 2022/2555 exige medidas técnicas, operativas y organizativas apropiadas, incluyendo políticas de análisis de riesgos y seguridad de sistemas de información, gestión de incidentes, continuidad, seguridad de la cadena de suministro y uso de criptografía y, de forma amplia, seguridad de recursos humanos, control de acceso y gestión de activos. Otra vez, no aparece la etiqueta “agente de IA” porque no hace falta. Si el agente es una puerta de acceso a sistemas críticos, entra en el perímetro de esas medidas.

En términos prácticos, mínimo privilegio para agentes implica al menos seis decisiones operativas:

• Separar agentes por función y entorno: uno para soporte, otro para finanzas, otro para desarrollo; y nunca mezclar dev con producción bajo la misma identidad.
• Asignar permisos por acción, no por aplicación entera. Leer un expediente no implica modificarlo; abrir un ticket no implica cerrarlo; consultar facturas no implica emitir pagos.
• Usar acceso temporal para operaciones sensibles. Si el agente necesita elevar privilegios, que sea bajo control y con expiración automática.
• Aplicar límites contextuales: horario, origen, red, región, recurso específico, clasificación del dato.
• Introducir human-in-the-loop cuando la acción tenga impacto financiero, legal o operativo material.
• Revisar permisos de agentes con la misma cadencia o más frecuencia que la de usuarios privilegiados humanos.

Si esto te parece exigente, espera a tener que explicar por qué un agente con fines de productividad terminó accediendo a buzones, repositorios y datos de clientes porque “era más rápido integrarlo así”.

Rotación de credenciales: el secreto que nadie quiere tocar hasta que aparece en un repositorio

Buena parte del riesgo real no está en el modelo de IA, sino en las credenciales que lo sostienen. Agents, plugins y conectores suelen apoyarse en API keys, certificados, tokens refresh o secretos almacenados en gestores de configuración. Cuando esos secretos son persistentes, ampliamente reutilizados o carecen de rotación automática, el control está roto aunque el resto de la arquitectura sea razonable.

Las credenciales de agentes deberían seguir cuatro reglas sencillas y poco negociables. Primera: no embebidas en código ni en prompts ni en ficheros de configuración expuestos. Segunda: vida corta por defecto, con renovación automática cuando sea viable. Tercera: custodia en un vault con controles de acceso y registro de uso. Cuarta: sustitución rápida cuando exista indicio de compromiso, sin depender de una cadena manual de tickets que dura más que el incidente.

Hay aquí además una cuestión de evidencia. Si tu organización afirma que rota credenciales, el auditor no te pedirá una promesa; pedirá pruebas. Fechas de emisión y expiración, política aprobada, logs del vault, evidencias de rotación automática, excepciones aprobadas, tickets de emergencia y lista de credenciales huérfanas detectadas y eliminadas. Sin ese rastro, la política vale lo que suele valer una política sin implementación: bastante poco.

Desde la óptica de privacidad, la rotación y custodia de credenciales también importan por el riesgo de acceso no autorizado a datos personales. El GDPR no contiene una obligación nominal de “rotación de secretos”, pero sí exige seguridad adecuada al riesgo en el artículo 32, incluyendo seudonimización y cifrado cuando proceda, capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia, y procesos para verificar, evaluar y valorar regularmente la eficacia de las medidas. Si un agente de IA accede a datos personales con una clave estática comprometida durante meses, la defensa de que existían “medidas apropiadas” se debilita bastante.

Y si el incidente ya se ha producido, aparecen los plazos. El artículo 33 GDPR impone notificación a la autoridad de control sin dilación indebida y, si es posible, en un máximo de 72 horas desde que el responsable tenga constancia, salvo que sea improbable que la violación suponga un riesgo para los derechos y libertades de las personas. Para cumplir ese plazo, necesitas identificar rápidamente qué identidad accedió a qué datos y durante cuánto tiempo. Si todo pasa por tokens compartidos y logs fragmentados, el reloj corre más deprisa que tu investigación.

Trazabilidad: si no puedes reconstruir la acción del agente, no controlas nada

La trazabilidad es el punto en el que IAM, seguridad, cumplimiento y forense dejan de ser departamentos distintos y se convierten en la misma conversación. Un agente de IA no solo necesita autenticarse y estar autorizado. Sus acciones deben poder reconstruirse con suficiente granularidad como para responder cinco preguntas básicas: qué pidió un humano o sistema, qué decidió el agente, qué herramientas invocó, con qué identidad ejecutó cada paso y qué efecto produjo.

Suena obvio. No lo es en la práctica. Muchas implementaciones registran la conversación del agente o los logs del LLM, pero no la correlación completa con llamadas a APIs, cambios en sistemas destino, elevaciones de privilegios, aprobaciones humanas y resultados finales. Esa laguna invalida parte del valor de los registros. Tienes narrativa, pero no cadena de custodia técnica.

Un esquema robusto de trazabilidad para agentes debería incluir como mínimo:

• Identificador único del agente y de la sesión o ejecución.
• Relación con el usuario humano originador o con el sistema solicitante.
• Contexto de autorización aplicado: roles, claims, políticas evaluadas, aprobación requerida o no.
• Listado de herramientas o conectores invocados, con hora exacta y resultado.
• Identidad técnica usada en cada salto: token, certificado, workload identity o service account derivada.
• Datos de destino afectados: sistema, objeto, registro, expediente, bucket, repositorio.
• Resultado material: lectura, modificación, creación, borrado, ejecución, fallo o bloqueo.
• Evento de revocación o expiración cuando proceda.

Esto encaja bien con requisitos clásicos de logging y monitorización, pero el matiz nuevo está en la correlación entre decisión del agente y acción técnica. El problema ya no es solo “qué cuenta hizo la llamada”, sino “qué instrucción, política o cadena de razonamiento operacionalizó esa llamada”. Nadie sensato va a exigir guardar todo el chain of thought de un modelo, entre otras cosas porque ni siempre es accesible ni siempre es una prueba fiable. Lo que sí debe conservarse es la telemetría suficiente para atribuir, revisar y explicar la acción ejecutada.

Para entidades sujetas a DORA, este punto no es accesorio. El Reglamento exige capacidades de detección, respuesta y recuperación, así como registro y notificación de incidentes relacionados con las TIC. Sin trazabilidad suficiente de identidades no humanas, clasificar un incidente, medir su impacto y determinar la causa raíz se vuelve una lotería cara. Y pocas cosas gustan menos a un supervisor que una lotería presentada como control.

Revocación: el control más aburrido hasta que se convierte en el más urgente

La revocación casi nunca sale en las demos de producto. Es normal: no queda tan lucida como la automatización autónoma. Pero cuando un agente se comporta de forma anómala, un plugin resulta vulnerable, se filtra un token o cambia el perímetro de riesgo del caso de uso, la capacidad de revocar acceso rápido y de manera granular es el control que separa un incidente acotado de un desastre ampliamente distribuido.

Gobernar agentes de IA exige diseñar revocación en varios niveles:

Revocación de identidad: deshabilitar la identidad principal del agente o de la workload.

Revocación de secreto o token: invalidar certificados, claves API, refresh tokens y credenciales derivadas.

Revocación de permisos: retirar roles, scopes, políticas o acceso a herramientas concretas sin apagar por completo el agente si no hace falta.

Revocación de integración: desconectar plugins, conectores o trust relationships con terceros.

Revocación de contexto de uso: impedir determinadas categorías de acciones o acceso a ciertos datos aunque el agente siga operativo.

La revocación eficaz también requiere saber dónde están todas las dependencias. De poco sirve deshabilitar el agente en el orquestador si un token emitido previamente sigue siendo válido durante horas, o si el conector downstream mantiene su propia sesión independiente. Este es uno de los lugares donde las arquitecturas bonitas en el diagrama fallan en producción.

Desde cumplimiento, la pregunta clave es sencilla: ¿puedes demostrar cuánto tardas en revocar y qué alcance tiene esa revocación? Esa métrica es más interesante que muchas dashboards de “madurez”. Si revocar un agente crítico exige tocar manualmente cinco sistemas, coordinar tres equipos y esperar a que expire una caché, tu control existe más en PowerPoint que en la realidad.

Lo que cambia para el sector financiero europeo

En una entidad financiera europea, la identidad de agentes de IA no vive aislada. Se cruza con DORA, con GDPR, con normas internas de segregación de funciones, con requerimientos de outsourcing y con expectativas supervisoras sobre gobernanza y resiliencia. El resultado es que un diseño pobre de IAM para identidades no humanas termina apareciendo por varias puertas a la vez.

DORA, aplicable desde el 17 de enero de 2025, ya no es novedad sino obligación operativa consolidada en 2026. El reglamento exige que las entidades financieras dispongan de un marco de gestión del riesgo de las TIC integral, documentado y revisable. En ese marco, el control de acceso y la gestión de privilegios afectan directamente a agentes de IA si estos interactúan con funciones críticas o importantes. Además, el capítulo sobre gestión del riesgo de terceros TIC complica el panorama cuando el agente depende de proveedores cloud, modelos alojados, APIs externas o herramientas SaaS. No basta con asegurar la identidad del agente dentro de casa; hay que saber qué dependencias externas sostienen esa identidad y bajo qué garantías contractuales y técnicas operan.

Aquí aparece una contradicción frecuente. Muchas entidades han reforzado la diligencia debida sobre terceros para servicios cloud o de procesamiento de datos, pero siguen integrando agentes de IA y plugins con permisos operativos amplios sin elevar ese mismo escrutinio. Mala idea. Si el agente depende de un tercero para inferencia, conectividad o ejecución de herramientas, el vector de riesgo es híbrido: acceso, supply chain, disponibilidad y posible tratamiento de datos. Y sí, eso debería reflejarse tanto en el inventario de terceros como en las evaluaciones de riesgo y en las cláusulas contractuales de seguridad.

En el ámbito de privacidad, el agente puede convertirse en un multiplicador silencioso del riesgo. Un bot bien intencionado con acceso de lectura transversal puede acabar combinando datasets que ningún humano vería juntos en su trabajo diario. Aunque el tratamiento original sea lícito, el exceso de acceso choca con minimización y limitación de finalidad del artículo 5.1, letras b) y c), GDPR. No hace falta esperar a una brecha para tener un problema: basta con que el diseño de permisos permita usos desalineados con la finalidad declarada.

Y hay otra derivada menos comentada. Si un agente interviene en procesos con efectos relevantes para clientes o empleados, la organización debe revisar si está entrando, directa o indirectamente, en terreno sensible del artículo 22 GDPR sobre decisiones individuales automatizadas. No siempre aplicará, porque muchos agentes asisten y no deciden de forma final. Pero cuando la automatización deja de ser mera recomendación y empieza a producir consecuencias sustantivas sin supervisión humana real, la revisión jurídica ya no es opcional.

Arquitectura de control: cómo debería verse un modelo sensato

No hace falta inventar una disciplina nueva. Hace falta aplicar bien varias que ya existen. Un modelo sensato para gobernar identidades de agentes de IA suele apoyarse en ocho capas.

1. Inventario de agentes, herramientas e identidades asociadas

Cada agente debe estar registrado con propietario, finalidad, entorno, sistemas destino, datos que puede tocar, conectores habilitados e identidades técnicas asociadas. Si no puedes enumerarlos, tampoco puedes evaluar su riesgo ni retirar lo que sobre.

2. Clasificación por impacto

No todos los agentes merecen el mismo nivel de control. Una clasificación útil distingue al menos entre acceso a datos personales, acceso a información confidencial, capacidad de modificación, capacidad de ejecución, impacto financiero y dependencia de terceros. Esta clasificación determina revisión, aprobación y evidencias exigibles.

3. Emisión centralizada de identidad

El alta de un agente no debería consistir en crear manualmente una cuenta técnica y pegar una clave en un archivo. Debe existir un flujo gobernado para emitir identidad, asociar políticas, registrar propietario y fijar expiración o revisión obligatoria.

4. Políticas de autorización granulares

La política debe describir no solo qué recursos puede usar, sino para qué operaciones y bajo qué condiciones. Si la plataforma lo permite, conviene usar atributos de contexto y no solo roles estáticos. Los agentes hacen demasiadas cosas distintas como para reducir su control a dos casillas.

5. Custodia y rotación de credenciales

Vault central, acceso medido, expiración corta, rotación automática y alertas por uso anómalo. Sin excepciones “temporales” que duran un año, que de esas ya hemos visto demasiadas.

6. Observabilidad unificada

Logs de identidad, logs del orquestador, eventos del vault, decisiones de política, llamadas a APIs y cambios en sistemas destino deben correlacionarse. Si tu SIEM ve cinco historias distintas, necesitas una sexta capa que las una.

7. Revocación y kill switch

Todo agente con impacto material debería disponer de un mecanismo rápido de desactivación total o parcial. No glamuroso, sí indispensable.

8. Revisión periódica y recertificación

Las identidades de agentes no pueden quedar fuera de las campañas de recertificación de accesos. De hecho, en muchos casos deberían revisarse antes que los usuarios humanos, porque acumulan privilegios sin sufrir las fricciones naturales de bajas, cambios de puesto o vacaciones.

Qué evidencias va a pedir una auditoría seria

Cuando el discurso sobre IA pasa del comité a auditoría interna, auditoría externa o supervisión, lo que cuenta no es la intención sino la evidencia. Si tu organización ya opera agentes con acceso a sistemas, estas son las pruebas que conviene tener preparadas.

• Inventario actualizado de agentes, cuentas técnicas, workloads y tokens asociados, con fecha de alta y propietario asignado.
• Matriz de permisos por agente y por entorno, con justificación de negocio y fecha de aprobación.
• Políticas de autenticación aplicables a workloads y prueba de su implantación técnica.
• Registro de secretos y certificados, con fechas de emisión, expiración y rotación efectiva.
• Logs correlacionados de acciones del agente y de llamadas a sistemas destino.
• Evidencia de revisiones periódicas de acceso y de remediación de excesos detectados.
• Procedimientos de revocación y pruebas de ejercicio o simulación.
• Evaluaciones de riesgo del caso de uso, incluyendo dependencia de terceros y tratamiento de datos personales cuando exista.
• Documentación de excepciones: quién las aprobó, por cuánto tiempo y qué controles compensatorios existen.

Esto no es burocracia decorativa. Es lo que permite demostrar que el control existe antes, durante y después de un incidente. Y, de paso, distinguir a una organización que gobierna automatización de otra que solo la ha activado.

Errores recurrentes que conviene cortar ya

Hay fallos que aparecen una y otra vez en despliegues de agentes. Conviene nombrarlos sin eufemismos.

Cuenta técnica única para varios agentes. Cómodo al principio, tóxico para la trazabilidad.

Permisos amplios por “falta de tiempo”. El clásico acceso a toda la aplicación porque granularlo retrasa el proyecto. Luego llegan los hallazgos y la prisa cambia de bando.

Secrets persistentes fuera de vault. Suelen acabar en repositorios, tickets, chats o documentación compartida.

Ausencia de propietario claro. El agente es “de innovación”, “de operaciones” o “de datos”. Es decir, de nadie cuando hay que responder.

Sin recertificación. Las campañas de revisión de accesos miran humanos y algunos privilegiados, pero dejan fuera bots y agentes. Justo los que más privilegios acumulan sin protestar.

Logging incompleto. Hay registro de conversación, pero no de acción; o de acción, pero no de identidad origen. En ambos casos, la reconstrucción forense queda a medias.

Revocación teórica. En política pone que se puede revocar inmediatamente; en operación, depende de cuatro sistemas y dos equipos.

La cuestión incómoda: gobernar agentes no es un proyecto de IA, es un programa de control de acceso

Muchas organizaciones siguen tratando este asunto como una extensión de sus iniciativas de IA. Ese enfoque se queda corto. El gobierno de identidades de agentes debe sentarse, como mínimo, entre IAM/PAM, seguridad cloud, arquitectura, riesgo tecnológico, privacidad y cumplimiento. Si se deja solo en manos del equipo que despliega el agente, la prioridad natural será que funcione. Y claro que tiene que funcionar. Pero también tiene que poder limitarse, revisarse, explicarse y apagarse.

La buena noticia es que no hace falta esperar a una norma milagrosamente específica sobre “identidad de agentes de IA”. Con NIST CSF 2.0, con el AI RMF, con ISO/IEC 27001:2022, con DORA y con GDPR ya existe base suficiente para construir un modelo exigente y defendible. La mala noticia es que eso obliga a hacer trabajo poco fotogénico: inventariar, recertificar, reducir permisos, rotar credenciales, correlacionar logs y ensayar revocación. Nada de eso sale bien en una keynote. Todo eso sale muy bien en una investigación de incidente o en una auditoría tensa.

Si tu entidad está desplegando agentes con acceso real a sistemas, aquí está el quid: deja de pensar en ellos como software “inteligente” y empieza a tratarlos como identidades operativas con capacidad de impacto. La diferencia entre una automatización útil y un problema de control interno suele ser una sola cosa: quién puede hacer qué, con qué credencial, durante cuánto tiempo y con qué prueba.

La IA ha añadido una capa nueva de complejidad. El principio de fondo, en cambio, sigue siendo el de siempre: ninguna identidad sin dueño, ningún privilegio sin justificación, ninguna acción sin rastro, ninguna credencial sin caducidad y ninguna automatización sin freno de emergencia. El resto son eslóganes.