Concevoir une solution pour les identités d’agent à l’aide de l’ID d’agent Microsoft Entra

À mesure que les organisations adoptent des agents d’INTELLIGENCE artificielle ( systèmes logiciels qui perçoivent leur environnement, prennent des décisions et prennent des mesures), une nouvelle catégorie d’identité émerge qui ne s’adapte pas parfaitement aux modèles d’identité humains ou de charge de travail existants. En tant qu’architecte de sécurité, vous devez concevoir une stratégie d’identité qui tient compte de ce nouveau type d’identité et des défis de sécurité, de gouvernance et de conformité uniques qu’il introduit.

Microsoft Entra ID de l’agent étend les fonctionnalités de sécurité de Microsoft Entra aux agents IA, ce qui permet aux organisations de découvrir, de régir et de protéger les identités d’agent à l’aide du même framework de Zero Trust appliqué aux utilisateurs humains et aux identités de charge de travail.

Pourquoi les identités d’agent nécessitent une conception dédiée

Les modèles d’identité traditionnels traitent les utilisateurs humains (authentification interactive, planifications prévisibles) et les identités de charge de travail (authentification programmatique, comportement statique). Les agents IA ne correspondent pas à l’une ou l’autre catégorie. Comme les utilisateurs, certains agents ont besoin d’accéder aux ressources collaboratives : documents, canaux d’équipe et boîtes aux lettres. Comme les identités de charge de travail, les agents s’authentifient de manière programmatique à la vitesse de la machine. Contrairement aux deux, les agents prennent des décisions autonomes, s'adaptent dynamiquement, interagissent avec d'autres agents et font face à des vecteurs d'attaque spécifiques à l'IA, tels que l'injection de commande.

Le traitement des agents comme des identités de charge de travail laisse des lacunes de gouvernance (aucune responsabilité de sponsor, aucune gestion du cycle de vie), tout en les traitant comme des utilisateurs humains crée des frictions d’authentification et des signaux de sécurité mal alignés. Microsoft Entra Agent ID résout cet écart en établissant les identités d'agent comme un type d'identité distinct et de première classe.

Types d’agents IA

Votre solution d’identité d’agent doit prendre en compte trois types d’agents, chacun ayant des implications de sécurité distinctes :

Les agents d’assistance effectuent des tâches spécifiques lorsqu’ils sont lancés par un utilisateur, qui fonctionnent dans les autorisations déléguées de l’utilisateur demandeur. Les risques de sécurité se concentrent sur la garantie que l’agent ne dépasse pas son étendue déléguée.

Les agents autonomes fonctionnent indépendamment avec leurs propres identités, prenant des décisions sans intervention humaine. Ceux-ci présentent le risque intrinsèque le plus élevé : un agent autonome compromis peut fonctionner à la vitesse de la machine sans surveillance.

Les utilisateurs de l’agent fonctionnent avec des caractéristiques utilisateur humaines : identités persistantes, accès aux boîtes aux lettres, appartenance à l’équipe et participation à la réunion. Un utilisateur d’agent compromis peut agir en tant que membre d’équipe approuvé, accéder aux documents et envoyer des communications sous la légitimité supposée.

Architecture d’identité de l’agent

Microsoft Entra Agent ID introduit des structures d'identité développées pour un objectif spécifique qui forment une hiérarchie conçue pour la gestion à grande échelle.

Cette hiérarchie est architecturalement significative : les stratégies appliquées à un blueprint se cascadent automatiquement sur toutes les identités d’agent enfant, ce qui permet la gestion des familles d’agents associées par le biais d’une attribution de stratégie unique. La plateforme utilise les normes OAuth 2.0 et OpenID Connect (OIDC), de sorte que la validation de jeton, le consentement et l’infrastructure d’autorisation existantes s’appliquent.

Problèmes de sécurité de l’agent qui favorisent les décisions de conception

Lors de la conception d’une solution d’identité d’agent, votre architecture doit atténuer plusieurs catégories de risques qui différencient les agents d’autres types d’identité.

Surface d’attaque accrue

Les agents IA étendent la surface d’attaque organisationnelle de manière à exiger des réponses de conception spécifiques :

• Accessibilité externe : les agents qui interagissent avec des systèmes externes ou l’Internet public créent des voies permettant aux adversaires de compromettre les agents et de pivoter en ressources organisationnelles.
• Risque d’escalade des autorisations : les agents sont fréquemment approvisionnés avec des autorisations plus larges que nécessaires, en violation des privilèges minimum.
• Prise de décision autonome : les agents compromis disposant d’une autorité d’achat ou de privilèges administratifs peuvent prendre des mesures dangereuses à la vitesse de la machine.
• Injection de prompt : des instructions malveillantes insérées dans des données traitées par l’agent peuvent manipuler le comportement de l’agent, un vecteur d’attaque exclusif à l’IA.
• Propagation de l’agent à agent : un agent d’orchestration compromis peut cibler d’autres agents via des flux A2A, en propageant la compromission entre les écosystèmes d’agents.

Prolifération d'agents

La prolifération de l’agent crée un défi de gouvernance appelé « expansion de l’agent » : l’expansion incontrôlée des agents au sein d’une organisation sans visibilité, gestion ou contrôles de cycle de vie adéquats. La prolifération des agents apparaît lorsque les unités commerciales créent des agents indépendamment (IA fantôme), les agents créés à des fins temporaires restent en production indéfiniment, les autorisations s’accumulent sans révision, et la responsabilité de la gestion de ces agents est perdue. Les conséquences incluent la posture de sécurité dégradée, le risque de conformité, l’inefficacité opérationnelle, l’exposition aux données et la réponse aux incidents altérés.

Votre conception de l'identité des agents doit traiter de manière proactive la dispersion en exigeant que chaque agent dispose d'une identité enregistrée, d'un sponsor assigné et d'un cycle de vie gouverné.

Concevoir une stratégie de gouvernance des identités d’agent

Microsoft Entra ID Governance s’étend aux identités d’agent, ce qui vous permet d’appliquer les mêmes contrôles de cycle de vie et de gestion des accès utilisés pour les identités humaines. Votre conception de gouvernance doit aborder trois domaines : la gestion du cycle de vie, l’attribution d’accès et la responsabilité du sponsor.

Gestion du cycle de vie

Les identités d’agent commencent avec des permissions limitées — uniquement les étendues déléguées OAuth 2.0 héritées du blueprint parent. Un accès supplémentaire doit être explicitement demandé, approuvé et affecté par le biais de processus régis.

Attribution d’accès via la gestion des droits d’utilisation

Les packages d'accès de gestion des droits attribuent aux identités d'agent l'accès aux appartenances aux groupes de sécurité, aux autorisations d'application OAuth API (y compris les autorisations d'application Microsoft Graph) et aux rôles Microsoft Entra. L’accès peut être demandé par l’identité de l’agent elle-même (par programme), le sponsor de l’agent ou un administrateur.

Les packages d’accès prennent en charge les stratégies d’expiration, ce qui garantit que l’accès à l’agent est limité dans le temps. À l'approche de l'expiration, les commanditaires reçoivent des notifications et doivent soit demander une extension (déclenchant un nouveau cycle d'approbation), soit laisser l'accès expirer.

Responsabilité du sponsor

Chaque identité d’agent doit avoir un sponsor humain désigné responsable de son cycle de vie et de ses décisions d’accès. Si un sponsor quitte l’organisation, le parrainage transfère automatiquement à son responsable. Les flux de travail de cycle de vie informent les cosponsors et les responsables de changements de parrainage imminents, en maintenant une chaîne ininterrompue de supervision humaine.

Conception pour la protection des identités d’agent

Microsoft Entra ID Protection étend la détection des risques et la réponse aux identités de l’agent. Étant donné que les agents peuvent fonctionner de manière autonome et à grande échelle, un comportement anormal nécessite une détection et une réponse automatisées plutôt que de s’appuyer sur une révision manuelle.

La protection d’ID pour les agents établit une base de référence comportementale pour chaque agent, puis surveille les écarts. Les activités qui contribuent à ce qu'un agent soit considéré comme à risque sont les suivantes :

Ces signaux de risque alimentent l’accès conditionnel pour les agents (couverts dans l’unité suivante), ce qui permet aux stratégies basées sur les risques qui empêchent automatiquement les agents à haut risque d’accéder aux ressources. Votre conception doit combiner la détection des risques de l’agent avec l’application de l’accès conditionnel comme défense en couches.

Concevoir des contrôles au niveau du réseau pour les agents

Microsoft Entra Accès sécurisé global étend les contrôles de sécurité réseau au trafic agent. Pour les agents basés sur des plateformes telles que Microsoft Copilot Studio, vous pouvez transférer le trafic de l'agent vers le service proxy Global Secure Access, en appliquant les mêmes stratégies réseau que celles utilisées pour les utilisateurs. Les fonctionnalités incluent la journalisation de l'activité réseau de l’agent, l'application de la catégorisation web pour contrôler l'accès aux API et au serveur MCP, la restriction des transferts de fichiers par type, le blocage des destinations malveillantes grâce au renseignement sur les menaces et la détection des attaques par injection de commandes.

Les contrôles réseau complètent les protections de couche d’identité : l’accès conditionnel régit l’acquisition de jetons, tandis que les contrôles réseau régissent les chemins de trafic et le contenu une fois autorisés, fournissant une défense en profondeur.

Registre et découverte de l’agent logiciel

Le Registre d’agents dans le centre d’administration Microsoft Entra offre une visibilité centralisée sur toutes les identités de l’agent, leurs métadonnées (objectif, fonctionnalités, protocoles), propriétaires et commanditaires. Prend en charge la découverte et l’autorisation agent à agent basée sur des protocoles standards comme MCP (protocole de contexte de modèle) et A2A (Agent à agent). Le registre est votre principal mécanisme pour lutter contre la prolifération des agents, dont l'enregistrement est nécessaire pour assurer une visibilité organisationnelle et garantir que chaque agent peut être inventorié, audité et sous gouvernance.

Intégration sur plusieurs plateformes Microsoft

Microsoft Entra ID d’agent s’intègre à plusieurs plateformes qui créent et gèrent des agents, fournissant une gestion cohérente des identités, quel que soit l’emplacement d’origine des agents :

• Microsoft Foundry provisionne automatiquement des blueprints et des identités d’agent tout au long du cycle de vie de l’agent.
• Microsoft Copilot Studio agents peuvent recevoir automatiquement des identités d’agent lorsqu’ils sont activés dans un environnement Power Platform.
• Azure App Service et Azure Functions pouvez utiliser la plateforme d’identité de l’agent pour se connecter aux ressources en tant qu’agents.
• Les blueprints d'identité d'agent de Microsoft Teams peuvent être gérés dans le Portail des développeurs pour Teams.

Cette intégration multiplateforme signifie que Microsoft Entra ID d’agent fournit la couche d’identité unifiée, quel que soit l’emplacement d’origine des agents.

Considérations relatives à la conception pour les architectes de sécurité

Lors de la conception d’une solution d’identité d’agent :

• Établissez des identités d’agent en tant que classe d’identité distincte. Ne réaffectez pas les comptes d’utilisateurs humains ni les principaux de service standard pour les agents. Utilisez les constructions d’identité d’agent conçues pour garantir une gouvernance, une détection des risques et une couverture de stratégie appropriées.
• Exiger une organisation au niveau du plan directeur. Regroupez les agents associés sous des blueprints partagés pour simplifier l’attribution de stratégie et l’héritage des autorisations. Cela réduit la surcharge opérationnelle à mesure que les populations d’agents augmentent.
• Obliger l’affectation d’un sponsor pour chaque agent. Les agents non facturés sont des agents non gouvernementaux. Concevez vos processus pour empêcher la création d’identité de l’agent sans sponsor humain désigné.
• Appliquez l’accès au privilège minimum par défaut. Les identités d'agent héritent uniquement des permissions déléguées de leur blueprint au moment de la création. Concevoir des flux de travail d’attribution d’accès via des packages d'accès pour la gestion des droits avec approbation, expiration et contrôles de révision.
• Identité de couche et contrôles réseau. Combinez l’accès conditionnel pour les risques de l’agent avec les stratégies réseau d’accès sécurisé global pour une défense en profondeur. Les contrôles d’identité régissent l’acquisition de jetons ; les contrôles réseau régissent le trafic et le contenu.
• Planifiez les agents multilocataires. Si votre organisation utilise ou développe des agents opérant sur plusieurs locataires, concevez pour les principaux blueprint dans les locataires de ressources, de manière similaire aux principaux de service des applications multilocataires.
• Réduisez la prolifération des agents dès le départ. Exiger l’inscription de l’agent dans le Registre centralisé, appliquer la gestion du cycle de vie via la gouvernance des ID et planifier des révisions d’accès régulières pour les identités d’agent, comme vous le feriez pour les utilisateurs humains.
• Intégrez la surveillance des identités de l’agent aux opérations de sécurité. Les détections de risques de l’agent, les journaux de connexion et les journaux d’activité réseau doivent être acheminés vers votre SIEM (par exemple, Microsoft Sentinel) pour la corrélation avec des flux de travail de détection des menaces plus larges.