Microsoft veut placer les agents d’IA sous contrôle continu

Un nouvel acteur doté de moyens d’action

Microsoft étend Project Perception afin d’encadrer les agents d’intelligence artificielle utilisés dans les entreprises. Un agent est un logiciel capable d’organiser plusieurs étapes et d’utiliser des outils pour accomplir une mission. Il peut écrire du code, étudier des revenus, traiter des dépenses ou agir directement dans des applications. Son utilité dépend souvent d’un accès aux données, aux outils et parfois à d’autres agents.

Une erreur peut donc dépasser la production d’une réponse incorrecte et provoquer une opération dans un système réel. Le risque ne signifie pas que ces agents sont malveillants par nature. Il vient de l’autorité qu’un utilisateur leur délègue et de leur capacité à travailler continuellement, rapidement et à grande échelle. Un agent peut se tromper, subir une manipulation ou être compromis pendant son activité.

L’observation part d’un parc difficile à recenser

L’observation présentée par Microsoft concerne d’abord la dispersion de ces logiciels. Certains agents sont créés dans ses plateformes, tandis que d’autres proviennent de partenaires ou sont installés localement. Ces derniers peuvent apparaître sans passer par un processus central de déploiement. Les équipes de sécurité risquent alors d’ignorer leur existence, leur propriétaire ou les ressources auxquelles ils accèdent.

Microsoft annonce la détection de 35 types supplémentaires d’agents locaux, pour un total de 60 types pris en charge. Claude Code, OpenAI Codex et GitHub Copilot figurent parmi les outils cités. La méthode proposée commence par leur inscription dans un registre commun. Celui ci doit relier chaque agent à son propriétaire, à son activité et aux risques observés, quelle que soit son origine.

Une identité distincte pour contenir les permissions

Project Perception et Microsoft Agent 365 doivent partager leurs signaux et leur contexte avec ce registre. L’objectif est de fournir une vue commune aux équipes informatiques et aux responsables de la sécurité. La découverte ne constitue toutefois qu’une première étape. Microsoft veut attribuer à chaque agent une identité durable, différente de celle de la personne qui l’utilise ou qui l’a déployé.

Microsoft étend pour cela Entra Agent ID aux agents locaux ou auparavant inconnus, repérés par ses capteurs. Cette identité doit permettre d’appliquer des règles à un logiciel qui n’était pas initialement intégré aux services de sécurité. Elle doit aussi distinguer une action humaine d’une opération exécutée pour le compte d’une personne. Les autorisations, la responsabilité et le cycle de vie disposent alors d’un point d’ancrage commun.

L’interprétation centrale est qu’un agent ne doit pas hériter automatiquement de tous les droits permanents de son utilisateur. Microsoft propose qu’il commence sans autorisation, puis reçoive uniquement les accès nécessaires à une tâche approuvée. Ces droits pourraient être limités dans le temps, réduits si la mission change, puis supprimés à son achèvement. Une opération importante pourrait exiger une approbation humaine vérifiable avant son exécution.

Des barrières extérieures au modèle

Le modèle et le programme qui organise son travail devraient fonctionner dans un bac à sable, un environnement isolé soumis à des règles. Microsoft cite son Execution Container comme exemple de cette séparation. L’agent ne devrait pas pouvoir neutraliser les contrôles chargés de l’observer, même s’il est compromis. Ses appels aux outils et aux ressources devraient également passer par des points de contrôle indépendants.

Cette séparation répond au caractère variable des modèles d’intelligence artificielle. Un agent peut commencer une mission correctement, puis réagir autrement lorsque ses données, son contexte ou son plan évoluent. Les décisions de sécurité ne doivent donc pas appartenir au modèle surveillé. Microsoft propose que des systèmes extérieurs déterminent ce qu’il peut lire, modifier, appeler ou approuver à chaque étape.

La protection doit ensuite évoluer avec le comportement observé. Dynamic Agent Risk combine des signaux issus de l’identité, des données, des appareils, du réseau, du cloud et de l’activité. Dynamic Conditional Access utilise cette estimation pour réduire les permissions, bloquer l’écriture ou restreindre les ressources accessibles. Le système peut aussi demander une validation humaine, isoler l’environnement ou arrêter complètement l’exécution.

Un scénario parlant, mais aucune mesure d’efficacité

Microsoft illustre son approche avec un agent chargé d’approuver des dépenses courantes. Celui ci peut lire une demande, vérifier une règle et autoriser un remboursement sans obtenir tous les accès de son responsable. Il peut ensuite rencontrer une injection de consigne, une instruction hostile dissimulée dans un contenu consulté. Le dispositif conserverait alors la lecture tout en bloquant l’approbation, l’écriture ou l’accès aux ressources sensibles.

Les Guardian Agents doivent enquêter sur les changements de risque, recommander un confinement et appliquer des procédures définies par les équipes humaines. Microsoft évoque aussi des signaux tirés du raisonnement du modèle pour repérer une dérive par rapport à la tâche. Ces indices enrichiraient l’analyse sans donner au modèle le pouvoir de décider seul. Les personnes conserveraient le contrôle des objectifs, des règles et des décisions importantes.

La publication expose cependant une architecture et une interprétation du risque, plutôt qu’une évaluation expérimentale. Elle ne décrit aucun protocole d’essai et ne fournit aucune mesure permettant de comparer cette approche à une autre. Aucun taux d’erreur, résultat indépendant ou calendrier détaillé n’est présenté. Son efficacité réelle et sa capacité à contenir des agents à grande échelle restent donc impossibles à mesurer avec cette seule source.