Introducción
Microsoft Entra está ampliando el modelo de gobierno de identidades para cubrir también las identidades de agentes. En este contexto, un agente no es una persona ni una simple cuenta técnica genérica: es un agente de IA que necesita una identidad propia para autenticarse, operar sobre aplicaciones o servicios y quedar sujeto a controles de ciclo de vida.
La idea central es sencilla: si una organización ya gobierna identidades humanas para garantizar que las personas adecuadas tienen el acceso adecuado durante el tiempo adecuado, ese mismo principio debe aplicarse a los agentes de IA. Un agente puede ejecutar acciones, consultar información o integrarse en flujos empresariales; por tanto, su identidad no debería quedar fuera de los controles de seguridad, propiedad y retirada de acceso.
Microsoft describe las Agent Identities como cuentas dentro de Microsoft Entra ID que proporcionan identificación única y capacidades de autenticación para agentes de IA. Esto permite tratarlas dentro de un marco de gobierno similar al de otras identidades corporativas.
Qué problema intenta resolver
A medida que las organizaciones incorporan agentes de IA en procesos internos, aparecen preguntas de seguridad muy concretas:
- ¿Quién es responsable de un agente durante su ciclo de vida?
- ¿Qué permisos tiene y por qué?
- ¿Durante cuánto tiempo debe conservar ese acceso?
- ¿Cómo se evita que un agente mantenga permisos después de dejar de ser necesario?
- ¿Cómo se diferencia la actividad de un agente de la actividad de una persona o de otra aplicación?
Sin un modelo de identidad gobernado, los agentes pueden acabar funcionando como cuentas técnicas poco documentadas: con permisos amplios, propietarios ambiguos y procesos de retirada inconsistentes. La gobernanza de identidades de agentes busca reducir ese riesgo proporcionando una forma más estructurada de identificar, autenticar y controlar a estos agentes.
Qué son las identidades de agentes
Una identidad de agente es una cuenta en Microsoft Entra ID asociada a un agente de IA. Su propósito es proporcionar una identidad única al agente para que pueda autenticarse y operar de forma controlada.
Conviene diferenciar este concepto de otros tipos de identidad habituales:
- No es una identidad humana.
- No debe tratarse simplemente como una cuenta compartida.
- No equivale a una identidad administrada de Azure creada para un recurso con comandos como
az identity create. - No debería usarse como una vía para evitar los controles de gobierno existentes.
El valor principal está en que el agente pueda tener una identidad reconocible, con un responsable asignado y con controles que ayuden a que su acceso no se mantenga más tiempo del necesario.
Principios de gobierno aplicables
La gobernanza de identidades de agentes se basa en principios ya conocidos en la gestión de identidades:
Propiedad clara
Cada agente debería tener una persona o equipo responsable. Esa responsabilidad es importante porque el agente puede seguir existiendo y operando aunque el equipo que lo creó cambie, el proyecto termine o el caso de uso evolucione.
Sin un responsable claro, resulta más difícil responder preguntas como:
- ¿Quién aprueba los permisos del agente?
- ¿Quién valida que sigue siendo necesario?
- ¿Quién decide su retirada?
- ¿Quién revisa incidentes o comportamientos inesperados?
Acceso mínimo necesario
El agente debería tener únicamente los permisos requeridos para su función. En términos prácticos, esto implica evitar asignaciones amplias “por comodidad” y revisar el alcance del acceso antes de poner el agente en producción.
Este principio es especialmente relevante en escenarios donde los agentes pueden interactuar con datos empresariales, herramientas colaborativas, flujos de trabajo o servicios internos.
Ciclo de vida controlado
Una identidad de agente no debería vivir indefinidamente sin revisión. Su ciclo de vida debe contemplar, como mínimo:
- Alta: creación o registro de la identidad del agente.
- Asignación de responsable: identificación de la persona o equipo propietario.
- Concesión de acceso: permisos necesarios para el caso de uso.
- Revisión periódica: validación de que el agente y sus permisos siguen siendo necesarios.
- Retirada: eliminación, deshabilitación o revocación de acceso cuando el agente deje de ser necesario.
Trazabilidad
Al disponer de una identidad propia, el agente puede diferenciarse mejor de otras identidades. Esto facilita razonar sobre qué agente intervino en una acción, qué permisos tenía y bajo qué responsabilidad operaba.
La trazabilidad no sustituye a una estrategia completa de monitorización y auditoría, pero es un componente necesario para que los agentes de IA sean gestionables en entornos empresariales.
Microsoft Entra Agent ID y Microsoft Agent 365
Según la documentación de Microsoft, Microsoft Entra Agent ID proporciona la plataforma para crear y administrar identidades de agentes y agent identity blueprints. Microsoft indica que Agent ID está disponible para clientes de Microsoft Entra.
La integración con Microsoft Agent 365, orientada a que los agentes operen a través de servicios de Microsoft 365 y flujos empresariales, requiere una licencia de Microsoft Agent 365.
Esto es importante desde el punto de vista de arquitectura y licenciamiento: la identidad del agente y su capacidad para operar en determinados entornos o servicios pueden depender de componentes y licencias diferentes.
Qué no conviene asumir
Al evaluar esta capacidad, es importante evitar algunas conclusiones precipitadas:
- No todas las identidades técnicas existentes pasan automáticamente a ser identidades de agente.
- No se debe asumir que los comandos de Azure CLI para identidades administradas crean identidades de agente.
- No se debe conceder acceso amplio a un agente solo porque sea “interno” o esté asociado a una solución de IA.
- No se debe omitir la asignación de propietario por tratarse de un sistema automatizado.
- No se debe considerar que el uso de IA reduce los requisitos de auditoría, revisión y cumplimiento.
En entornos regulados o con datos sensibles, los agentes deben tratarse como entidades con capacidad de acción y, por tanto, sujetas a controles explícitos.
Recomendaciones prácticas para equipos técnicos
Antes de desplegar agentes de IA con acceso a recursos corporativos, conviene definir una guía operativa mínima:
1. Inventariar los agentes
Mantén un registro de los agentes previstos o existentes:
- Nombre del agente.
- Propósito.
- Sistema o flujo donde opera.
- Datos o servicios a los que accede.
- Responsable técnico y responsable funcional.
- Fecha o condición de retirada.
2. Clasificar el riesgo
No todos los agentes requieren el mismo nivel de control. Un agente que solo resume información pública no tiene el mismo riesgo que uno que accede a datos internos, ejecuta acciones en sistemas empresariales o interactúa con usuarios finales.
Algunos criterios útiles:
- Sensibilidad de los datos.
- Capacidad de modificar información.
- Alcance del acceso.
- Exposición a usuarios externos.
- Dependencia de flujos críticos de negocio.
3. Aplicar mínimo privilegio
El diseño de permisos debe partir de la pregunta: “¿Qué necesita exactamente este agente para cumplir su función?”.
Evita conceder permisos genéricos o demasiado amplios si el caso de uso puede resolverse con un alcance menor. También conviene separar agentes por función cuando distintos casos de uso requieran permisos muy diferentes.
4. Definir revisiones periódicas
El acceso de un agente puede ser correcto en el momento de su creación y dejar de serlo meses después. Por eso, la revisión periódica es una parte esencial del gobierno.
La revisión debería confirmar:
- Que el agente sigue siendo necesario.
- Que el propietario sigue siendo válido.
- Que los permisos siguen alineados con el caso de uso.
- Que no existen accesos heredados o innecesarios.
- Que el agente se retirará si el proyecto o proceso asociado termina.
5. Preparar el proceso de retirada
La retirada no debe improvisarse. Para cada agente, debería existir un criterio claro de desactivación o eliminación, por ejemplo:
- Fin del proyecto.
- Sustitución por otro agente.
- Cambio de arquitectura.
- Incumplimiento de políticas internas.
- Falta de propietario válido.
- Inactividad prolongada.
Ejemplo conceptual
Imaginemos un agente de IA que ayuda a un equipo de operaciones a consultar información de inventario y preparar respuestas para incidencias internas.
Un enfoque gobernado debería contemplar:
- Crear o registrar una identidad específica para ese agente.
- Asociar la identidad a un responsable del área de operaciones.
- Limitar el acceso a los sistemas y datos estrictamente necesarios.
- Documentar el propósito del agente y sus límites.
- Revisar periódicamente si el agente sigue siendo necesario.
- Retirar la identidad y sus accesos cuando el caso de uso deje de existir.
El punto importante no es automatizar la creación con un comando genérico, sino asegurar que la identidad del agente queda dentro del mismo marco de control que el resto de identidades relevantes de la organización.
Implicaciones para arquitectura
Para arquitectos y responsables técnicos, la gobernanza de identidades de agentes introduce varias consideraciones:
- Los agentes deben modelarse como actores con identidad propia.
- La asignación de permisos debe diseñarse desde el inicio, no al final del proyecto.
- La propiedad del agente debe quedar documentada.
- Los agentes deben integrarse en procesos de revisión y retirada.
- El uso de agentes en flujos empresariales puede requerir licenciamiento específico, especialmente cuando se integran con Microsoft Agent 365.
Este enfoque ayuda a evitar que los agentes se conviertan en componentes opacos dentro de la arquitectura de seguridad.
Conclusión
La gobernanza de identidades de agentes en Microsoft Entra responde a una necesidad cada vez más relevante: gestionar agentes de IA como entidades identificables, autenticables y sujetas a controles de ciclo de vida.
La principal recomendación es no tratar los agentes como automatizaciones aisladas ni como cuentas técnicas sin dueño. Cada agente debe tener una identidad clara, un responsable, permisos mínimos y un proceso de revisión y retirada.
A medida que los agentes se integran en servicios corporativos y flujos de trabajo, su gobierno deja de ser un detalle operativo y pasa a formar parte de la arquitectura de identidad y seguridad de la organización.
Fuente oficial
-
[Governing Agent Identities - Microsoft Entra ID Governance Microsoft Learn](https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview)