Concepts d’identité de l’agent dans Microsoft Foundry

Une identité agent est un type d'identité spécialisé dans Microsoft Entra ID conçu spécifiquement pour les agents IA. Il fournit un cadre standardisé pour la gouvernance, l’authentification et l’autorisation des agents d’IA dans services Microsoft. Cette infrastructure permet aux agents d’accéder en toute sécurité aux ressources, d’interagir avec les utilisateurs et de communiquer avec d’autres systèmes.

Microsoft Foundry provisionne et gère automatiquement les identités d’agent tout au long du cycle de vie de l’agent. Cette intégration simplifie la gestion des autorisations tout en conservant la sécurité et l’audit à mesure que les agents passent du développement à la production.

Cet article explique comment les identités d’agent se rapportent à des objets Microsoft Entra ID, comment Foundry les utilise lorsqu’un agent appelle des outils et comment appliquer un accès avec des privilèges minimum avec Azure contrôle d’accès en fonction du rôle (RBAC).

Conditions préalables

• Compréhension de l’authentification Microsoft Entra ID et OAuth
• Familiarité avec Azure contrôle d'accès basé sur les rôles (RBAC)
• Connaissance de base des agents IA et de leurs exigences d’exécution

Pour connaître les rôles et les étendues RBAC spécifiques à Foundry, consultez Azure contrôle d’accès en fonction du rôle dans Foundry.

Fonctionnement des identités d’agent dans Foundry

Foundry utilise des identités d’agent Microsoft Entra ID pour prendre en charge deux besoins connexes :

• Gestion et gouvernance : donnez aux administrateurs un moyen cohérent d’inventorier les agents, d’appliquer des stratégies et d’auditer l’activité.
• Tool authentication : laissez un agent s’authentifier auprès des systèmes en aval (par exemple, stockage Azure) sans incorporer de secrets dans des invites, du code ou des chaînes de connexion.

À un niveau élevé, Foundry effectue les opérations suivantes :

1. Mets en service un modèle d’identité d’agent et une ou plusieurs identités d’agent dans Microsoft Entra ID.
2. Affecte des rôles RBAC (ou d’autres modèles d’autorisation, en fonction du système cible) à l’identité de l’agent.
3. Lorsque l’agent appelle un outil, Foundry demande un jeton d’accès pour le service en aval et utilise ce jeton pour authentifier l’appel de l’outil.

Échange de jetons en temps réel

Lorsqu’un agent appelle un outil, un échange de jetonS OAuth 2.0 en plusieurs étapes se produit automatiquement entre le service d’agent, Microsoft Entra ID et la ressource en aval. Les développeurs ne gèrent pas directement les jetons : le service agent gère l’ensemble de l’échange.

L’échange progresse à quatre étapes :

• Authentification Blueprint : Le service d'agent présente les informations d'identification OAuth du Blueprint à Microsoft Entra ID. Cela prouve qu’Agent Service est autorisé à agir pour le compte du blueprint et de ses identités d’agent.

• Émission de jeton d’identité Agent : Microsoft Entra ID valide les informations d’identification du blueprint et émet un jeton pour l'identité d'un agent spécifique. Ce jeton est distinct des jetons d’identité humaine ou d’identité managée : il identifie l’agent comme acteur indépendant dans l’annuaire.

• Demande de jeton délimité: Agent Service présente de nouveau à Microsoft Entra ID le jeton de l’identité d’agent et demande un nouveau jeton d’accès délimité à l'audience du service en aval. L’audience est l’identificateur de ressource OAuth pour le service cible (par exemple, https://storage.azure.com pour stockage Azure).

• Appel d’outil authentifié : Le service agent transmet le jeton d'accès limité au serveur MCP ou au point de terminaison A2A. La ressource en aval valide le jeton et vérifie les attributions de rôle RBAC de l’identité de l’agent avant d’accorder ou de refuser l’accès.

Le tableau suivant répertorie les valeurs d’audience courantes pour les services de Azure globaux :

Termes utilisés dans cet article

Concepts clés

Le cadre de la plateforme d’identification des agents introduit des identités d’agent formelles et des plans d’identités d’agents dans Microsoft Entra ID pour représenter les agents IA. Vous pouvez utiliser cette infrastructure pour communiquer en toute sécurité avec les agents IA. Ce framework permet également à ces agents d’IA de communiquer en toute sécurité avec des services web, d’autres agents IA et différents systèmes.

Identité de l’agent

Une identité d’agent est un principal de service spécial dans Microsoft Entra ID. Il représente une identité que le blueprint d'identité de l'agent a créée et est autorisé à usurper.

Avantages en matière de sécurité

Les identités d’agent aident à résoudre des problèmes de sécurité spécifiques que posent les agents IA :

• Distinguez les opérations effectuées par les agents IA des opérations effectuées par les employés, les clients ou les identités de charge de travail.
• Permettre aux agents d’IA d’obtenir un accès de taille appropriée à travers les systèmes.
• Empêcher les agents IA d’accéder aux rôles et systèmes de sécurité critiques.
• Élargissez la gestion des identités à un grand nombre d’agents IA pouvant être rapidement créés et détruits.

Fonctionnalités d’authentification

Les identités d’agent prennent en charge deux scénarios d’authentification clés :

• Assisté (accès délégué ou flux de délégation OBO) : l’agent fonctionne au nom d’un utilisateur humain, à l’aide du flux OAuth 2.0 on-behalf-of (OBO). L’utilisateur s’authentifie d’abord auprès de l’application et l’application transmet le jeton de l’utilisateur au service agent. Le service d'agent échange ensuite ce jeton contre un autre qui porte à la fois l'identité de l'agent et les autorisations déléguées de l'utilisateur. Cette approche signifie que l’agent peut uniquement accéder aux ressources auxquelles l’utilisateur a consenti et est autorisé.
• Sans assistance (flux d’application uniquement) : l’agent agit sous sa propre autorité, à l’aide du flux d’informations d’identification du client OAuth 2.0. Agent Service authentifie le blueprint auprès de Microsoft Entra ID, obtient un jeton pour l’identité d’agent et demande un jeton d’accès délimité pour la ressource en aval. L'accès de l'agent est entièrement régi par ses propres attributions de rôles RBAC, les autorisations de l'application Microsoft Graph ou d'autres stratégies d'autorisation, aucun utilisateur humain n'est impliqué.

Blueprint d’identité de l’agent

Un plan d’identité d’agent sert de modèle réutilisable et directeur pour la création de toutes les identités d’agent associées. Il correspond à un type, un type ou une classe d’agents. Il agit en tant qu’objet de gestion pour toutes les instances d’identité d’agent de cette classe.

Fonctionnalités de plan

Les blueprints d’identité de l’agent servent trois objectifs essentiels :

Classification de type : le blueprint établit la catégorie d’agent, telle que « Contoso Sales Agent ». Cette classification permet aux administrateurs de :

• Appliquez des stratégies d’accès conditionnel à tous les agents de ce type.
• Désactivez ou révoquez des autorisations pour tous les agents de ce type.
• Auditer et régir des agents à grande échelle via des contrôles cohérents basés sur des blueprints.

Autorité de création d’identité : les services qui créent des identités d’agent utilisent le blueprint pour s’authentifier. Les blueprints ont des informations d’identification OAuth que les services utilisent pour demander des jetons de Microsoft Entra ID pour créer, mettre à jour ou supprimer des identités d’agent. Ces informations d’identification incluent les secrets client, les certificats ou les informations d’identification fédérées comme les identités managées.

Plateforme d’authentification du runtime : le service d’hébergement utilise le blueprint pendant l’authentification du runtime. Le service demande un jeton d’accès à l’aide des informations d’identification OAuth du blueprint. Il présente ensuite ce jeton à Microsoft Entra ID pour obtenir un jeton pour l’une de ses identités d’agent.

Métadonnées de blueprint

Par exemple, une organisation peut utiliser un agent IA appelé « Contoso Sales Agent ». Le blueprint définit des informations telles que :

• Nom du type d’agent : « Contoso Sales Agent ».
• Éditeur ou organisation responsable du blueprint : « Contoso ».
• Rôles que l’agent peut effectuer : « responsable des ventes » ou « commercial ».
• Microsoft Graph autorisations ou étendues déléguées : « lecture du calendrier de l'utilisateur authentifié ».

Informations d'identité fédérée

Les informations d’identification OAuth du blueprint déterminent la manière dont Agent Service s’authentifie auprès de Microsoft Entra ID pendant l'échange de jetons à l'exécution. Les Blueprints prennent en charge trois types d'identifiants :

L’option d’informations d’identification fédérées est la plus pertinente pour Foundry. Lorsque Foundry provisionne un blueprint d’identité d’agent pour votre projet, le blueprint établit une relation d’approbation avec l’identité managée du projet. La chaîne d’authentification fonctionne comme suit :

• Le blueprint d’identité de l’agent a une relation de confiance des informations d’identification fédérées avec l’identité gérée du projet.
• Au moment de l’exécution, le service agent utilise l’identité managée pour authentifier le blueprint sur Microsoft Entra ID. Aucune clé secrète client ou certificat n’est nécessaire.
• Entra ID valide les informations d’identification fédérées et émet un jeton pour l’identité agent (principal du service).
• Le jeton d’identité de l’agent est ensuite échangé pour un jeton d’accès étendu ciblant l’audience de la ressource en aval.

Cette chaîne est conçue pour éliminer les secrets stockés dans la configuration du blueprint. Azure gère la rotation des autorisations par le biais de l'infrastructure de l'identité managée, et chaque couche — l'identité managée, l'identité de l'agent, et la ressource en aval — possède des attributions de rôles indépendantes et à privilèges minimum. Toutefois, certaines configurations d’outils exposent toujours l’identité managée du projet en tant qu’option d’authentification.

Intégration de Foundry

Foundry s’intègre automatiquement à Identifiant d’assistant Microsoft Entra en créant et en gérant des identités tout au long du cycle de vie du développement de l’agent. Lorsque vous créez votre premier agent dans un projet Foundry, le système provisionne un blueprint d’identité d’agent par défaut et une identité d’agent par défaut pour votre projet.

Identité de projet partagée

Tous les agents non publiés ou en développement au sein du même projet partagent une identité commune. Cette conception simplifie la gestion des autorisations, car les agents non publiés nécessitent généralement les mêmes modèles d’accès et configurations d’autorisation. L’approche d’identité partagée offre les avantages suivants :

• Administration simplifiée : les administrateurs peuvent gérer de manière centralisée les autorisations pour tous les agents de développement au sein d’un projet.
• Expansion réduite des identités : l’utilisation d’une identité unique par projet empêche la création d’identité inutile lors de l’expérimentation anticipée.
• Autonomie du développeur : une fois l’identité partagée configurée, les développeurs peuvent générer et tester des agents indépendamment sans configurer de nouvelles autorisations à plusieurs reprises.

Pour rechercher votre blueprint d’identité d’agent partagé et votre identité d’agent, accédez à votre projet Foundry dans le portail Azure. Dans le volet Vue d’ensemble , sélectionnez Affichage JSON. Choisissez la dernière version de l’API pour afficher et copier les identités.

Identité d’agent distincte

Lorsque les autorisations, l’auditabilité ou les exigences de cycle de vie d’un agent diffèrent des valeurs par défaut du projet, vous devez effectuer une mise à niveau vers une identité distincte. La publication d’un agent crée automatiquement un schéma d’identité d'agent dédié et une identité d’agent. Les deux sont liés à la ressource d’application de l’agent. Cette identité distincte représente l’autorité système de l’agent pour accéder à ses propres ressources.

Les scénarios courants qui nécessitent des identités distinctes sont les suivants :

• Agents prêts pour les tests d’intégration.
• Agents préparés pour une utilisation en production.
• Agents qui nécessitent des ensembles d'autorisations uniques.
• Agents qui ont besoin de pistes d’audit indépendantes.

Pour trouver le plan distinctif d'identité d'agent et l'identité de l'agent, rendez-vous sur la ressource d'application de votre agent dans le portail Azure. Dans le volet Vue d’ensemble , sélectionnez Affichage JSON. Choisissez la dernière version de l’API pour afficher et copier les identités.

Outils d’automatisation et de déploiement

Les outils de déploiement tels que l’interface CLI développeur Azure (azd) fournissent une automatisation limitée pour les autorisations d’identité de l’agent :

• Développement : azd affecte automatiquement l’Utilisateur AI Azure à l’identité de l’agent de projet partagé pour les agents qui ne sont pas publiés.
• Production : les agents publiés reçoivent des identités distinctes qui nécessitent des attributions de rôles manuelles

azd ne configure pas Container Registry, Application Insights ou des autorisations de ressources personnalisées. Pour les déploiements de production et les exigences d’autorisation complètes pour les agents hébergés, consultez les informations de référence sur les autorisations de l’agent hébergé.

Authentification de l’outil

Les agents accèdent aux ressources et outils distants à l’aide d’identités d’agent pour l’authentification. Le mécanisme d’authentification diffère en fonction de l’état de publication de l’agent :

• Agents non publiés : authentifiez-vous à l’aide de l’identité de l’agent du projet partagé.
• Agents publiés : authentifiez-vous à l’aide de l’identité d’agent unique associée à l’application de l’agent.

Lorsque vous publiez un agent, vous devez réaffecter les autorisations RBAC à la nouvelle identité de l’agent pour toutes les ressources auxquelles l’agent doit accéder. Cette réaffectation garantit que l’agent publié conserve l’accès approprié tout en fonctionnant sous son identité distincte.

Attribuer des autorisations à l’identité de l’agent

L’identité de l’agent est un service principal dans Microsoft Entra ID. Vous attribuez des rôles RBAC à celui-ci de la même façon que vous attribuez des rôles à tout autre principal de service ou identité managée. Utilisez la agentIdentityId vue JSON de votre projet ou agent en tant que bénéficiaire.

Par exemple, pour accorder à une identité d’agent un accès en lecture/écriture à un compte de stockage, attribuez le rôle Contributeur de données Blob de stockage à l’étendue du compte de stockage :

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

Pour vérifier l’affectation :

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

Attributions de rôles courantes pour les outils d’agent :

Outils pris en charge

Actuellement, les outils qui prennent en charge l’authentification avec une identité d’agent sont les suivants :

• Modèle Context Protocol (MCP) : utilisez l’identité de votre agent pour s’authentifier auprès des serveurs MCP qui prennent en charge l’authentification d’identité de l’agent. Pour plus d’informations, consultez Le protocole de contexte de modèle et l’authentification du serveur MCP.
• Agent à agent (A2A) : activez la communication sécurisée entre les agents à l’aide d’identités d’agent. Pour plus d’informations, consultez l’outil Agent à Agent et l’authentification Agent2Agent (A2A).

D’autres outils et intégrations peuvent utiliser différentes méthodes d’authentification (par exemple, l’authentification basée sur des clés ou la passthrough d’identité OAuth). Utilisez la documentation de l’outil pour confirmer l’authentification prise en charge.

Configurer les connexions d’outils

Pour connecter un serveur MCP ou un point de terminaison A2A avec l’authentification d’identité de l’agent, créez une connexion de projet qui spécifie le type d’authentification et l’audience cible du service en aval. Le type d’authentification dépend de l’outil :

Lorsque l’agent appelle l’outil, Agent Service utilise l’identité de l’agent pour obtenir un jeton d’accès délimité à la valeur d’audience , puis transmet ce jeton au point de terminaison de l’outil pour l’authentification.

Pour obtenir des instructions de configuration pas à pas, consultez :

• Configurer l’authentification du serveur MCP
• Authentification Agent2Agent (A2A)

Considérations relatives à la sécurité

Les identités d’agent vous aident à réduire les risques en supprimant la nécessité d’incorporer des informations d’identification de longue durée dans les configurations de l’agent. Utilisez ces pratiques pour conserver les privilèges minimum d’accès et auditables :

• Attribuez uniquement les autorisations dont l’agent a besoin pour ses actions d’outil. Privilégiez les périmètres restreints (ressource ou groupe de ressources) plutôt qu'un accès à l'ensemble de l'abonnement.
• Traitez l’identité de projet partagée comme un périmètre d’impact plus large. Si un agent a besoin de contrôles plus stricts ou d’audit distincts, publiez-le afin qu’il obtienne une identité distincte et attribuez des rôles à cette nouvelle identité.
• Passez en revue et journaliser l’accès aux outils et serveurs non Microsoft. Si un appel d’outil quitte les services Microsoft, la gestion et la conservation des données dépendent du fournisseur externe.

Limitations

• Seuls certains outils prennent actuellement en charge l’authentification d’identité de l’agent. Consultez la documentation de l’outil pour obtenir l’authentification prise en charge.
• La publication d’un agent modifie l’identité utilisée pour les appels d’outils (identité de projet partagée et identité d’agent distincte). Planifiez la réaffectation de rôle lors de la publication.

Problèmes courants

Ces problèmes provoquent généralement des échecs d’authentification des outils lors de l’utilisation des identités d’agent :

• Rôles affectés à l’identité incorrecte : confirmez que vous avez accordé des autorisations à l’identité actuelle utilisée par l’agent (identité de projet partagée pour les agents non publiés, identité distincte pour les agents publiés).
• Attributions de rôles manquantes : vérifiez que l’identité de l’agent a le rôle RBAC requis sur la ressource cible. Pour les rôles et périmètres de Foundry, consultez le contrôle d'accès basé sur les rôles Azure dans Foundry.
• Audience incorrect : vérifiez que l’audience correspond au service en aval que vous appelez (par exemple, https://storage.azure.com pour stockage Azure).

Pour la résolution des problèmes spécifiques à l’outil, consultez la documentation de l’outil :

• Protocole de contexte de modèle
• Outil Agent à Agent

Gérer les identités d’agent

Les identités d’agent persistent tant que le projet Foundry associé ou la ressource d’application de l’agent existe. Lorsque vous supprimez un projet Foundry, le blueprint d’identité de l’agent associé et l’identité d’agent partagé sont supprimés. Les agents publiés ont leur propre cycle de vie d’identité, lié à la ressource d’application de l’agent, la suppression de l’application de l’agent supprime son identité distincte.

Vous pouvez afficher et gérer toutes les identités d’agent dans votre locataire via le centre d’administration Microsoft Entra. Connectez-vous au centre d’administration Microsoft Entra et accédez à Entra ID>Agent ID>Toutes les identités d’agents pour afficher un inventaire de tous les agents de votre locataire, y compris les agents Foundry, les agents Microsoft Copilot Studio, et d'autres.

Dans cette expérience, vous pouvez activer des contrôles de sécurité intégrés, notamment :

• Accès conditionnel : appliquez des stratégies d’accès aux identités d’agent.
• Protection des identités : surveillez et protégez les identités des agents contre les menaces.
• Accès réseau : contrôler l’accès en fonction du réseau pour les agents.
• Gouvernance : gérer l’expiration, les propriétaires et les sponsors pour les identités d’agent.

Pour plus d’informations sur les fonctionnalités Identifiant d’assistant Microsoft Entra, consultez Microsoft Entra documentation.

Contenu connexe

• applications d'agent dans Microsoft Foundry
• Azure contrôle d'accès basé sur les rôles dans Foundry
• Authentification du serveur MCP
• Authentification Agent2Agent (A2A)
• Documentation de Identifiant d’assistant Microsoft Entra