Conceptos de identidad del agente en Microsoft Foundry

Una identidad de agente es un tipo de identidad especializado en Microsoft Entra ID diseñado específicamente para agentes de IA. Proporciona un marco estandarizado para gobernar, autenticar y autorizar agentes de inteligencia artificial en servicios Microsoft. Este marco permite a los agentes access recursos de forma segura, interactuar con los usuarios y comunicarse con otros sistemas.

Microsoft Foundry aprovisiona y administra automáticamente las identidades del agente durante todo el ciclo de vida del agente. Esta integración simplifica la administración de permisos al tiempo que mantiene la seguridad y la auditabilidad a medida que los agentes pasan de desarrollo a producción.

En este artículo se explica cómo se relacionan las identidades del agente con los objetos de Microsoft Entra ID, cómo los usa Foundry cuando un agente llama a herramientas y cómo aplicar el acceso con privilegios mínimos con el control de acceso basado en rol (RBAC) de Azure.

Prerrequisitos

• Comprensión de la autenticación Microsoft Entra ID y OAuth
• Conocimientos de control de acceso basado en roles (RBAC) de Azure
• Conocimientos básicos de los agentes de inteligencia artificial y sus requisitos en tiempo de ejecución

Para ver los ámbitos y roles RBAC específicos de Foundry, consulte el control de acceso basado en roles de Azure en Foundry.

Funcionamiento de las identidades de agente en Foundry

Foundry usa identidades de agente de Microsoft Entra ID para dar respuesta a dos necesidades relacionadas:

• Administración y gobernanza: proporcione a los administradores una manera coherente de realizar el inventario de agentes, aplicar directivas y actividad de auditoría.
• Autenticación de herramientas: permitir que un agente se autentique en sistemas descendentes (por ejemplo, Azure Storage) sin incorporar secretos en mensajes, código o cadenas de conexión.

En un nivel alto, Foundry hace lo siguiente:

1. Se aprovisiona un plano técnico de identidad del agente y una o más identidades de agente en Microsoft Entra ID.
2. Asigna roles de RBAC (u otros modelos de permisos, según el sistema de destino) a la identidad del agente.
3. Cuando el agente invoca una herramienta, Foundry solicita un token de acceso para el servicio descendente y usa ese token para autenticar la llamada a la herramienta.

Intercambio de tokens en tiempo de ejecución

Cuando un agente invoca una herramienta, se produce automáticamente un intercambio de tokens OAuth 2.0 de varios pasos entre el servicio de agente, Microsoft Entra ID y el recurso descendente. Los desarrolladores no administran tokens directamente: el servicio del agente controla todo el intercambio.

El intercambio avanza a través de cuatro fases:

• Autenticación de Blueprint: el servicio Agente presenta las credenciales de OAuth de Blueprint a Microsoft Entra ID. Esto demuestra que el servicio Agente está autorizado para actuar en nombre de Blueprint y las identidades de sus agentes.

• Agent identity token issuance: Microsoft Entra ID valida las credenciales del plano técnico y emite un token para la identidad específica del agente. Este token es distinto de los tokens de usuario humano o identidad administrada; identifica al agente como un actor independiente en el directorio.

• Solicitud de token con ámbito: el servicio Agente devuelve el token de identidad del agente a Microsoft Entra ID y solicita un nuevo token de acceso con ámbito definido para la audiencia del servicio descendente. La audiencia es el identificador de recurso de OAuth para el servicio de destino (por ejemplo, https://storage.azure.com para Azure Storage).

• Llamada a la herramienta autenticada: Agent Service pasa el token de acceso limitado al servidor MCP o al punto de conexión A2A. El recurso descendente valida el token y comprueba las asignaciones de roles RBAC del agente antes de conceder o denegar el acceso.

En la tabla siguiente se enumeran los valores comunes de audiencia para los servicios globales de Azure:

Términos utilizados en este artículo

Conceptos clave

El marco de la plataforma de ID de agente introduce identidades formales de agente y planos de identidad de agente en Microsoft Entra ID para representar agentes de IA. Puede usar este marco para comunicarse de forma segura con agentes de IA. Este marco también permite a esos agentes de inteligencia artificial comunicarse de forma segura con servicios web, otros agentes de IA y varios sistemas.

Identidad del agente

Una identidad de agente es un principal de servicio especial en Microsoft Entra ID. Es una identidad que el esquema de identidad del agente creó y está autorizada para ser suplantada.

Ventajas de seguridad

Las identidades del agente ayudan a abordar desafíos de seguridad específicos que suponen los agentes de IA:

• Distinga las operaciones que realizan los agentes de IA de las operaciones que realizan las identidades de personal, cliente o carga de trabajo.
• Habilite a los agentes de inteligencia artificial para obtener acceso adecuado en todos los sistemas.
• Impedir que los agentes de inteligencia artificial obtengan access a los roles y sistemas de seguridad críticos.
• Escale la administración de identidades a un gran número de agentes de inteligencia artificial que se pueden crear y destruir rápidamente.

Funcionalidades de autenticación

Las identidades del agente admiten dos escenarios de autenticación clave:

• Asistido (acceso delegado o flujo con derechos delegados): el agente actúa en nombre de un usuario humano mediante el flujo de OAuth 2.0 en su nombre (OBO). El usuario primero se autentica en la aplicación y la aplicación pasa el token del usuario al servicio del agente. A continuación, el servicio de agente intercambia ese token por uno que contiene tanto la identidad del agente como los permisos delegados del usuario. Este enfoque significa que el agente solo puede acceder a los recursos a los que el usuario ha aceptado y está autorizado para.
• Desatendido (flujo solo de aplicación): el agente actúa bajo su propia autoridad mediante el flujo de credenciales de cliente de OAuth 2.0. El servicio Agente autentica el Blueprint en Microsoft Entra ID, obtiene un token para la identidad del agente y solicita un token de acceso con ámbito para el recurso descendente. El acceso del agente se rige por completo por sus propias asignaciones de roles de RBAC, permisos de nivel de aplicación de Microsoft Graph u otras directivas de autorización: no hay ningún usuario humano implicado.

Plano técnico de identidad del agente

Un plano técnico de identidad del agente actúa como plantilla reutilizable que rige desde la que se crean todas las identidades de agente asociadas. Corresponde a un tipo, tipo o clase de agentes. Actúa como el objeto de administración para todas las instancias de identidad del agente de esa clase.

Capacidades del plano

Los planos técnicos de identidad del agente sirven para tres propósitos esenciales:

Clasificación de tipos: el plano técnico establece la categoría del agente, como "Contoso Sales Agent". Esta clasificación permite a los administradores:

• Aplique directivas de acceso condicional a todos los agentes de ese tipo.
• Deshabilite o revoque permisos para todos los agentes de ese tipo.
• Audite y controle los agentes a escala a través de controles coherentes basados en planos técnicos.

Entidad de creación de identidades: los servicios que crean identidades de agente usan el modelo para autenticarse. Los planos técnicos tienen credenciales de OAuth que los servicios usan para solicitar tokens de Microsoft Entra ID para crear, actualizar o eliminar identidades de agente. Estas credenciales incluyen secretos de cliente, certificados o credenciales federadas, como identidades administradas.

Plataforma de autenticación en tiempo de ejecución: el servicio de hospedaje usa la plantilla durante la autenticación en tiempo de ejecución. El servicio solicita un token de acceso mediante las credenciales de OAuth del esquema. A continuación, presenta ese token a Microsoft Entra ID para obtener un token para una de sus identidades de agente.

Metadatos del plano técnico

Por ejemplo, una organización podría usar un agente de IA denominado "Contoso Sales Agent". El plano técnico define información como:

• Nombre del tipo de agente: "Contoso Sales Agent".
• El publicador u organización responsable del plano: "Contoso".
• Los roles que el agente puede realizar: "administrador de ventas" o "representante de ventas".
• Microsoft Graph, permisos o alcances delegados: "leer el calendario del usuario que ha iniciado sesión".

Credenciales de identidad federada

Las credenciales de OAuth de Blueprint determinan cómo el servicio Agente se autentica en Microsoft Entra ID durante el intercambio de tokens en tiempo de ejecución. Los planos técnicos admiten tres tipos de credenciales:

La opción de credencial federada es la más relevante para Foundry. Cuando Foundry aprovisiona un plano técnico de identidad del agente para el proyecto, el plano técnico establece una relación de confianza con la identidad administrada del proyecto. La cadena de autenticación funciona de la siguiente manera:

• El plano técnico de identidad del agente tiene una relación de confianza de credenciales federada con la identidad administrada del proyecto.
• En tiempo de ejecución, el servicio Agente usa la identidad administrada para autenticar el Blueprint en Microsoft Entra ID. No se necesita ningún secreto de cliente ni certificado.
• Entra ID valida la credencial federada y emite un token para la identidad del agente (la entidad de servicio).
• A continuación, se intercambia el token de identidad del agente por un token de acceso con ámbito destinado a la audiencia del recurso descendente.

Esta cadena está diseñada para eliminar los secretos almacenados en la configuración del plano técnico. Azure administra la rotación de credenciales a través de la infraestructura de la identidad administrada, y cada capa — identidad administrada, identidad del agente y recurso descendente — tiene asignaciones de roles independientes y con privilegios mínimos. Sin embargo, algunas configuraciones de herramientas todavía exponen la identidad administrada del proyecto como opción de autenticación.

Integración de Foundry

Foundry se integra automáticamente con Agente de Microsoft Entra ID mediante la creación y administración de identidades a lo largo del ciclo de vida de desarrollo del agente. Al crear el primer agente en un proyecto Foundry, el sistema aprovisiona un plan de identidad de agente predeterminado y una identidad de agente predeterminada para tu proyecto.

Identidad de proyecto compartida

Todos los agentes no publicados o en desarrollo dentro del mismo proyecto comparten una identidad común. Este diseño simplifica la administración de permisos porque los agentes no publicados normalmente requieren los mismos patrones de access y configuraciones de permisos. El enfoque de identidad compartida proporciona estas ventajas:

• Administración simplificada: los administradores pueden administrar de forma centralizada los permisos de todos los agentes de desarrollo dentro de un project.
• Reducción de la proliferación de identidades: el uso de una única identidad por proyecto evita la creación de identidades innecesarias durante las fases iniciales de experimentación.
• Autonomía del desarrollador: después de configurar la identidad compartida, los desarrolladores pueden compilar y probar agentes de forma independiente sin configurar repetidamente nuevos permisos.

Para buscar el plano técnico de identidad del agente compartido y la identidad del agente, vaya a su proyecto de Foundry en Azure Portal. En el panel Información general , seleccione Vista JSON. Elija la versión de API más reciente para ver y copiar las identidades.

Identidad de agente distinta

Cuando los permisos, la auditabilidad o los requisitos del ciclo de vida de un agente difieren de los valores predeterminados del proyecto, debe actualizar a una identidad distinta. Al publicar un agente, se crea automáticamente un plano de identidad del agente dedicado y una identidad de agente. Ambos están enlazados al recurso de aplicación del agente. Esta identidad distinta representa la autoridad del sistema del agente para acceder a sus propios recursos.

Entre los escenarios comunes que requieren identidades distintas se incluyen:

• Agentes listos para pruebas de integración.
• Agentes preparados para uso en producción.
• Agentes que requieren conjuntos de permisos únicos.
• Agentes que necesitan pistas de auditoría independientes.

Para buscar el esquema de identidad del agente y la identidad del agente distintivos, acceda al recurso de aplicación del agente en el portal de Azure. En el panel Información general , seleccione Vista JSON. Elija la versión de API más reciente para ver y copiar las identidades.

Herramientas de automatización e implementación

Las herramientas de implementación como la CLI para desarrolladores de Azure (azd) proporcionan automatización limitada para los permisos de identidad del agente:

• Desarrollo: azd asigna automáticamente el usuario de Foundry a la identidad del agente de proyecto compartido para los agentes no publicados.

  Importante

  Recientemente se cambió el nombre de los roles RBAC de Foundry. Foundry User, Foundry Owner, Foundry Account Owner y Foundry Project Manager se llamaban anteriormente Usuario de Azure AI, Propietario de Azure AI, Propietario de la cuenta de Azure AI y Administrador de proyectos de Azure AI. Es posible que siga viendo los nombres anteriores en algunos lugares mientras se implementa el cambio de nombre. El cambio de nombre no modifica los identificadores de rol y los permisos principales.

• Producción: los agentes publicados reciben identidades distintas que requieren asignaciones de roles manuales

azd no configura Container Registry, Application Insights ni personaliza los permisos de recursos. Para las implementaciones de producción y los requisitos de permisos completos para los agentes hospedados, consulte Referencia de permisos del agente hospedado.

Autenticación de herramientas

Los agentes acceden a recursos y herramientas remotas mediante identidades de agente para la autenticación. El mecanismo de autenticación difiere en función del estado de publicación del agente:

• Agentes no publicados: Autenticar utilizando la identidad del agente del proyecto compartido.
• Agentes publicados: autentíquese mediante la identidad del agente única asociada a la aplicación del agente.

Cuando despliegue un agente, debe reasignar los permisos de RBAC a la identidad del nuevo agente para cualquier recurso al que necesite acceder el agente. Esta reasignación garantiza que el agente publicado mantenga el acceso apropiado mientras opera bajo su identidad distinta.

Asignación de permisos a la identidad del agente

La identidad del agente es una entidad de servicio en Microsoft Entra ID. Asigna los roles de RBAC a esta entidad de la misma manera que asigna roles a cualquier otra entidad de servicio o identidad administrada. Use el agentIdentityId de la vista JSON de la aplicación del proyecto o del agente como asignado.

Por ejemplo, para conceder acceso de lectura y escritura de identidad de agente a una cuenta de almacenamiento, asigne el rol Colaborador de datos de Storage Blob en el ámbito de la cuenta de almacenamiento:

az role assignment create \
    --assignee "<agentIdentityId>" \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>"

Para comprobar la asignación:

az role assignment list \
    --assignee "<agentIdentityId>" \
    --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>" \
    --output table

Asignaciones de roles comunes para las herramientas del agente:

Herramientas compatibles

Actualmente, las herramientas que admiten la autenticación con una identidad de agente son:

• Protocolo de contexto de modelo (MCP): use la identidad del agente para autenticarse con servidores MCP que admiten la autenticación de identidad del agente. Para obtener más información, consulte el Protocolo de Contexto del Modelo y la autenticación del servidor MCP.
• Agente a agente (A2A): habilite la comunicación segura entre agentes mediante identidades de agente. Para obtener más información, consulte La herramienta Agente a agente y la autenticación Agent2Agent (A2A).

Otras herramientas e integraciones pueden usar métodos de autenticación diferentes (por ejemplo, autenticación basada en claves o paso directo de identidad de OAuth). Use la documentación de la herramienta para confirmar la autenticación admitida.

Configuración de conexiones de herramientas

Para conectar un servidor MCP o un punto de conexión A2A con la autenticación de identidad del agente, cree una conexión de proyecto que especifique el tipo de autenticación y la audiencia de destino para el servicio de bajada. El tipo de autenticación depende de la herramienta:

Cuando el agente invoca la herramienta, el servicio Agente usa la identidad del agente para obtener un token de acceso con ámbito al valor de audiencia y, a continuación, pasa ese token al punto de conexión de la herramienta para la autenticación.

Para obtener instrucciones de configuración paso a paso, consulte:

• Configuración de la autenticación del servidor MCP
• Autenticación de Agent2Agent (A2A)

Consideraciones de seguridad

Las identidades del agente ayudan a reducir el riesgo mediante la eliminación de la necesidad de insertar credenciales de larga duración en las configuraciones del agente. Utilice estas prácticas para mantener el acceso de privilegios mínimos y auditables.

• Asigne solo los permisos que necesita el agente para sus acciones de herramienta. Preferir ámbitos estrechos (recurso o grupo de recursos) sobre acceso a toda la suscripción.
• Trate la identidad del proyecto compartido como un alcance más amplio. Si un agente necesita controles más estrictos o auditoría independiente, publíquelo para obtener una identidad distinta y asignar roles a esa nueva identidad.
• Revise y registre el acceso a las herramientas y servidores que no son de Microsoft. Si una llamada a herramienta deja los servicios Microsoft, el control de datos y la retención dependen del proveedor externo.

Limitaciones

• Actualmente, solo algunas herramientas admiten la autenticación de identidad del agente. Consulte la documentación de la herramienta para obtener la autenticación admitida.
• La publicación de un agente cambia la identidad utilizada para realizar llamadas a herramientas (identidad de proyecto compartido frente a identidad de agente distinta). Planee la reasignación de roles al publicar.

Problemas comunes

Estos problemas suelen provocar errores de autenticación de herramientas al usar identidades de agente:

• Roles asignados a la identidad incorrecta: Confirme que ha concedido permisos a la identidad actual utilizada por el agente (proyecto compartido de identidad para agentes no publicados, identidad distinta para agentes publicados).
• Faltan asignaciones de roles: asegúrese de que la identidad del agente tenga el rol RBAC necesario en el recurso de destino. Para ver los roles y ámbitos de Foundry, vea Azure Control de Acceso Basado en Roles en Foundry.
• Audiencia incorrecta: Asegúrese de que la audiencia coincide con el servicio descendente al que llama (por ejemplo, https://storage.azure.com para Azure Storage).

Para obtener una solución de problemas específica de la herramienta, consulte la documentación de la herramienta:

• Protocolo de contexto de modelo
• Herramienta Agente a agente

Administración de identidades de agente

Las identidades del agente se conservan siempre y cuando exista el recurso de aplicación de agente o proyecto de Foundry asociado. Al eliminar un proyecto de Foundry, se eliminan el plano de identidad del agente asociado y la identidad compartida del agente. Los agentes publicados tienen su propio ciclo de vida de identidad asociado al recurso de aplicación del agente; al eliminar la aplicación del agente, se elimina su identidad distinta.

Puede ver y administrar todas las identidades de agente del inquilino a través del Centro de administración Microsoft Entra. Inicie sesión en el centro de administración de Microsoft Entra y vaya a ID de Entra>ID de agente>Todos los agentes para ver un inventario de todos los agentes del tenant, incluidos agentes de Foundry, agentes de Microsoft Copilot Studio y otros.

En esta experiencia, puede habilitar controles de seguridad integrados, entre los que se incluyen:

• Conditional Access: Aplicar políticas de acceso a identidades de agentes.
• Protección de identidades: supervise y proteja las identidades del agente frente a amenazas.
• Network access: Controlar el acceso basado en red para agentes.
• Gobernanza: administre la expiración, los propietarios y los patrocinadores de identidades de agente.

Para obtener más información sobre las características de Agente de Microsoft Entra ID, consulte Microsoft Entra documentación.

Contenido relacionado

• Aplicaciones de Agentes en Microsoft Foundry
• Control de acceso basado en roles de Azure en Foundry
• Autenticación del servidor MCP
• Autenticación de Agent2Agent (A2A)
• Documentación de Agente de Microsoft Entra ID