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 inteligencia artificial. Proporciona un marco estandarizado para gobernar, autenticar y autorizar agentes de inteligencia artificial en servicios Microsoft. Este marco permite a los agentes acceder de forma segura a los recursos, 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 Entra ID de Microsoft, cómo Foundry los utiliza cuando un agente invoca herramientas y cómo aplicar el acceso de mínimo privilegio con el control de acceso basado en rol de Azure (RBAC).

Requisitos previos

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

Funcionamiento de las identidades de agente en Foundry

Foundry utiliza identidades de agente de Microsoft Entra ID para cumplir con 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 herramienta Tool: permitir que un agente se autentique en sistemas descendentes (por ejemplo, Azure Storage) sin insertar secretos en indicaciones, código o cadenas de conexión.

En un nivel alto, Foundry hace lo siguiente:

  1. Aprovisiona una plantilla de identidad de agente y una o varias 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 de bajada 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, un intercambio de tokens de OAuth 2.0 de varios pasos automáticamente se produce entre el servicio del 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 Blueprint: El servicio del agente presenta las credenciales OAuth del Blueprint a Microsoft Entra ID. Esto demuestra que Agent Service está autorizado para actuar en nombre del plano maestro y sus identidades de agente.

  • 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 alcance: El servicio del agente devuelve el token de identidad del agente a Microsoft Entra ID y solicita un nuevo token de acceso con un alcance definido al público del servicio de bajada. 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: el servicio de agente pasa el token de acceso con ámbito al servidor MCP o al punto de conexión A2A. El recurso descendente valida el token y comprueba las asignaciones de roles de RBAC de la identidad 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:

Servicio descendente Valor de audiencia
Azure Storage https://storage.azure.com
Azure Logic Apps https://logic.azure.com
Azure Cosmos DB https://cosmos.azure.com
Microsoft Graph https://graph.microsoft.com
Azure Key Vault https://vault.azure.net

Importante

Un valor de audiencia incorrecto provoca errores de autenticación incluso cuando se asignan correctamente los roles de RBAC. La audiencia debe coincidir con el identificador de recurso del servicio descendente, no la dirección URL del propio servidor MCP.

Términos usados en este artículo

Término Qué significa en el contexto de Foundry
Identidad del agente Un principal de servicio de Microsoft Entra ID que representa al agente durante su ejecución.
Plano técnico de identidad del agente Objeto de Microsoft Entra ID que rige una categoría de identidades de agente y se utiliza para operaciones de ciclo de vida.
agentIdentityId Identificador que se usa al asignar permisos a la identidad del agente.
Audiencia El identificador de recurso del servicio descendente al cual está destinado el token (por ejemplo, https://storage.azure.com).

Conceptos clave

El marco de la plataforma de identificación de agente presenta identificaciones de agentes formales y modelos 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.

Nota

El marco Agente de Microsoft Entra ID está actualmente en versión preliminar. Las características y las API pueden cambiar antes de la disponibilidad general.

Identidad del agente

Una identidad de agente es una entidad de servicio especial en Microsoft Entra ID. Representa una identidad que el plano de identidad del agente creó y que está autorizado a suplantar.

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.
  • Permitir a los agentes de inteligencia artificial obtener acceso adecuado en todos los sistemas.
  • Impedir que los agentes de inteligencia artificial obtengan acceso 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:

  • Atendido (acceso delegado o flujo de representación): el agente opera en nombre de un usuario humano mediante el flujo de representación de OAuth 2.0 (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 de solo aplicación): el agente actúa bajo su propia autoridad mediante el flujo de credenciales de cliente de OAuth 2.0. El servicio de agente autentica la hoja de ruta en Microsoft Entra ID, obtiene un token para la identidad del agente y solicita un token de acceso con ámbito para el recurso aguas abajo. 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: ningún usuario humano está involucrado.

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 plan maestro

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.

Autoridad de creación de identidades: los servicios que crean identidades de agente usan el plano 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 durante el 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 plano técnico. 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: "Agente de Ventas de Contoso".
  • El editor u organización responsable del plan maestro: "Contoso".
  • Los roles que el agente puede realizar: "administrador de ventas" o "representante de ventas".
  • Microsoft Graph permisos o ámbitos delegados: "leer el calendario del usuario que ha iniciado sesión".

Credenciales de identidad federada

Las credenciales de OAuth del esquema determinan cómo Agent Service 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:

Tipo de credencial Cómo funciona Compromisos
Secreto de cliente Cadena secreta compartida almacenada en el registro de Entra ID del plano técnico. Es más sencillo configurar, pero requiere rotación manual y almacenamiento seguro.
Certificado Certificado X.509 usado para la autenticación basada en aserciones. Es más seguro que los secretos de cliente, pero requiere la administración del ciclo de vida de los certificados.
Credencial federada (identidad administrada) Relación de confianza entre un plan y una identidad administrada o un principal de servicio. No se almacena ningún secreto en el plano. Recomendado para entornos de producción. Azure administra automáticamente la rotación 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.
  • Durante el tiempo de ejecución, Agent Service utiliza la identidad administrada para autenticar la plantilla 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 de agente (el principal del servicio).
  • A continuación, se intercambia el token de identidad del agente para un token de acceso con ámbito destinado a la audiencia del recurso de nivel inferior.

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 de nivel inferior) 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.

Nota

La identidad administrada autentica el blueprint en Entra ID. No accede directamente al recurso descendente. La identidad del agente, no la identidad administrada, es la principal que requiere asignaciones de roles de RBAC en el recurso de destino.

Integración de fundición

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 plano técnico de identidad de agente predeterminado y una identidad de agente predeterminada para el proyecto.

Identidad del proyecto compartido

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 acceso 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 proyecto.
  • Reducción de la expansión de identidades: el uso de una sola identidad por proyecto evita la creación de identidades innecesaria durante la experimentación temprana.
  • 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 encontrar su plano de identidad del agente compartido y la identidad del agente, vaya a su proyecto Foundry 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.

Captura de pantalla de la vista JSON en el portal de Azure que muestra un plano técnico de identidad del agente y los detalles de identidad del agente para un proyecto Foundry.

Identidad de agente distinta

Cuando los permisos, la auditabilidad o los requisitos de 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 modelo de identidad de 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 el consumo en producción.
  • Agentes que requieren conjuntos de permisos únicos.
  • Agentes que necesitan pistas de auditoría independientes.

Para encontrar el esquema distinto de la identidad del agente y la identidad del agente, diríjase 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 de Azure Developer (azd) proporcionan automatización limitada para los permisos de identidad del agente:

  • Development: azd asigna automáticamente el usuario de Azure AI a la identidad del agente de proyecto compartido para agentes no publicados.
  • Producción: los agentes publicados reciben identidades distintas que requieren asignaciones de roles manuales

azd no configura el Registro de Contenedores, Application Insights ni los permisos de recursos personalizados. 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 remotos 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: autentíquese mediante la identidad del agente del proyecto compartido.
  • Agentes publicados: autentíquese mediante la identidad del agente única asociada a la aplicación del agente.

Al publicar un agente, debe reasignar los permisos de RBAC a la nueva identidad del agente para los recursos a los que el agente necesita acceder. Esta reasignación garantiza que el agente publicado mantenga el acceso adecuado 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. Asignas roles de RBAC a esta entidad de la misma manera en que asignas roles a cualquier otra entidad de servicio o identidad administrada. Use la vista JSON de la aplicación de tu proyecto o agente como el asignado.

Por ejemplo, para otorgar acceso de lectura/escritura a una identidad de agente en una cuenta de almacenamiento, asigne el rol Storage Blob Data Contributor 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:

Escenario de la herramienta Rol necesario Ámbito de destino
Servidor MCP que lee y escribe blobs Colaborador de datos de Storage Blob Cuenta de almacenamiento
Servidor MCP que desencadena aplicaciones lógicas Operador estándar de Logic Apps (versión preliminar) Recurso de Logic App
Herramienta A2A que consulta Cosmos DB Lector de datos integrado de Cosmos DB Cuenta de Cosmos DB

Importante

Al publicar un agente, recibe un nuevo identificador distintivo agentIdentityId. Repita estas asignaciones de roles para la nueva identidad. Los roles de identidad del proyecto compartido no se transfieren a la identidad del agente publicado.

Propina

Para obtener detalles completos sobre todos los permisos implicados en la implementación del agente hospedado, incluidas Azure Container Registry, Application Insights y configuraciones de RBAC de varios recursos, consulte Referencia de permisos del agente hospedado.

Herramientas compatibles

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

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:

Tipo de herramienta Valor de tipo de autenticación Categoría de conexión
Servidor MCP AgenticIdentityToken RemoteTool
Punto de conexión de A2A AgenticIdentity RemoteA2A

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

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

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. Use estas prácticas para mantener el acceso con privilegios mínimos y auditables:

  • Asigne solo los permisos que necesita el agente para sus acciones de herramienta. Se prefieren ámbitos estrechos (recurso o grupo de recursos) sobre el acceso global a la suscripción.
  • Trate la identidad del proyecto compartido como un radio de explosión 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 de Microsoft, el control y la retención de datos 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 que se usa para las llamadas a herramientas (identidad de proyecto compartida frente a identidad de agente distinta). Planee la reasignación de roles al momento de 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 usada por el agente (identidad de proyecto compartida para agentes no publicados, identidad distinta para agentes publicados).
  • Faltan asignaciones de roles: asegúrese de que la identidad del agente tiene el rol RBAC necesario en el recurso de destino. Para ver los roles y las definiciones de Foundry, consulte control de acceso basado en roles de Azure en Foundry.
  • Audiencia incorrecta : asegúrese de que la audiencia coincida con el servicio descendente al que está llamando (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:

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 quitan el plano de identidad del agente asociado y la identidad de agente compartida. Los agentes publicados tienen su propio ciclo de vida de identidad asociado al recurso de la aplicación del agente; al eliminar la aplicación del agente, se quita su identidad distintiva.

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 Microsoft Entra y vaya a Entra ID>Agent ID>Todas las identidades de agentes para ver un inventario de todos los agentes del inquilino, incluidos agentes de Foundry, agentes de Microsoft Copilot Studio, y otros.

Captura de pantalla del centro de administración de Microsoft Entra que muestra la pestaña de identidades de agente con un inventario de todos los agentes del arrendatario.

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

  • Acceso condicional: aplique directivas de acceso a identidades de agente.
  • Protección de identidades: supervise y proteja las identidades del agente frente a amenazas.
  • Acceso a la red: controle el acceso basado en red para los agentes.
  • Gobernanza: gestione la expiración de las identidades de agente, así como sus propietarios y patrocinadores.

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