Autorización en el ID de agente de Microsoft Entra

La introducción de las identidades de agente se basa en el aumento de los agentes con tecnología de inteligencia artificial en las organizaciones. Los tipos de identidad tradicionales (como los registros de aplicaciones estándar o las cuentas de usuario) no son ideales para los agentes autónomos. Los agentes de inteligencia artificial tienen problemas de seguridad únicos porque sus capacidades de toma de decisiones autónomas, aprendizaje dinámico y posiblemente acceso a datos confidenciales pueden introducir comportamientos impredecibles.

Se creó el identificador de Microsoft Entra Agent para rellenar este hueco. Basado en la plataforma microsoft Entra ID, proporciona un marco de autenticación y autorización dedicados para los agentes de IA que les permite acceder de forma segura a los servicios y LAS API, a la vez que proporciona a los administradores una manera central de supervisar y controlar sus acciones. En resumen, las identidades de agente permiten a las organizaciones detectar, administrar y proteger agentes de inteligencia artificial que operan en un inquilino, con una aplicación de directivas adecuada, en lugar de tratar a los agentes como usuarios completos o aplicaciones genéricas.

En este artículo se explica cómo funciona la autorización en el id. de Agente de Microsoft Entra para los agentes de IA al proporcionar información sobre roles, controles de permisos y procedimientos recomendados para administrar el acceso al agente.

¿Por qué es importante la autorización de identidad del agente?

Los agentes de inteligencia artificial pueden ejecutar tareas rápidamente y a escala. Muchas funcionalidades con privilegios elevados en el identificador de Entra de Microsoft (por ejemplo, la capacidad de administrar usuarios o roles) asumen que un administrador humano tiene una intención cuidadosa. Un agente sin restricciones con privilegios elevados podría realizar tareas administrativas inesperadas con un impacto de gran alcance (como eliminar usuarios o cambiar la configuración de seguridad).

Por este motivo, el identificador de Entra de Microsoft limita lo que pueden hacer las identidades de agente. Por ejemplo, Microsoft Entra impide que a los agentes se les conceda muchos roles o permisos con privilegios elevados. Los usuarios y administradores no pueden dar su consentimiento a esos permisos eficaces para un agente. Este diseño reconoce que los agentes deben funcionar con privilegios mínimos. Al impedir que los agentes reciban privilegios confidenciales, el sistema minimiza el riesgo de que un agente de IA pueda escalar el acceso. La lista de roles y permisos permitidos evolucionará con el tiempo.

Asignaciones de roles para identidades de agente de Microsoft Entra

Desde el punto de vista de la autorización, una identidad del agente se comporta como una aplicación o un usuario con medidas de seguridad adicionales. Cada identidad del agente tiene un principal de servicio o un usuario en Microsoft Entra ID, y se pueden asignar determinados roles de Microsoft Entra.

Por ejemplo, la identidad de un agente se puede asignar a un rol de Microsoft Entra para concederle privilegios de administrador, pero muchos roles de directorio con privilegios elevados están bloqueados para los agentes. Los roles como administrador global, administrador de roles con privilegios o administrador de usuarios no se pueden asignar a identidades de agente. Solo se pueden asignar roles con privilegios inferiores (como un rol de lector) a un agente. No se pueden asignar roles personalizados a identidades de agente. Además, las identidades de agente no pueden ser miembros de grupos a los que se pueden asignar roles.

Microsoft ha creado los roles de Administrador de ID de agente y Desarrollador de ID de agente para administrar y crear agentes.

Los roles de Microsoft Entra permitidos para agentes

A continuación se muestra la lista de roles de Microsoft Entra que se pueden asignar a identidades de agente:

• Administrador de IA
• Autor de carga de ataque
• Administrador de simulación de ataque
• Lector de asignaciones de atributos
• Lector de definiciones de atributos
• Administrador del registro de atributos
• Lector de registro de atributos
• Administrador de Azure DevOps
• Administrador de Azure Information Protection
• Administrador de políticas de IEF B2C
• Administrador de facturación
• Administrador de Cloud App Security
• Administrador de cumplimiento
• Administrador de datos de cumplimiento
• Aprobador de acceso de Customer LockBox
• Administrador de análisis de escritorio
• Lectores de directorios
• Cuentas de sincronización de directorios
• Administrador de Dynamics 365
• Administrador de Dynamics 365 Business Central
• Administrador de Microsoft Edge
• Administrador de Exchange
• Administrador de destinatarios de Exchange
• Administrador de usuarios de directorio extendido
• Administrador del proceso de usuario de ID externa
• Administrador de atribución de flujo de usuario con ID externa
• Administrador de Fabric
• Lector global
• Lector de registros de acceso seguro global
• Administrador de Insights
• Analista de conclusiones
• Líder de Insights Empresariales
• Administrador de dispositivos IoT
• Administrador de Kaizala
• Administrador de información
• Responsable del conocimiento
• Administrador de licencias
• Lector de privacidad del Centro de mensajes
• Lector del Centro de mensajes
• Administrador de Copia de seguridad Microsoft 365
• Administrador de migración de Microsoft 365
• Administrador local de dispositivos integrados en Microsoft Entra
• Administrador de Microsoft Graph Data Connect
• Administrador de garantía de hardware de Microsoft
• Especialista en garantía de hardware de Microsoft
• Administrador de red
• Administrador de aplicaciones de Office
• Administrador de marca organizacional
• Administrador de orígenes de datos de la organización
• Aprobador de mensajes organizacionales
• Redactor de mensajes organizativos
• Administrador de personas
• Administrador de lugares
• Administrador de Power Platform
• Administrador de impresoras
• Técnico de impresoras
• Lector de informes
• Administrador de búsqueda
• Editor de búsqueda
• Administrador de soporte técnico del servicio
• Administrador de SharePoint
• Administrador integrado de SharePoint
• administrador de Skype Empresarial
• Administrador de Teams
• Administrador de comunicaciones de Teams
• Ingeniero de soporte técnico de comunicaciones de Teams
• Especialista de soporte técnico de comunicaciones de Teams
• Administrador de dispositivos de Teams
• Lector de Teams
• Administrador de telefonía de Teams
• Creador de inquilinos
• Lector de informes de resumen de uso
• Gerente de éxito de la experiencia del usuario
• Virtual Visits Administrator (Administrador de visitas virtuales)
• administrador de inquilinos de Viva Glint
• Administrador de Viva Goals
• Administrador de Viva Pulse
• Administrador de Windows 365
• Administrador de implementación de Windows Update
• Administrador de Yammer

Permisos de Microsoft Graph para identificadores de agente

Para los permisos de OAuth2, los IDs de agentes —en concreto, los planos de identidad de agente y los principales del plano de identidad de agente— pueden utilizar el mismo modelo de permisos de Microsoft Graph que otras aplicaciones. Los agentes pueden solicitar permisos delegados (actuar en nombre de un usuario mediante consentimiento) o permisos de aplicación (privilegios de solo aplicación concedidos por un administrador).

Sin embargo, un conjunto de permisos de Microsoft Graph API de alto riesgo se bloquean explícitamente para los agentes. Por ejemplo, no se puede conceder a un agente los permisos siguientes:

Los identificadores de agentes todavía pueden recibir permisos con privilegios inferiores según corresponda. Por ejemplo, si un agente necesita leer el buzón de un usuario o un archivo de OneDrive en nombre de ese usuario, puede solicitar un permiso delegado como Mail.Read o Files.Read y el usuario (o administrador) puede dar su consentimiento. Estos no se consideran privilegios elevados en el sentido de todo el cliente; están vinculados a los datos de ese usuario.

Lo que está bloqueado son los privilegios con ámbito de inquilino que van más allá de un solo usuario o implican un control administrativo. Los agentes operan bajo un principio de ámbito limitado. Los agentes solo pueden hacer lo que un usuario normal podría consentir, o lo que un administrador concede explícitamente de manera controlada y delimitada.

Cuándo usar roles de Azure, roles de Microsoft Entra o permisos de Microsoft Graph

En función de lo que necesite hacer un agente, los administradores pueden conceder acceso de maneras diferentes para mantener el ámbito adecuado. Esto incluye la asignación de roles de Azure, roles de Microsoft Entra, concesiones de permisos de OAuth, incluidos los permisos de Microsoft Graph, las asignaciones de roles de aplicación, las asignaciones de paquetes de acceso y pertenencias a grupos.

Roles de Azure

Si un agente necesita acceder a los recursos de Azure: asigne roles de Azure para esos recursos específicos. Por ejemplo, para permitir que un agente lea un Azure Key Vault, asigne a su identidad el rol de Key Vault Reader en ese almacén. Esto mantiene el ámbito restringido (solo ese recurso o grupo de recursos) y usa privilegios mínimos. Para más información, consulte Asignación de roles de Azure mediante Azure Portal.

roles de Microsoft Entra

Si un agente necesita realizar acciones de nivel de directorio: use roles de Microsoft Entra solo si existe un rol con privilegios inferiores adecuado. Por ejemplo, si un agente solo necesita leer información básica del directorio, puede usar un rol de tipo lector de directorio. Si necesita conceder acceso de escritura a un agente, revise las implicaciones y seleccione el rol con privilegios mínimos. Es posible que no haya un rol integrado adecuado que no esté bloqueado. En esos casos, puede optar por confiar en los permisos de Microsoft Graph en su lugar (con la comprensión de sus límites). Para obtener más información, consulte Asignar roles de Microsoft Entra.

Permisos delegados de Microsoft Graph

Si un agente actúa en nombre de un usuario (escenarios centrados en el usuario): use permisos delegados de Microsoft Graph. Esta opción requiere consentimiento interactivo del usuario, pero garantiza que el agente no puede superar el acceso del usuario. Por ejemplo, un agente programando reuniones para Alice usaría permisos de API de calendario delegados; Alice da su consentimiento y el agente solo puede administrar el calendario de Alice (igual que Alice podría hacerlo por sí misma). Para obtener más información, consulte Información general sobre los permisos y el consentimiento en la plataforma de identidad de Microsoft.

Permisos de aplicación de Microsoft Graph

Si un agente se ejecuta de forma autónoma en el inquilino (escenarios de servicio): use los permisos de aplicación de Microsoft Graph con moderación. Conceda solo los permisos de aplicación específicos necesarios y solo si no son privilegios elevados. Por ejemplo, un agente que genera organigramas organizativos podría necesitar el permiso de aplicación User.Read.All para leer todos los perfiles, lo que podría ser aceptable (y no está en la lista de bloqueados), mientras que User.ReadWrite.All se rechazaría.

Revise siempre el ámbito del permiso: el acceso de lectura a nivel de arrendatario puede estar bien para determinados datos, pero el acceso de escritura o el control a nivel de arrendatario no están permitidos para los agentes. Los administradores deben dar su consentimiento explícito a cualquier permiso de aplicación que obtenga un agente, por lo que hay una oportunidad para revisar estas solicitudes cuidadosamente. Para obtener más información, consulte Información general sobre los permisos y el consentimiento en la plataforma de identidad de Microsoft.

Permisos heredables para identidades de agente

Los planos técnicos de identidad del agente admiten permisos heredados, que permiten a los administradores conceder permisos una vez en el nivel de plano técnico y hacer que esas concesiones se apliquen automáticamente a todas las identidades de agente creadas a partir del plano técnico. Esta funcionalidad reduce las solicitudes de consentimiento repetidas en varias implementaciones y entornos.

Para obtener más información sobre cómo funcionan conjuntamente los permisos heredables, el acceso a los recursos necesarios y las concesiones directas, consulte Permisos que se pueden heredar.