Accès conditionnel pour les agents

L’accès conditionnel est un moteur de stratégie intelligent qui aide les organisations à contrôler la façon dont les utilisateurs et les agents accèdent aux ressources d’entreprise. Il réunit des signaux en temps réel, tels que le contexte, l’appareil, l’emplacement et les informations de risque de session de l’utilisateur, pour déterminer quand autoriser, bloquer ou limiter l’accès, ou exiger davantage de étapes de vérification.

L’accès conditionnel pour les agents nécessite Microsoft Entra ID P1 ou P2 et une licence Microsoft Agent 365 pour chaque utilisateur. La mise en application des licences Agent 365 arrive bientôt. Les contrôles réseau pour les agents nécessitent Accès Internet Microsoft Entra. Pour plus d’informations, consultez Qu’est-ce que Identifiant d’assistant Microsoft Entra.

En savoir plus sur l’accès conditionnel pour les agents :

• Vue d’ensemble générale de l’accès conditionnel : Qu’est-ce que l’accès conditionnel ?
• Guide de gestion des identités d’agent au sein de votre organisation : gérez les identités d’agent dans votre organisation.
• Guide pratique pour cibler des identités d’agent dans l’accès conditionnel
• Configurer des stratégies pour l’accès aux agents autonomes

Comment l’accès conditionnel évalue les demandes d’accès de l’agent

Pour accéder à une ressource d’entreprise telle que SharePoint fichier, les serveurs MCP ou les services Open API, un utilisateur ou un agent demande d’abord un jeton d’accès à partir de Microsoft Entra ID.

Lorsqu’une stratégie d’accès conditionnel s’applique, Microsoft Entra ID évalue les exigences de stratégie configurées avant d’émettre le jeton. Si les exigences sont satisfaites, un jeton d’accès est émis. Le jeton est ensuite présenté à la ressource cible, qui valide le jeton et utilise ses revendications pour prendre des décisions d’autorisation.

Le diagramme suivant illustre ce processus.

Comment les sujets et les publics sont utilisés

Microsoft Entra ID émet un jeton d’accès à un sujet pour une audience spécifique (ressource). Chaque jeton d’accès a exactement un sujet et une audience.

Objet : identité qui reçoit le jeton.

• Dans les scénarios d’accès délégué, le jeton représente l’utilisateur tout en identifiant l’application ou l’agent appelant.
• Dans les scénarios d’application uniquement, l’application ou l’agent autonome est l’objet.
• Dans les scénarios liés au compte d’utilisateur de l’agent, le compte d’utilisateur de l’agent est le sujet.

Audience : ressource cible pour laquelle le jeton est destiné.

• La ressource doit être inscrite dans Microsoft Entra ID.
• Si un sujet doit accéder à plusieurs ressources (par exemple, plusieurs serveurs ou API MCP), il nécessite généralement un jeton d’accès distinct pour chaque ressource, chacun avec son propre public et ses propres autorisations.

Les stratégies d’accès conditionnel sont évaluées en fonction de l’objet demandant l’accès et de l’audience accessible.

Comment les décisions relatives à l’accès conditionnel sont prises

Les stratégies d’accès conditionnel fonctionnent comme des instructions if-then :

• Si les conditions définies dans une stratégie sont remplies, les contrôles d’accès configurés sont appliqués.
• Si les contrôles requis sont satisfaits, l’accès est accordé.
• Si les contrôles requis ne sont pas satisfaits, l’accès est refusé.

Par exemple, une organisation peut nécessiter une authentification multifacteur avant qu’un utilisateur puisse autoriser un agent à accéder à son e-mail. De même, une organisation peut configurer une stratégie pour bloquer l’accès à partir d’agents identifiés comme présentant un risque élevé.

Quand l’accès conditionnel est évalué

L’accès conditionnel est évalué chaque fois que Microsoft Entra ID émet ou actualise un jeton d’accès. Certaines ressources prennent également en charge l’évaluation continue de l’accès, ce qui peut déclencher une mise en application quasi en temps réel lors de certains événements spécifiques.

Modèles d’accès de l’agent

Les agents peuvent accéder aux ressources protégées par Microsoft Entra à l’aide de l’un des modèles suivants :

Agents agissant pour le compte d’un utilisateur

Le flux OBO (on-behalf-of) est le modèle d’accès le plus courant. Dans ce flux, un utilisateur se connecte à une application agent et accède aux ressources en aval à l’aide de l’identité de l’utilisateur et des autorisations déléguées. Par exemple, lorsqu’un agent lit vos e-mails, il accède à votre boîte aux lettres en votre nom. Pour plus d’informations sur la façon dont fonctionne le flux OBO pour les agents, consultez Flux OAuth pour les agents : On-behalf-of.

Dans ce flux, l’agent ne peut pas réutiliser le jeton d’origine de l’utilisateur, car il a été émis pour un public différent. Au lieu de cela, l’agent utilise le flux OBO pour échanger des jetons avec Microsoft Entra ID afin d’obtenir un nouveau jeton limité à la ressource cible. Cet échange de jetons est également évalué par l’accès conditionnel, ce qui permet aux administrateurs d’appliquer des contrôles granulaires sur les ressources auxquelles les agents peuvent accéder pour le compte de l’utilisateur.

Étant donné que l’utilisateur est l’objet de ce flux, les stratégies d’accès conditionnel ciblent les utilisateurs et les groupes, et non les identités d’agent.

Agents agissant en tant qu’application

Les agents peuvent accéder aux ressources sans utilisateur connecté. Dans ce cas, l’agent accède à la ressource avec sa propre identité. Ce flux est également appelé flux d’informations d’identification du client ou accès à l’application uniquement. Tous les types d’agents peuvent utiliser ce flux. Pour plus d’informations sur la façon dont les agents s’authentifient avec leur propre identité, consultez Les flux OAuth de l’agent : applications autonomes.

Ce flux s’applique dans les scénarios courants suivants :

• Les agents autonomes qui fonctionnent indépendamment s’exécutent en arrière-plan, répondent aux événements ou s’exécutent selon une planification.
  • Par exemple, un agent qui génère un rapport quotidien et envoie le résultat à un groupe d’employés.
  • Dans ce scénario, il n’y a aucun utilisateur présent et l’agent fonctionne seul.
• Les agents interactifs qui utilisent leur propre identité n’accèdent pas toujours aux ressources pour le compte d’un utilisateur ; parfois ils utilisent leur propre identité.
  • Par exemple, si un agent appelle un service SMS principal auquel les utilisateurs n’ont pas accès, le flux OBO ne s’applique pas et l’agent s’authentifie directement comme lui-même.
• Les agents publiés sur le web pour une utilisation publique n’authentifient pas l’utilisateur ou ne prennent pas en charge la délégation du contexte de l’utilisateur aux ressources d’entreprise.

Dans ces scénarios, l’agent demande un jeton d’accès à l’aide de ses propres identités d’agent et d’informations d’identification gérées via le blueprint d’identité de l’agent. Le jeton est émis à l’identité de l’agent (et non à l’utilisateur). Par conséquent, les stratégies d’accès conditionnel sont limitées à l’identité de l’agent plutôt qu’à l’utilisateur. Pour obtenir une configuration de stratégie pas à pas, consultez l’accès conditionnel pour les agents autonomes.

Agents agissant en tant qu’utilisateur

Parfois, il n’est pas suffisant qu’un agent effectue des tâches pour le compte d’un utilisateur ou fonctionne avec sa propre identité. Dans certains scénarios, un agent dispose de son propre compte utilisateur d’agent, qui fonctionne comme un travailleur numérique avec sa propre boîte aux lettres, un accès au chat et la capacité de participer à des flux de travail collaboratifs en tant que membre de l’équipe.

Dans ce modèle, un administrateur crée un compte d’utilisateur dans l’annuaire et le lie à l’identité de l’agent. À partir de là, c’est comme n’importe quel autre compte d’utilisateur. Les licences peuvent être affectées pour accéder à des ressources Microsoft 365 telles qu’une boîte aux lettres et un calendrier. Le compte peut être ajouté aux unités administratives et aux groupes de sécurité comme un compte d’utilisateur humain.

Les agents utilisant ce flux sont également considérés comme des agents autonomes, car ils n’impliquent pas d’interface utilisateur pour l’interaction humaine. Dans ce modèle, le jeton d’accès est émis au compte d’utilisateur de l’agent (objet du jeton) et la stratégie est évaluée par rapport au compte d’utilisateur de l’agent, et non à l’identité de l’agent. Pour obtenir une configuration de stratégie pas à pas, consultez l’accès conditionnel pour les agents autonomes. Pour plus d’informations sur le flux OAuth utilisateur de l’agent, consultez Le flux OAuth utilisateur de l’agent.

Les agents s’exécutant sur des points de terminaison gérés tels que des PC cloud Windows 365 pour les agents peuvent également être soumis à des contrôles de réseau conforme et à la conformité des appareils. Utilisez la condition Environnements d’exécution de l’agent (version préliminaire) pour limiter ces stratégies aux seules sessions basées sur les points de terminaison. Pour plus d’informations, consultez Exiger un appareil conforme pour les comptes d’utilisateur des agents.

Stratégies d’accès conditionnel et blueprints d’identité d’agent

Outre les modèles d’accès d’agent spécifiques, vous pouvez également sélectionner des blueprints d’identité d’agent pour appliquer des stratégies d’accès conditionnel à une classe d’agents. Chaque identité d’agent est dérivée d’un blueprint d’identité d’agent, qui définit sa configuration et son modèle de gouvernance. L’application d’une stratégie au niveau du blueprint couvre automatiquement toutes les identités d’agent dérivées de celle-ci, y compris les nouvelles identités ajoutées à l’avenir. Le fait de cibler le modèle d’identité de l’agent ne couvre pas les comptes utilisateur des agents.

Le diagramme suivant montre que seules les identités d’agent associées au blueprint « A » sont autorisées à accéder ; tous les autres agents sont exclus et bloqués.

Par exemple, imaginez un projet où vous avez plusieurs agents, chacun ayant son propre objectif. Certains fonctionnent indépendamment, tandis que d’autres collaborent avec d’autres agents (A2A) pour effectuer des tâches. S’ils sont tous créés sous le même blueprint, une stratégie unique appliquée à ce blueprint applique des contrôles d’accès cohérents dans l’ensemble de la collection.

Accès conditionnel piloté par les attributs

Au fur et à mesure que le nombre d’identités d’agent augmente, la gestion individuelle de chaque stratégie devient insoutenable. Les attributs de sécurité personnalisés vous permettent de classer les identités et les ressources d’agent avec des étiquettes spécifiques à l’entreprise, puis de cibler ces attributs dans les stratégies d’accès conditionnel. Les stratégies s’appliquent automatiquement à chaque agent avec des attributs correspondants, y compris ceux ajoutés à l’avenir.

Pour obtenir une procédure pas à pas complète sur la création d’attributs de sécurité personnalisés et leur utilisation dans une stratégie d’accès conditionnel, consultez l’accès conditionnel pour les agents autonomes.

Limites de l'accès conditionnel

Les stratégies d’accès conditionnel ne s’appliquent pas quand :

• Un blueprint d'identité d'agent acquiert un jeton pour Microsoft Graph afin de créer un identité d'agent ou un compte utilisateur d'agent.
  • Les blueprints d’agent ont des fonctionnalités limitées. Ils ne peuvent pas agir indépendamment pour accéder aux ressources et sont uniquement impliqués dans la création d’identités d’agent et de comptes d’utilisateur des agents.
  • Les tâches d'agent sont toujours exécutées par l'identité d'agent.
• Un plan d'identité d'agent ou une identité d'agent effectue un échange de jeton intermédiaire au point de terminaison AAD Token Exchange Endpoint: Public (ID de ressource : fb60f99c-7a34-4190-8149-302f77469936).
  • Les jetons limités au AAD Token Exchange Endpoint: Public ne peuvent pas appeler Microsoft Graph.
  • Les flux d'agent sont protégés car l'accès conditionnel protège l'acquisition de jetons depuis l'identité de l'agent ou le compte utilisateur de l'agent.
• Les valeurs par défaut de sécurité sont activées .
• L’accès conditionnel protège uniquement les ressources sécurisées par Microsoft Entra ID. Par exemple, si un agent accède aux ressources à l'aide d'une clé API, il contourne entièrement le pipeline d'authentification et d'émission de jetons Microsoft Entra ID, et les stratégies d'accès conditionnel ne s'appliquent pas à celles-ci.

Les configurations suivantes ne sont actuellement pas prises en charge :

• Les stratégies ciblant tous les utilisateurs n’incluent pas les comptes d’utilisateur de l’agent.
• Étendue d’une stratégie d’accès conditionnel pour inclure ou exclure le compte d’utilisateur de l’agent en fonction de son appartenance au groupe
• Une stratégie d’accès conditionnel ciblant les identités d’agent ne s’applique pas au compte d’utilisateur de l’agent.
• Une stratégie d’accès conditionnel ciblant les identités de l’agent à l’aide du blueprint d’identité de l’agent couvre uniquement l’identité de l’agent, et non le compte d’utilisateur de l’agent.

Étapes suivantes

• Guide pratique pour cibler des identités d’agent dans l’accès conditionnel
• Configurer la stratégie pour l’accès de l’agent autonome