ID de agente: Una introducción a la plataforma de identidad de agentes de Microsoft

En el capítulo anterior de esta guía, analizamos las diferencias entre los objetos principales de Entra ID para identidades no humanas. En este capítulo, nos adentramos en el mundo y el concepto de la plataforma Agent ID.

Entra Agent ID de Microsoft y la plataforma de identidad de agentes están a punto de convertirse en un tema central en los debates sobre identidad y seguridad. Si trabajas en Entra ID, ya sea desarrollando aplicaciones, protegiendo entornos o detectando vías de abuso, estamos seguros de que vas a oír hablar mucho de ello.

Uno de los objetivos de esta guía es que, al finalizarla, seas capaz de comprender cada uno de los aspectos que aparecen en la siguiente imagen:

¿Por qué necesitamos la plataforma de identidad de agentes?

El auge de los agentes de IA está transformando el funcionamiento de las organizaciones. Los modelos de identidad tradicionales que hemos comentado anteriormente en esta guía se diseñaron para cuentas humanas y aplicaciones deterministas. Los agentes de IA no encajan claramente en ninguna de estas dos categorías. Pueden tomar decisiones tras un proceso de razonamiento, aprender y adaptarse a los cambios, y comportarse de forma impredecible sin necesidad de iniciar sesión de forma interactiva.

Esta situación puso de manifiesto la necesidad de un nuevo tipo de identidad: la identidad de agente.

Microsoft ha creado la plataforma de identidad de agentes para controlar y proteger este nuevo tipo de identidad. La plataforma permite detectar, gestionar, supervisar y proteger las identidades de los agentes de IA utilizando las capacidades existentes de Entra ID.

¿Qué es, en realidad, la identidad de un agente?

La identidad de agente es un nuevo tipo de identidad específico de Microsoft Entra, diseñado especialmente para los agentes de IA. Se trata de un cambio fundamental: los agentes ya no se consideran usuarios ni entidades de servicio tradicionales, sino una clase de identidades propia con modelos de ciclo de vida, gobernanza y autenticación.

Para comprender mejor la identidad de un agente, resulta útil entender en qué consiste, en la práctica, un agente de IA. La mayoría de las arquitecturas de agentes combinan varios componentes:

• Un modelo: el modelo lingüístico que se encarga de la interpretación y la toma de decisiones
• Una capa de orquestación: el componente que gestiona el razonamiento, la planificación y la ejecución de acciones (a menudo, decidiendo qué herramienta utilizar y cuándo).
• Memoria: estado que persiste entre pasos o sesiones, lo que permite al agente mantener el contexto y mantenerse «al día» dentro de su ventana operativa.
• Herramientas: las interfaces que el agente puede utilizar para interactuar con el entorno, como las API, las acciones SaaS, los scripts y los conectores.

Esos componentes son importantes porque el verdadero poder de un agente en entornos empresariales proviene de las herramientas a las que puede acceder, y el acceso a esas herramientas está condicionado por la autenticación y la autorización.

Los agentes pueden ser autónomos y funcionar de forma independiente. Tras un evento desencadenante o una instrucción explícita del usuario, pueden actuar en nombre de este en un escenario de delegación, o bien pueden crearse y eliminarse dinámicamente para ejecutar una tarea específica.

En cualquier caso, durante la ejecución, el agente necesita una identidad que le permita autenticarse, solicitar tokens, aplicar políticas y dejar registros de auditoría.

Conoce a los protagonistas: los objetos principales de Agent ID

Antes de profundizar en cómo los agentes se autentican, heredan permisos o participan en flujos delegados, debemos comprender los objetos clave que conforman este modelo.

Nota: La plataforma de identidad de agentes de Microsoft aún se encuentra en fase de vista previa, por lo que es posible que algunas de las operaciones que se describen aquí no funcionen o puedan sufrir cambios con el tiempo. En el momento de publicar este artículo, muchas funciones no están disponibles a través del portal de Entra y solo pueden realizarse mediante los puntos de conexión beta de MS Graph.

Modelo de identidad del agente

Un modelo de identidad de agente es la plantilla básica a partir de la cual se crean las identidades de agente. Define una clase de agentes y se basa en el objeto de registro de la aplicación. El modelo almacena la configuración compartida para todas las identidades de agente derivadas de él, incluidos los métodos de autenticación, los permisos heredados y otros ajustes básicos.

Microsoft define cuatro objetivos fundamentales para los modelos de identidad de los agentes:

• Los plantillas funcionan como modelos: todas las identidades de agente creadas a partir de una misma plantilla heredan sus propiedades compartidas, incluida la descripción, los roles, el editor y cualquier reclamación opcional añadida a los tokens de acceso.
• Los «Blueprints» pueden crear identidades de agentes: Cada plano cuenta con la función integrada AgentIdentity.CreateAsManager permiso que le permite crear, actualizar y eliminar identidades de agente. Este permiso se asigna de forma predeterminada y, por el momento, no se puede revocar. (Créenos, lo hemos intentado).
• Los plantillas contienen credenciales: las identidades de los agentes no gestionan sus propias credenciales. En su lugar, se basan en las credenciales configuradas en su plantilla. Entre los tipos de credenciales admitidos se incluyen las credenciales de identidad federada, los certificados y los secretos de cliente.
• Los plantillas actúan como contenedores lógicos: las políticas y algunas configuraciones aplicadas a nivel de plantilla afectan automáticamente a todas las identidades de agente creadas a partir de ella. Por ejemplo, al añadir la plantilla a una política de acceso condicional, dicha política se extiende a todas las identidades de agente asociadas. Al desactivar una plantilla, también se desactivan todas las identidades de agente derivadas de ella.

La plataforma de identidades de agentes introduce un modelo unificado de roles administrativos, común tanto a los planos como a las identidades de agentes derivadas de ellos. Define tres roles: propietario, patrocinador y gestor.

El propietario desempeña la función de administrador técnico. Se trata del rol con más privilegios en este modelo, ya que puede gestionar configuraciones y modificar propiedades. Entre sus funciones se incluyen la actualización de otros propietarios o patrocinadores, la gestión de credenciales, la modificación de la configuración y la restauración de identidades eliminadas de forma temporal.

Los propietarios pueden desactivar y eliminar agentes, así como volver a activarlos. Básicamente, el propietario es el administrador de la identidad. Aunque tienen amplias competencias, no es obligatorio designar a un propietario al crear un modelo de identidad de agente.

Los propietarios pueden ser usuarios o entidades de servicio; sin embargo, esta función debe limitarse a administradores de TI de confianza o a entidades de servicio que necesiten explícitamente gestionar el ciclo de vida y la configuración del agente.

El patrocinador es el propietario de la empresa de un agente y es responsable del ciclo de vida de este. Los patrocinadores pueden eliminar o desactivar agentes, solicitar paquetes de acceso para ellos con justificaciones y gestionar las propiedades relacionadas con el ciclo de vida. Conocen la finalidad del agente y pueden comprobar si su comportamiento es el esperado, especialmente durante las investigaciones de seguridad. A diferencia de los propietarios, los patrocinadores tienen privilegios limitados. No pueden volver a activar agentes, añadir nuevos patrocinadores o propietarios, ni modificar la configuración de autenticación.

Al crear un modelo de identidad de agente, debe indicarse al menos un patrocinador. Se puede asignar a usuarios, entidades de servicio o grupos. Este rol debe recaer en alguien que conozca la finalidad del agente.

El papel de «Gerente» se entenderá mejor cuando presentemos el usuario «agente», así que volveremos sobre ello en un momento.

En resumen, si quieres gestionar un grupo de agentes similares, como por ejemplo agentes especializados en ventas, una única plantilla te ofrece una forma centralizada de definirlos y gestionarlos. Cada identidad de agente creada a partir de la plantilla heredará automáticamente parte de su configuración compartida, al tiempo que te permitirá gestionar las identidades de los agentes de forma individual cuando sea necesario.

Modelo de identidad del agente principal

Un principal de plantilla de identidad de agente es la representación específica de un inquilino de una plantilla de identidad de agente. Se basa en el objeto de entidad de servicio, y puede haber varios principales que representen la misma plantilla de identidad de agente, uno en cada inquilino diferente. En otras palabras, es la instancia de la plantilla de identidad de agente en el inquilino.

Según Microsoft, los «service principals» de Blueprint cumplen dos funciones clave:

• Emisión de tokens: Durante las solicitudes de tokens, la reclamación OID (identificador de objeto) incluida en un token hace referencia al principal del blueprint, identificando al principal que ha realizado la solicitud.
• Registro de auditoría: En los registros de auditoría, las operaciones realizadas por el modelo (como la creación de una identidad de agente) aparecen como acciones ejecutadas por el ID de objeto del sujeto del modelo.

Identidad del agente

La identidad de un agente es un tipo especial de entidad de servicio que representa a un agente de IA en tiempo de ejecución. Es la cuenta real que utiliza el agente para autenticarse y acceder a servicios y recursos.

Las identidades de agente se crean a partir de un modelo de identidad de agente y heredan su configuración y sus credenciales. Para la autenticación, se basan en su modelo, que obtiene los tokens en nombre de la identidad de agente.

A pesar de esta dependencia, la identidad de cada agente sigue siendo un objeto de identidad independiente en el directorio; se le pueden asignar permisos y roles, gestionarse de forma independiente, desactivarse individualmente y gestionarse por separado de su plantilla.

Las identidades de agente siguen el mismo modelo de roles administrativos descrito anteriormente (propietario y patrocinador). Al igual que con los plantillas de identidad de agente, la creación de una identidad de agente requiere al menos un patrocinador, mientras que la asignación de un propietario es opcional.

Una limitación que conviene mencionar es que, actualmente, se pueden crear hasta 250 identidades de agente por cada plantilla de identidad de agente (sí, lo hemos probado). Es importante tener esto en cuenta a la hora de diseñar arquitecturas de agentes a gran escala.

Así pues, cuando añadamos las identidades de los agentes a nuestro esquema, quedará así:

Usuario agente

Un usuario agente es un tipo de identidad de usuario especializado que permite a una identidad de agente acceder a servicios que requieren un objeto de tipo usuario, como un buzón de correo o una interfaz de chat. La gestión de un usuario agente es similar a la de un usuario humano, y su creación es opcional en función de las necesidades de tu organización.

Solo puede existir un usuario de agente por cada identidad de agente. Cada usuario de agente debe vincularse a una única identidad de agente en el momento de su creación, y esta relación es inmutable. Dicho esto, el usuario de agente cuenta con sus propios identificadores únicos, independientes de la identidad principal, y dispone de sus propios permisos y roles.

Para crear un usuario de agente, es necesario conceder al modelo de identidad del agente unos permisos específicos, que no están habilitados de forma predeterminada.

Los usuarios de agente pueden añadirse a grupos de seguridad —excepto a los grupos a los que se pueden asignar roles— y a unidades administrativas. En cierto modo, pueden gestionarse de forma similar a los usuarios humanos, pero con varias limitaciones importantes.

Por ejemplo, no es posible restablecer la contraseña de un usuario de agente, ya que este no se autentica de forma independiente. Su autenticación depende de la identidad del agente principal.

Los usuarios de agente tampoco pueden iniciar sesión de forma interactiva, y la documentación de Microsoft indica que no se les pueden asignar roles de administrador con privilegios. (Sin embargo, nuestras observaciones no coinciden del todo con esta última afirmación; profundizaremos un poco más en ello en el siguiente capítulo.)

Volviendo al modelo de roles administrativos, los usuarios «agentes» introducen un rol adicional, además de los de «propietarios» y «patrocinadores»: el rol de «gestor».

Un «gestor» es un usuario responsable del usuario agente, del mismo modo que un gestor real supervisa a un empleado humano. Este rol es específico de los usuarios agentes y permite solicitar paquetes de acceso en nombre del usuario agente y gestionar sus necesidades operativas diarias. Es el rol con menos privilegios del modelo y no puede modificar ni eliminar agentes.

Dicho esto, y tras haber analizado a fondo la herencia, los subtipos y la estructura de las entidades de servicio, he aquí el diagrama de árbol definitivo del nuevo modelo de ID de agente:

Tipos de agentes en el portal de la interfaz de usuario

Ahora que ya hemos visto estas definiciones básicas, podemos echar un vistazo a la página de resumen de la interfaz de usuario que Microsoft publicó inicialmente como parte de la experiencia beta de Agent ID.

Aunque esta vista ya no parece estar visible en el portal (o, al menos, parece que se ha ocultado por el momento), sigue siendo útil porque muestra cómo Microsoft presentaba inicialmente los diferentes tipos de agentes y cómo se reflejaba en la interfaz de usuario la transición del antiguo modelo basado en entidades de servicio al nuevo modelo de ID de agente.

La categoría más fácil de entender es Agentes sin identidad, que coinciden con los casos de agentes que hemos comentado anteriormente: aquellos creados sin una identidad de agente asociada, es decir, Has agent ID es falso.

A continuación, el término «identidades de agente (sin usuario)» hace referencia a las identidades de agente reales del inquilino. Aunque no estén registradas como instancias de agente, se incluirán en esta categoría.

La categoría «Identidades de agente (con usuario) » refleja el número de usuarios de agente en el inquilino. Cada usuario de agente aparece aquí, siguiendo una relación estricta de 1:1 con su identidad de agente principal.

Por último, el término «agente con entidades de servicio» hace referencia a los agentes que se crearon antes de que se introdujera el modelo de ID de agente. Estos agentes siguen funcionando según el modelo de entidades de servicio. Se prevé que, con el tiempo, esta categoría se reduzca a medida que los agentes vayan adoptando el nuevo modelo de ID de agente.

Punto de control práctico: Empieza a crear tu propio ID de agente

A veces, la mejor forma de aprender es lanzarse y probar. Ahora que ya entiendes la estructura que hay detrás del modelo de Agent ID, estás listo para nuestro primer punto de control práctico.
Ponte manos a la obra y empieza a crear un Agent ID.

Explora la guía

Introducción: Cómo entender y prevenir los ataques a las identidades de Entra ID Agent: una guía completa
Conoce las identidades de Entra ID Agent (por cierto, no son personas)
La taxonomía de las identidades de cargas de trabajo en Entra ID: aplicaciones empresariales, entidades de servicio y otras formas de confusión organizada
Punto de control práctico 1: Creación de una identidad de agente con MS Graph