Identité de l’agent 365

L’Agent 365 utilise Identifiant d’assistant Microsoft Entra pour représenter chaque agent avec une identité d’agent distincte. Une identité d’agent est un principal de service Microsoft Entra avec servicePrincipalType les valeurs fixées à ServiceIdentity et @odata.type sur #microsoft.graph.agentIdentity. Les administrateurs gèrent les identités des agents avec les mêmes contrôles de locataire utilisés ailleurs dans Microsoft Entra, y compris l’accès conditionnel, les autorisations et consentements, ainsi que les opérations du cycle de vie.

Objets identité

Trois objets composent le modèle. Tous les agents n’utilisent pas les trois.

Object Description
Blueprint d’identité de l’agent Un modèle dans Microsoft Entra ID qui définit un type d’agent. Il détient les identifiants, les autorisations déclarées et héritables, l’éditeur vérifié, ainsi que tous les rôles d’application. Un seul plan peut créer de nombreuses identités d’agents. Pour plus de contexte sur la manière dont les applications sont enregistrées dans Microsoft Entra, voir Enregistrer une application auprès de la Plateforme d'identités Microsoft.
Identité de l’agent Le compte qu’un agent individuel utilise en tant que personne. Il possède son propre identifiant d’objet, son nom d’affichage, son sponsor et ses attributions de permission.
Compte d’utilisateur de l’agent Un second compte optionnel, créé uniquement lorsque l’agent a besoin d’un compte utilisateur Microsoft Entra. Il peut détenir des licences et des ressources Microsoft 365 telles qu’une boîte aux lettres. Disponible uniquement pour les locataires participant au programme de prévisualisation Frontier. L’identité d’un agent n’a aucun ou un compte utilisateur d’agent, et chaque compte utilisateur appartient à exactement une seule identité d’agent.

Relation plan-agent

Au sein d’un locataire, une inscription standard de demande a généralement une relation individuelle avec son principal de service. Le modèle d’agent est un à plusieurs : un seul plan peut être associé à plusieurs identités d’agent au sein d’un locataire.

Chaque identité d’agent hérite des propriétés du protocole du blueprint et peut détenir ses propres permissions en aval. Parce que des agents du même type partagent un blueprint, un administrateur peut appliquer une politique d’accès conditionnel, révoquer une autorisation ou désactiver tous les agents de ce type en une seule opération.

Les identités d’agent sont monolocataires et ne peuvent recevoir que des jetons dans le locataire où elles sont créées. Les plans peuvent être multilocataires. C’est ainsi qu’un agent publié est ajouté à un locataire client, qui crée ensuite ses propres identités locataire-agent local à partir du blueprint.

Credentials

Un agent s’authentifie en utilisant sa propre identité d’agent, mais l’identité elle-même ne stocke pas les identifiants. Vous configurez les identifiants sur le blueprint, et le blueprint les utilise pour acquérir des jetons pour les identités des agents créées à partir de ce blueprint.

Types de créances pris en charge sur le plan :

  • Identifiants d’identité fédérée
  • Certificats et clés cryptographiques
  • Clés secrètes client

Pour les agents fonctionnant sur Azure, vous pouvez fédérer le blueprint vers une identité gérée Azure afin qu’aucun secret ne soit stocké sur le blueprint.

Les identifiants de blueprint sont partagés par chaque identité d’agent créée à partir de ce blueprint. Traitez chaque plan comme une frontière entre identifiants, et regroupez uniquement les identités qui peuvent partager en toute sécurité des identifiants et des permissions de base héritées.

Les identités des agents ne s’authentifient pas avec des mots de passe, des SMS, des clés d’accès ou des applications d’authentification, donc l’authentification multifacteur ne s’applique pas à eux. Gouvernez-les plutôt avec des politiques d’accès conditionnel.

Compte d’utilisateur de l’agent

Certains agents doivent accéder à des systèmes nécessitant un compte utilisateur Microsoft Entra. Dans ces cas, vous pouvez donner un second compte à l’agent et le marquer dans le répertoire comme agent IA.

En utilisant un compte utilisateur et les licences appropriées, un agent peut disposer d’une boîte aux lettres et d’un stockage OneDrive, apparaître dans les métadonnées du répertoire et de l’organisation, et être atteint via Teams, Outlook, commentaires Word et par email.

Ajoutez un compte utilisateur uniquement lorsque l’agent en a besoin. Les agents qui n’émettent que des outils de télémétrie et d’appel n’en ont généralement pas besoin.

Important

Les agents disposant de leur propre compte utilisateur ne sont disponibles que pour les locataires participant au programme de prévisualisation Frontier.

Permissions et flux d’exécution

Un agent peut fonctionner en trois modes d’exécution. Le mode détermine pour qui l’agent agisse, quel sujet de jeton apparaît dans l’appel en aval, et quelles permissions et consentement sont requis :

Mode d’exécution Description
S2S (service à service) L’agent s’exécute sans contexte utilisateur et agit comme une identité d’agent à part entière. Utilisez ce mode pour les tâches planifiées, la surveillance et le traitement en arrière-plan. Il utilise les permissions de l’application et l’identité de l’agent est le sujet du jeton. Pour le patron OAuth sous-jacent, voir OAuth 2.0 Customer Credentials Grant.
OBO (au nom de) L’agent reçoit le contexte d’un utilisateur humain connecté et agit pour cet utilisateur. Utilisez ce mode lorsque l’accès dépend de l’identité de l’utilisateur ou des permissions. Il utilise des autorisations déléguées ; L’utilisateur est le sujet du jeton et l’identité de l’agent est l’acteur. Pour les détails de l’implémentation, voir OAuth 2.0 On-Behalf-Of flow.
Agent utilisateur L’agent fonctionne avec son propre compte utilisateur Microsoft Entra et agit comme ce compte. Ce mode nécessite le programme de prévisualisation Frontier et est utilisé lorsque l’agent a besoin de ressources utilisateur ou d’expériences Microsoft 365 basées sur l’utilisateur, comme une boîte aux lettres, la présence Teams ou des interactions Word et Outlook. Le compte utilisateur de l’agent est l’utilisateur en agant, tandis que l’identité de l’agent reste l’identité enregistrée de l’Agent 365.

Par exemple, le traitement en arrière-plan nocturne utilise généralement S2S ; une action spécifique à l’utilisateur dans le chat utilise OBO ; et lire la boîte aux lettres d’un agent utilise Agentic-User. Le modèle de permissions et le mode d’exécution sont liés, mais ce ne sont pas des termes interchangeables : choisissez d’abord le mode, puis confirmez l’application ou les autorisations et le consentement délégués requis par la ressource en aval.

Avant de mettre en place un mode, confirmez que votre configuration complète supporte le fonctionnement :

  1. Identifiez en tant qu’agent qui doit agir pour l’opération : son identité d’agent, un utilisateur connecté ou son propre compte utilisateur.
  2. Confirmez que le mode sélectionné prend en charge ce contexte de compte et le type d’autorisation requis par l’API ou la ressource cible.
  3. Accordez les portées et consentez nécessaires, puis satisfez à toutes les conditions supplémentaires, telles que des licences ou une ressource utilisateur provisionnée.

Si une exigence n’est pas prise en charge par le mode sélectionné, choisissez un mode ou une opération différente. Pour les champs de contrôle Microsoft Graph, voir la référence des permissions Microsoft Graph.

Une fois que vous savez quelles permissions l’agent doit obtenir, décidez où les attribuer. Déclarez des permissions de base partagées sur le blueprint afin que chaque identité d’agent créée à partir de celui-ci les hérite, et attribuez directement des permissions à un identité d’agent lorsque l’accès est spécifique à cet agent. Le contrôle d'accès basé sur les rôles (RBAC) d'Azure est une exception : les blueprints ne peuvent pas contenir les rôles Azure RBAC, donc attribuez ces rôles directement à chaque identité d'agent. Les identités d’agent peuvent également occuper des rôles intégrés à Microsoft Entra.

Important

Déclarer des permissions sur un plan ne les accorde pas. Un administrateur doit consentir, soit sur le principe du plan, soit sur l’identité individuelle des agents.

Chaque identité d’agent et plan d’identité d’agent nécessite au moins un sponsor : le représentant commercial responsable de la finalité et du cycle de vie de l’agent. Les sponsors pourraient être invités à décider si un agent doit être conservé ou désactivé, et les équipes de sécurité pourraient utiliser le sponsor pour contacter un humain responsable lors d’un incident.

Les journaux de connexion et d’audit différencient le blueprint, l’identité de l’agent et le compte utilisateur de l’agent. Un évaluateur peut identifier la source de la qualification, l’identité d’acteur et le sujet du jeton. Dans les opérations S2S, l’identité de l’agent est le sujet du jeton. Dans les opérations OBO, l’utilisateur connecté est le sujet et l’identité de l’agent est l’acteur.

Ce que vous configurez

Lorsque vous intégrez un agent dans Agent 365, vous enregistrez un blueprint d’identité d’agent dans Microsoft Entra, et créez des identités d’agent à partir de celui-ci. La make-a365-agent compétence effectue les deux étapes suivant le parcours standard de l’agent. Sur le chemin des coéquipiers IA, il make-ai-teammate les exécute. Voir Quickstart : Connecter un agent existant à l’Agent 365.

Décidez des points suivants avant de commencer :

Élément Description
Combien de plans Utilisez un plan par limite de titres. Utilisez des plans séparés pour les agents qui ne peuvent pas partager en toute sécurité des identifiants et des permissions de base héritées.
Quel modèle d’autorisation Autorisations d’application, autorisations déléguées, ou les deux.
Si l’agent a besoin d’un compte utilisateur Seulement si cela nécessite une boîte aux lettres, une présence Teams ou un profil dans l’annuaire organisationnel.
Qui sont les sponsors Chaque plan et chaque identité d’agent nécessitent au moins un sponsor, qui peut être un utilisateur ou un groupe.

Contenu connexe

  • Last updated on