La nueva gobernanza de identidades para agentes de IA y workloads

La gestión del ciclo de vida de identidades que reina en la mayoría de las empresas fue diseñada pensando en personas: alta en RR. HH., con un manager, con cambios de puesto documentados y una fecha de salida. Ese modelo funciona porque se basa en señales estructuradas (altas, traslados, bajas) que disparan provisión, recertificación y desprovisión. Sin embargo, esa arquitectura no encaja cuando el principal no es humano: los agentes de IA y las identidades de workload emergen desde pipelines, contenedores y APIs, sin pasar por el peaje de RR. HH., sin un dueño claro y sin los eventos administrativos que alimentan a las herramientas IGA tradicionales.

El problema no es puramente teórico. Cuando una identidad entra al entorno sin un registro de incorporación y con credenciales emitidas por la propia pipeline, la visibilidad y el control se rompen. Esos agentes pueden ampliar su superficie de acceso en ejecución, bifurcarse en múltiples instancias con credenciales dispares, delegar tareas a sub-agentes y persistir con claves o tokens que nunca fueron revocados. El resultado práctico es sencillo: credenciales sobredimensionadas, ausencia de historial de aprobación, revisiones de acceso que atestiguan registros obsoletos y caminos de acceso que permanecen abiertos mucho después de que el workload desapareciera.

Las consecuencias superan la higiene operativa. Desde el punto de vista de seguridad, un token de agente sin rotación o responsabilidad definida facilita la escalada de privilegios y la exfiltración encadenada a través de APIs. En términos de cumplimiento, auditorías que confían en evidencia de HR y en campañas de recertificación trimestrales obtendrán un registro formalmente «verde» mientras la actividad real muestra un panorama distinto; eso agrava el riesgo legal y regulatorio en entornos sujetos a SOX, HIPAA o normas sectoriales. En respuesta a incidentes, la falta de correlación entre identidad, dueño y propósito complica la contención y la atribución.

La buena noticia es que la solución no pasa por forzar un modelo de RR. HH. sobre agentes, sino por reconstruir la gobernanza según las características operativas de esos principals. Eso implica tres ejes técnicos y organizativos: descubrimiento continuo de identidades allí donde realmente viven (IAM de nube, servidores de autorizaciones OAuth, Kubernetes, gestores de secretos, registros de CI/CD), un modelo de atributos específico para agentes (equipo propietario, propósito operativo, perímetro autorizado, fecha de expiración esperada) y controles en tiempo real que traten las desviaciones de comportamiento como eventos de gobernanza y no como hallazgos trimestrales.

En el plano técnico conviene adoptar prácticas probadas: emitir credenciales efímeras cuando sea posible (tokens de corta vida via STS o flujos OIDC), integrar federación de identidades para workloads (Workload Identity Federation de Azure o soluciones equivalentes en Google Cloud) y centralizar la gestión de secretos con rotación automática en gestores como AWS Secrets Manager, Azure Key Vault o HashiCorp Vault. La documentación y las políticas deben forzarse en la canalización: todo despliegue que cree un agente y solicite permisos debe generar un ticket de gobernanza o endpoint de aprobación que quede registrado en la plataforma IGA o en un catálogo de riesgos. Microsoft y Google ofrecen guías prácticas sobre federación de identidades para workloads que son relevantes para este enfoque: guía de Azure Workload Identity Federation y documentación de Google Workload Identity Federation.

La observabilidad es el otro pilar: instrumentar APIs y flujos de agent-to-service, exportar telemetría a SIEM/UEBA y construir líneas base del comportamiento normal del agente permite definir alertas cuando un agente solicita scopes nuevos, eleva privilegios o accede a datos que no se correspondían con su propósito documentado. En lugar de esperar a la próxima campaña de recertificación, esas divergencias deben traducirse en workflows automáticos que limiten permisos, disparen revisiones de riesgo y pidan re-autorización al equipo propietario. Las buenas prácticas de desarrollo seguro y de API están recogidas en recursos como el proyecto OWASP API Security: OWASP API Security, que ofrece controles aplicables al diseño y protección de interfaces que los agentes consumen.

En cuanto a gobernanza y procesos, la recomendación es clara: defina un atributo obligatorio para cada agente antes de su primera ejecución en producción —dueño (equipo o persona), propósito funcional, lista de APIs autorizadas y ventana de vida prevista— y haga que la provisión de permisos dependa de ese registro. Establezca reglas de política como código que rechacen despliegues que soliciten scopes fuera de los patrones aprobados y automatice la revocación para credenciales inactivas mediante políticas de expiración y telemetría de uso.

La integración entre pipeline y IGA debe ser bidireccional: los pipelines no son un “foro libre” para crear identidades, sino un punto de control que debe someter solicitudes de acceso a guardrails. Esto se consigue con puertas CI/CD que validen solicitudes de IAM contra catálogos de riesgo y plantillas de least-privilege, con documentación automática en el inventario de identidades y con auditoría legible por cumplimiento. Las pruebas operativas deben incluir ejercicios de «red team» y simulaciones de robos de tokens para validar que la rotación, el corte de acceso y la detección funcionan bajo presión.

La transformación es incremental: empiece por identificar los agentes que acceden a recursos sensibles (bases de datos con PII, secretos críticos, servicios financieros) y desenrede sus cadenas de credenciales; establezca telemetría y políticas para esos casos antes de abarcar masas de workloads menos críticos. En paralelo, amplíe la capacidad de descubrimiento para eliminar la «caja negra» de identidades no visibles y vincule cada identidad nueva a un proceso de aprobación automatizado.

Si su organización quiere alinear su modelo de ciclo de vida de identidades con la realidad de agentes autónomos, la receta combina tecnología, procesos y responsabilidad. Visibilidad continua, atributos de identidad diseñados para agentes y controles en tiempo real son la base para evitar que cientos o miles de credenciales huérfanas se conviertan en vectores explotables. No basta con confiar en campañas trimestrales: los agentes exigen una gobernanza permanente y conectada a la infraestructura que los crea y los ejecuta.