Identidades de los agentes: análisis en profundidad del diseño

Nota del editor: Bienvenido al capítulo 4 de «Comprender y prevenir los ataques a la identidad de los agentes de Entra ID: una guía completa». Esta guía técnica, dividida en varias partes, te ayuda a comprender el enfoque de Microsoft respecto a las identidades de los agentes y cómo puedes protegerlas frente a los autores de amenazas. Para repasar los capítulos anteriores y las lecciones prácticas, empieza aquí.

En el capítulo anterior de esta guía exhaustiva sobre la prevención de ataques a la identidad de los agentes de Entra ID, definimos los objetos fundamentales que conforman el modelo de Agent ID. Teniendo en cuenta ese modelo general —y, esperemos, tras haber hecho un breve desvío para practicar la creación de Agent ID con MS Graph—, estamos listos para profundizar en la comprensión de cómo se estructuran las identidades en la plataforma Agent ID.

Volvamos al tema.

Exploración del modelo de datos de Microsoft Graph

Para comprender cómo se representan los cuatro componentes básicos de la identidad en la jerarquía de datos subyacente de Microsoft Graph, podemos examinar el punto final de metadatos de Graph.

Microsoft Graph expone su modelo de datos a través del punto final de metadatos OData en https://graph.microsoft.com/beta/$metadata. Al acceder a él, se obtiene un documento XML que define los tipos de entidad, los tipos complejos, las enumeraciones y las relaciones que admite la API. En términos más sencillos, se trata del mapa estructural de Microsoft Graph. No nos indica todo lo que la plataforma permitirá en tiempo de ejecución, pero sí nos muestra cómo ha decidido Microsoft modelar los objetos.

Microsoft explica que estos metadatos ayudan a los desarrolladores a comprender el modelo de datos y las relaciones entre las entidades. Para los investigadores de seguridad, este punto de acceso resulta extremadamente valioso, ya que revela la jerarquía de herencia y las definiciones de propiedades que determinan el comportamiento de los objetos de Entra ID, incluidos los nuevos tipos de Agent ID.

Dicho esto, Agent ID sigue siendo una interfaz en constante evolución, y es posible que algunos detalles del esquema cambien a medida que la plataforma vaya madurando.

Antes de entrar en detalle sobre los propios objetos, aclaremos que hay dos conceptos relacionados con los metadatos que conviene distinguir: EntityType y ComplexType.

• Un EntityType suele representar un objeto al que se puede acceder directamente a través de su propio punto final, que tiene propiedades de navegación (relaciones con otras entidades) y que puede almacenarse, recuperarse y actualizarse de forma independiente. Algunos ejemplos de este tipo de entidades son user, application, servicePrincipaly group.
• A ComplexType es un tipo de valor estructurado que agrupa varias propiedades. No tiene identidad propia, sino que existe integrado en una entidad (o incluso dentro de otra ComplexType) y no se pueden consultar directamente como objetos independientes. Algunos ejemplos de este tipo de tipos son apiApplication, appRole, federatedIdentityCredentialy keyCredential.

Piénsalo de esta manera: un EntityType es como una fila de una tabla de una base de datos, y un ComplexType es un objeto JSON anidado dentro de esa fila.

En la respuesta de metadatos XML, podemos ver el tipo de entidad base abstracto del que heredan casi todos los tipos de entidad de Graph (y por eso casi todos los recursos de Microsoft Graph tienen, en última instancia, una cadena de identificación):

La siguiente pieza es la directoryObject entidad, que hereda de entidad.

A partir de ahí, podemos analizar servicePrincipal tipo y su estructura.

La interfaz de usuario basada en texto no es, por decirlo suavemente, el formato más legible para navegar por un documento de metadatos de 428 KB, así que hemos creado sobre la marcha una aplicación web local para que resulte un poco más sencillo recorrer estas relaciones entre entidades.

Ahora, en lugar de intentar comprender el tipo de entidad «agentIdentity» fijándonos en sus metadatos sin procesar:

… podemos explorar visualmente la jerarquía de objetos e interactuar con las relaciones que rodean a cada tipo de una forma más orientada a la investigación:

Los metadatos nos indican que agentIdentity hereda de servicePrincipal (con OpenType="true", lo que significa que también pueden existir propiedades dinámicas o no documentadas adicionales) y añade el siguiente pequeño conjunto de elementos específicos del agente a nivel de subtipo:

• Dos propiedades:
  • agentIdentityBlueprintId (una cadena obligatoria que vincula la identidad del agente con su modelo de referencia)
  • createdDateTime
• Tres propiedades de navegación:
  • patrocinadores (una recopilación de directoryObject)
  • inheritedAppRoleAssignments (una recopilación de appRoleAssignment)
  • inheritedOauth2PermissionGrants (una recopilación de oAuth2PermissionGrant)

Las dos últimas son incorporaciones recientes al esquema beta y revisten especial importancia, ya que representan el mecanismo de herencia de permisos desde el sujeto principal «Agent Identity Blueprint» hasta la identidad del agente. Microsoft describe estas asignaciones de roles de aplicación heredadas y estas concesiones delegadas como permisos efectivos que se aplican en el momento de la emisión del token.

Es aquí también donde empieza a quedar más clara la diferencia entre los «agentes clásicos» y los «agentes modernos» de Entra ID.

• Los agentes clásicos, como los creados por Copilot Studio y Azure AI Foundry antes de que se introdujera el nuevo modelo de ID de agente, se representan en segundo plano mediante objetos de entidad de servicio normales.
• Agentes modernos, por otro lado, están representados a través del nuevo agentIdentity subtipo.

Sabiendo esto, es fácil comprender por qué filtrar por la columna «Agent Blueprint ID» en el portal Agent ID (versión preliminar) puede ayudar a separar estos dos mundos. Los objetos con un agentIdentityBlueprintId pertenecen al nuevo modelo de ID de agente, mientras que los agentes más antiguos, respaldados por entidades de servicio, no.

Cabe señalar que los metadatos de la versión 1.0 muestran actualmente una definición más simplificada del esquema, sin los dos inherited* propiedades de navegación activadas agentIdentity. Este tipo de diferencia entre la versión beta y la v1.0 es habitual en las funciones en fase de vista previa, pero tiene un impacto real en la seguridad para los responsables de la seguridad que deseen evaluar agentes de Entra ya integrados en su organización. Cualquier herramienta de auditoría, producto CSPM o script de enumeración de permisos que no tenga en cuenta estas relaciones de permisos heredados podría pasar por alto parte de la visión global de los permisos efectivos de los objetos de ID de agente.

Y si configuramos permisos heredables en un blueprint, concedemos consentimiento de administrador al sujeto del blueprint y consultamos un agente asociado a él a través de diferentes versiones de la API, esa brecha se hace evidente.

Todo lo demás —las más de 40 propiedades y las más de 20 propiedades de navegación de la servicePrincipal objeto—se hereda estructuralmente. Esto incluye propiedades como keyCredentials, passwordCredentials, owners, federatedIdentityCredentialsy memberOf.

Sin embargo, es precisamente ahí donde el esquema puede llevarnos a error.

La herencia OData describe la estructura del modelo de objetos. No garantiza que todas las capacidades heredadas estén disponibles desde el punto de vista funcional en tiempo de ejecución. La documentación de Microsoft señala explícitamente este patrón para los recursos relacionados con el ID de agente:

…aunque este recurso hereda de `servicePrincipal`, algunas propiedades no son aplicables.

Las propiedades de las credenciales son el ejemplo más claro de ello, ya que las identidades de agente no tienen credenciales propias: ni contraseñas, ni certificados, ni secretos de cliente. Dependen del modelo principal para obtener tokens en su nombre; la API rechaza cualquier intento de añadir credenciales directamente a un objeto de identidad de agente.

Así que, aunque keyCredentials y passwordCredentials Si aparecen en el esquema heredado, son nulos o están vacíos en el caso de las identidades de los agentes y, en la práctica, no están disponibles. Esa restricción no proviene del propio archivo de metadatos, sino de las rutas de código de la lógica de tiempo de ejecución en la capa de la API, que deben reconocer el subtipo y rechazar las operaciones que no deberían aplicarse.

Algo parecido ocurre con el agentIdentityBlueprintPrincipal objeto, que también hereda de servicePrincipal y solo añade la relación de propietario en la definición de su subtipo. Al igual que la identidad del agente, hereda el conjunto completo de credenciales de servicePrincipal En teoría, pero en la práctica, sus credenciales se gestionan a través del objeto de aplicación «blueprint», y las operaciones sobre el objeto están vinculadas a medidas de seguridad específicas para cada punto final, comprobaciones dinámicas en tiempo de ejecución, etc.

Esta es una de las lecciones más importantes en materia de seguridad del modelo Agent ID: el esquema nos indica qué hereda el objeto, pero la plataforma debe seguir controlando lo que el objeto tiene permitido hacer.

La parte del problema que depende del usuario

En agentUser La entidad sigue el mismo patrón de herencia que hemos estado analizando, pero en esta ocasión se sitúa por encima de la user objeto en lugar de servicePrincipal.

Y si superponer subtipos de agentes sobre la superficie de la entidad de servicio es un tema delicado, superponerlos sobre la superficie del usuario es, sin duda, aún más delicado. El objeto de usuario afecta a las políticas de autenticación, las licencias, las funciones de colaboración, la pertenencia a grupos, la estructura organizativa y los flujos de asignación administrativa, que se diseñaron originalmente en torno a identidades humanas.

Al examinar los metadatos, agentUser hereda de graph.user y no añade ninguna propiedad nueva ni ninguna propiedad de navegación nueva a nivel de subtipo. En otras palabras, cada propiedad y cada documentado La relación que tiene un usuario agente depende del tipo de base de usuarios.

Sin embargo, «cero atributos nuevos» no significa que no haya ninguna señal distintiva.

En identityParentId La propiedad, que vincula al usuario agente con la identidad de su agente principal, se define en el propio tipo base de usuario. Para los humano Para los usuarios normales, esta propiedad siempre es nula, pero para los usuarios agentes, contiene el ID del objeto de la identidad del agente asociada y es obligatoria en el momento de la creación. La documentación de Microsoft también señala que esta relación es inmutable una vez establecida y no se puede eliminar ni modificar.

A diferencia de lo que ocurre en el agentIdentity y agentIdentityBlueprintPrincipal En cuanto a los objetos, Microsoft tomó aquí una decisión arquitectónica para trasladar la propiedad distintiva al tipo padre, en lugar de establecerla en el subtipo, lo que significa que los metadatos de OData por sí solos no nos indicarán que agentUser sea otra cosa que un usuario y la única señal a nivel de esquema sea la @odata.type discriminador en el propio objeto.

Esta distinción es importante debido a la función para la que están diseñados los usuarios-agente. A diferencia de las identidades de agente, que son objetos derivados de entidades de servicio y se autentican mediante flujos de tokens exclusivos de la aplicación, los usuarios-agente existen específicamente para contextos en los que se requiere una identidad con características propias de un usuario.

En términos de tokens, reciben tokens con el idtyp=user autorización, lo que significa que pueden acceder a API y servicios que comprueban específicamente si se trata de un token de usuario en lugar de un token de aplicación (Outlook, Teams, SharePoint y cualquier otro servicio que se base en el tipo de identidad), de modo que puedan disponer de buzones de correo, unirse a canales de Teams y aparecer en los organigramas. La visión de un asistente personal con IA en todo su esplendor.

Microsoft ha documentado varias restricciones de seguridad relativas a las identidades de los usuarios de los agentes:

• No pueden tener contraseñas ni claves de acceso.
• No se les pueden asignar roles de administrador con privilegios.
• No tienen acceso a las asignaciones de roles personalizadas ni a los grupos a los que se pueden asignar roles.
• Su modelo de permisos por defecto es similar al de los usuarios invitados, aunque con capacidades algo más amplias para enumerar usuarios y grupos.

Se trata de medidas de seguridad importantes. Pero cada una de ellas debe aplicarse en la capa de la API y de políticas, de forma individual, para cada ruta de código que afecte a un user objeto.

Esa es la parte incómoda. Si un punto final trata agentUser como uno más user y se olvida de aplicar las restricciones específicas de cada subtipo, el resultado no es solo un error. Puede convertirse en un problema relacionado con los límites de privilegios.

Por ejemplo, a pesar de que el restricciones oficiales de seguridad En lo que respecta a la asignación de roles con privilegios, durante las pruebas pudimos asignar usuarios de agente 3 de 32 roles marcados con isPrivileged=true:

• Global Reader: Acceso de lectura total a todo el directorio y a los datos de Microsoft 365
• Security Reader: Acceso de lectura a las herramientas de seguridad, Microsoft Defender e Identity Protection
• Administrador de IA: Control administrativo sobre las funciones relacionadas con la IA y los agentes

También pudimos asignar muchos roles que no están marcados como privilegiados (o que se tratan como standardAssigned), pero que, en la práctica, corresponden al Nivel 0, como el administrador de facturación, el administrador de Exchange, el administrador de SharePoint y las cuentas de sincronización de directorios.

Este patrón no es nuevo, ni es exclusivo de las identidades de los agentes.

La concesión excesiva de permisos al rol de «Administrador de IA» y^{el hallazgo} de Silverfort¹ que comentamos en el capítulo anterior son los ejemplos más recientes, pero forman parte de una serie bien documentada de «lagunas de alcance» de Entra ID. En estos casos, un permiso o un rol que parece actuar sobre una clase más restringida de objetos acaba abarcando el tipo base más amplio o una superficie de control más sensible de lo esperado. Las clásicas rutas de escalada de privilegios del «Administrador de aplicaciones» y del «Administrador de aplicaciones en la nube» son ejemplos paradigmáticos de ello.

Documentado exhaustivamente por Dirk-jan Mollema²y SpecterOps,³ Estas vías de escalada de privilegios se aprovechan del hecho de que los roles pueden añadir credenciales a cualquier entidad de servicio en el inquilino. Si una entidad de servicio tiene permisos de aplicación de alto impacto, como RoleManagement.ReadWrite.Directory o AppRoleAssignment.ReadWrite.All—o al que se le hayan asignado roles de directorio con privilegios—, añadir credenciales al mismo puede permitir al atacante autenticarse como esa entidad de servicio e heredar sus privilegios efectivos.

La cuestión relativa al alcance en este caso es sutil; la función se describe, con toda sinceridad, como la gestión de aplicaciones. La suposición peligrosa es que «gestionar aplicaciones» no debería significar también «poder hacerse cargo de entidades de servicio arbitrarias con privilegios elevados». Microsoft introdujo posteriormente controles de bloqueo de propiedades de instancias de aplicaciones para reducir parte de este riesgo, pero la clase de problema subyacente sigue siendo importante: el control sobre un objeto puede convertirse en control sobre los permisos ya asociados a dicho objeto.

Estudio de Semperis de 2024 sobre UnOAuthorized puso de manifiesto otra versión de este patrón. Los administradores de aplicaciones y los administradores de aplicaciones en la nube podían utilizar varias entidades de servicio propias de Microsoft (¿recuerdas este tipo de la taxonomía?) para añadir y eliminar usuarios de roles con privilegios. El problema no era simplemente un «exceso de permisos» en abstracto. Se trataba de una discrepancia entre los límites previstos para los roles y la forma en que se evaluaban en la práctica los ámbitos de OAuth 2.0 y las entidades de servicio propias.

Del mismo modo, Datadog I SPy⁴La información publicada a partir de 2025 reveló otra variación más. En determinados escenarios, los principales de servicio con los roles de «Administrador de aplicaciones en la nube», «Administrador de aplicaciones» o Application.ReadWrite.All podría secuestrar la entidad de servicio de Exchange Online de Office 365 añadiéndole credenciales. En entornos híbridos, esto podría encadenarse, a través de una relación de confianza de dominio federada, hasta obtener acceso de administrador global. Una superficie de ataque diferente, pero la misma lección: los permisos limitados a «aplicaciones» pueden resultar mucho más peligrosos cuando la propia aplicación objetivo es, a su vez, una primitiva de confianza con privilegios.

Y la vulnerabilidad «Actor Token» de Dirk-jan Mollema,^⁵ CVE-2025-55241, aunque estructuralmente diferente, pertenece a la misma familia general. En ese caso, unos tokens internos no documentados de suplantación de identidad entre servicios, combinados con una brecha en la validación de inquilinos en la API heredada de Azure AD Graph, permitieron la suplantación de identidad entre inquilinos de cualquier usuario, incluidos los administradores globales, sin registros y sin aplicación del acceso condicional. La brecha de alcance en este caso se situaba en el límite del inquilino, en lugar de en el límite del subtipo de objeto, pero la lección fundamental es la misma: cuando se introduce una primitiva privilegiada sin una validación estricta en cada punto de consumo, tarde o temprano uno de esos puntos se convierte en una vía de acceso.

Entonces, ¿qué significa todo esto?

Bueno, en primer lugar, ese «Agent ID» no es un nuevo tipo de objeto aislado. Se trata de un nuevo modelo de identidad que se superpone a los elementos básicos que Entra ID ya conoce muy bien: aplicaciones, entidades de servicio, usuarios, autorizaciones OAuth, asignaciones de roles de aplicación, credenciales y roles de directorio.

Y, en segundo lugar, ese diseño es práctico, pero también implica que el modelo de seguridad depende de un factor más delicado. La jerarquía del esquema de metadatos nos permite saber qué hereda un objeto, pero solo el comportamiento en tiempo de ejecución nos indica a qué capacidades heredadas se puede acceder realmente.

Esta es la tensión fundamental de Agent ID: Microsoft está otorgando a los agentes de IA una representación de primer orden dentro de Entra ID, pero lo hace ampliando tipos de objetos que ya tienen un significado de seguridad acumulado a lo largo de años. Cada propiedad heredada, cada acción de rol, cada flujo de tokens y cada punto final pasa a formar parte ahora de la cuestión.

Así que, antes de hablar de cómo hacer un uso indebido, proteger o supervisar las identidades de agente, primero tenemos que entender cómo es eso en sí mismo.

Y ahora, con un poco de suerte, esa idea está un poco más clara.

Vale, hablemos de los permisos

La plataforma Agent ID introduce nuevos tipos de identidad que pueden realizar acciones autónomas, actuar en nombre de los usuarios y disponer de permisos persistentes. Comprender su modelo de permisos es esencial para prevenir la escalada de privilegios y evitar vías de acceso no deseadas que puedan tener un gran impacto. Este modelo también introduce un nuevo concepto de permiso heredable, que debemos comprender.

Permisos exclusivos de la aplicación y permisos delegados

Al igual que las aplicaciones normales y los principales de servicio, a los modelos de identidad de agente y a las identidades de agente se les pueden asignar permisos exclusivos de la aplicación o permisos delegados.

Como hemos visto anteriormente, el modelo de identidad del agente siempre incluye un permiso exclusivo de la aplicación— AgentIdentity.CreateAsManager—por defecto, lo que le permite crear y gestionar las identidades de los agentes.

En lo que respecta a las identidades de los agentes, se deben utilizar permisos exclusivos de la aplicación cuando el agente actúe de forma totalmente autónoma. Los permisos delegados se aplican cuando un usuario participa en el flujo de trabajo y el agente necesita actuar en nombre de dicho usuario.

Permisos heredables

Los permisos heredables son una configuración de herencia de permisos definida a nivel del modelo de identidad del agente. Permiten que las identidades de agente creadas a partir del modelo hereden automáticamente los permisos aprobados del modelo, en lugar de tener que otorgar el mismo consentimiento por separado para cada identidad de agente.

En un principio, esto se aplicaba principalmente a los permisos delegados, pero la documentación actual de Microsoft describe ahora que los permisos heredables son compatibles tanto con los ámbitos delegados como con las funciones de aplicación. Los ámbitos delegados aparecen en el token de acceso delegado de la identidad del agente en el scp reclamación, mientras que los roles de aplicación aparecen en el token de acceso exclusivo para la aplicación en el roles afirmación.

Para que los permisos heredables surtan efecto, no basta con configurar el blueprint. Deben cumplirse dos condiciones:

• La aplicación de recursos correspondiente debe configurarse en el blueprint’s inheritablePermissions.
• También se debe conceder el permiso al sujeto del blueprint.

Microsoft describe esto como la diferencia entre declaración, concesión y herencia: inheritablePermissions es una configuración, mientras que el consentimiento sobre el sujeto del esquema es lo que otorga la autorización.

Esto significa que el allAllowed Esta configuración no debe interpretarse como que «el agente obtiene automáticamente todos los permisos que expone la aplicación de recursos». Significa que todos los permisos válidos de ese tipo, para esa aplicación de recursos, que se concedan al sujeto del modelo pueden transmitirse a las identidades de los agentes. El token efectivo es, por tanto, el resultado de la combinación de los permisos heredados y de cualquier permiso concedido directamente a la identidad específica del agente.

La configuración se realiza a través de la aplicación de recursos, y los ámbitos delegados y los roles de aplicación se pueden configurar de forma independiente para un mismo recurso. Por ejemplo, un modelo puede heredar ámbitos delegados, pero no roles de aplicación; puede heredar roles de aplicación, pero no ámbitos delegados. Los ejemplos de Microsoft lo ilustran utilizando inheritableScopes y inheritableRoles por separado.

Para que los permisos delegados y heredables surtan efecto, la entidad de servicio del blueprint debe disponer ya de los correspondientes OAuth2PermissionGrants entradas para esos ámbitos, tras haber dado el consentimiento a nivel de plano.

En el caso de los permisos delegados, los patrones de herencia de ámbito documentados son los siguientes:

• allAllowed: Estos patrones heredan todos los ámbitos delegados disponibles para el recurso al que han concedido acceso.
• noScopes: Estas plantillas no heredan ningún ámbito delegado para esa aplicación de recursos.
• enumerated: Estos patrones, que solo aparecen en la documentación de la API beta, incluyen únicamente los ámbitos especificados en la lista. Al utilizar el patrón enumerado, puedes incluir hasta 40 ámbitos por aplicación de recursos.

En cuanto a los permisos de las aplicaciones, los patrones de herencia exclusivos de la aplicación que figuran actualmente en la documentación son los siguientes:

• allAllowed: Estas plantillas heredan todos los ámbitos de aplicación disponibles para la aplicación de recursos a la que han concedido acceso.
• noRoles: Estas plantillas no heredan ningún rol de aplicación para esa aplicación de recursos.

Ahora bien, la documentación oficial no incluye ninguna opción específica para la herencia exclusiva de la aplicación. Sin embargo, tras realizar algunas pruebas, hemos comprobado que esta opción puede incluirse en el flujo de herencia exclusiva de la aplicación.

El siguiente esquema muestra el concepto en el que se basan los permisos enumerados, heredables y delegados. Un esquema similar sería aplicable a los permisos exclusivos de la aplicación, que funcionan de manera muy similar. (Las diferencias se mostrarán en el punto de verificación práctico 2.)

Un modelo puede definir permisos heredables para un máximo de 60 aplicaciones de recursos. Este límite no es exclusivo de los modelos.

También es importante señalar que algunos permisos de Microsoft Graph de alto riesgo están bloqueados para las identidades de agente. Microsoft indica que los ámbitos de permisos delegados o las funciones de aplicación bloqueados no pueden concederse a las identidades de agente, y que incluir un ámbito delegado o una función de aplicación bloqueados provoca que la solicitud sea rechazada.

Los permisos heredables son opcionales. Aunque no se utilicen, los permisos se pueden conceder directamente a cada identidad de agente de forma individual. La diferencia radica en que las concesiones directas solo se aplican a esa identidad de agente concreta, mientras que los permisos heredables permiten al administrador aprobar los permisos una sola vez a nivel de plantilla y hacer que los permisos aplicables se transfieran a las identidades de agente actuales y futuras creadas a partir de dicha plantilla.

Pertenencia a un grupo (solo para usuarios agentes)

La pertenencia a un grupo está limitada a los usuarios de tipo «agente». Los usuarios de tipo «agente» pueden añadirse a grupos de seguridad, pero no a grupos a los que se puedan asignar roles. Heredan los permisos de su pertenencia a los grupos del mismo modo que lo hacen los usuarios normales.

Roles de Microsoft Entra

A las identidades de agente se les pueden asignar roles de directorio de Microsoft Entra, de forma similar a las entidades de servicio, pero con importantes limitaciones. Los roles con privilegios elevados, como «Administrador global», «Administrador de roles con privilegios» y «Administrador de usuarios», no se pueden asignar a identidades de agente. Solo se admite un subconjunto definido de roles de Microsoft Entra, y algunos de esos roles siguen siendo de carácter administrativo, por lo que deben asignarse con cuidado en función de la finalidad prevista del agente y de los requisitos de privilegios mínimos.

La lista completa de funciones compatibles está disponible aquí.

Paquete de acceso

Además de asignar el acceso directamente a la identidad de un agente, las organizaciones pueden utilizar paquetes de acceso. Un paquete de acceso permite que el agente, o un conjunto de agentes con las mismas necesidades, acceda a los recursos. Los paquetes de acceso pueden incluir roles de Entra, pertenencias a grupos de seguridad, permisos delegados de OAuth2 y permisos de aplicación, todos ellos descritos anteriormente.

Los paquetes de acceso los configura un administrador, quien define:

• ¿Qué recursos se incluyen?
• ¿Quién puede solicitar el acceso?
• ¿Quién debe autorizar el acceso?
• Cuánto tiempo dura el acceso
• Y otras opciones de configuración

Un agente puede solicitar un paquete de acceso por su cuenta, o bien un patrocinador o un responsable puede solicitarlo en su nombre. El administrador también puede asignarlo directamente. Una vez aprobado, el agente recibe acceso por un tiempo limitado a los recursos incluidos, y un patrocinador puede solicitar una prórroga si es necesario.

Resumen de la cuestión de los permisos

Para resumir el modelo de permisos, cada componente de la plataforma Agent ID puede tener sus propios permisos. Las identidades de agente pueden tener permisos exclusivos de la aplicación o permisos delegados; los usuarios de agente pueden formar parte de grupos; y los plantillas de identidad de agente pueden definir permisos heredables que se transmiten a todas las identidades de agente creadas a partir de ellas. Dependiendo del flujo de autenticación, los elementos pertinentes se combinan durante la ejecución.

En el caso de un flujo «En nombre de», junto con los nuevos permisos heredables, los permisos finales del agente quedarán así:

Se espera un flujo similar cuando se utilizan los permisos exclusivos de la aplicación junto con los permisos heredables. Basta con sustituir todos los términos delegados por términos exclusivos de la aplicación.

Siguiente: Práctica sobre cómo configurar los permisos de identidad de los agentes

Ahora, haz una pequeña parada en nuestro segundo punto de control práctico y sigue los pasos para asignar permisos a la identidad de agente que configuraste en el primer ejercicio.

Practica cómo configurar los permisos de identidad de los agentes.

Explora la guía

• Introducción: Cómo comprender y prevenir los ataques a la identidad de los agentes de Entra ID: una guía completa
• Capítulo 1: Conoce las identidades de los agentes de Entra ID (por cierto, no son personas)
• Capítulo 2: La taxonomía de las identidades de carga de trabajo en Entra ID: aplicaciones empresariales, entidades de servicio y otras formas de confusión organizada
• Capítulo 3: Introducción al ID de Microsoft Agent y a la plataforma de identidad de Agent
• Punto de control práctico 1: Creación de un identificador de agente con MS Graph
• Punto de control práctico 2: Configuración de los permisos de identidad de los agentes

Notas finales

1. https://www.silverfort.com/blog/agent-id-administrator-scope-overreach-service-principal-takeover-in-entra-id/
2. Escalada de privilegios en Azure AD: cómo hacerse con los permisos predeterminados de una aplicación como administrador de la aplicación – dirkjanm.io
3. Escalada de privilegios en Azure mediante el abuso de entidades de servicio – SpecterOps
4. I SPy: Escalación al administrador global de Entra ID mediante una aplicación propia | Datadog Security Labs
5. Vulnerabilidad del token de actor