Microsoft a présenté un cadre de sécurité qui traite les agents IA comme une forme de risque interne. Selon l'entreprise, les organisations doivent contrôler leurs identités, leurs permissions et le comportement de leurs agents à l'exécution, indépendamment des modèles eux-mêmes.
Les recommandations de sécurité de Microsoft publiées le 19 octobre 2026 ne constituent pas une divulgation d'incident ou de vulnérabilité. Elles traitent du risque opérationnel qui apparaît lorsque des agents reçoivent un accès aux données, aux outils et à l'infrastructure de l'entreprise, et peuvent ensuite agir à la vitesse de la machine.
Microsoft ne décrit pas les agents comme intrinsèquement hostiles. Sa préoccupation tient au fait que les résultats d'un modèle peuvent varier, que le contexte d'une tâche peut évoluer et qu'un contenu externe peut manipuler un agent par ailleurs légitime. Un système qui commence correctement une tâche peut donc dévier par la suite, à cause d'une erreur, d'une compromission ou d'une injection de prompt.
L'entreprise qualifie cela d'« initié agentique » : un logiciel qui agit avec une autorité organisationnelle déléguée, sans comportement entièrement déterministe.
Les contrôles doivent rester en dehors du modèle
Le principe central de Microsoft consiste à « entourer une intelligence non déterministe de contrôles déterministes, de preuves indépendantes et de frontières de confinement ».
Dans ce modèle, un agent ne doit pas décider lui-même des limites de son autorité. Les mécanismes d'identité, d'accès et d'application doivent fonctionner en dehors du modèle, hors de sa portée pour les contourner ou les modifier.
Satya Nadella, président et directeur général de Microsoft, a résumé cette approche en affirmant que l'architecture agentique la plus fiable est celle qui conçue pour « faire le moins confiance au modèle ». La distinction pratique oppose le fait de faire confiance à un modèle pour qu'il se comporte correctement et le fait de bâtir un système qui limite les dégâts lorsqu'il ne le fait pas.
Microsoft organise le cadre autour de quatre responsabilités continues :
- Connaître : tenir un inventaire des agents, de leurs propriétaires, de leur finalité prévue et de leur activité observée.
- Confiner : restreindre les données, les systèmes et les actions avant qu'un agent ne commence à fonctionner.
- Protéger : sécuriser chaque composant sur le chemin de l'agent, y compris les outils, les environnements d'exécution et les ressources de l'entreprise.
- Adapter : revoir les protections lorsque le comportement, le contexte ou le risque évalué change.
Ces responsabilités ne sont pas présentées comme des étapes de mise en œuvre successives. Microsoft décrit plutôt une boucle de rétroaction dans laquelle de nouvelles preuves modifient le risque, le risque modifie la politique, et la politique modifie ce que l'agent peut faire.
Lorsque le risque augmente, le cadre peut conserver l'accès en lecture tout en bloquant les écritures, réduire les ressources disponibles pour l'agent, exiger une approbation humaine vérifiée pour les actions importantes, ou isoler l'agent et l'arrêter.
Chaque agent reçoit une identité distincte
Une conséquence immédiate pour les équipes de sécurité est qu'un agent ne doit pas fonctionner simplement comme une extension du compte d'un employé.
Microsoft affirme que chaque agent a besoin de sa propre identité de premier plan, distincte de celle de la personne qui le parraine. Cela permet aux systèmes d'audit et d'accès de distinguer les actions directes d'un employé des opérations effectuées par un agent pour son compte.
L'entreprise indique qu'elle ajoute la prise en charge de la découverte de 35 types d'agents locaux supplémentaires, portant le total pris en charge à 60. Parmi les exemples figurent Claude Code, OpenAI Codex et GitHub Copilot. La découverte doit couvrir les agents développés par Microsoft, les plateformes et les SDK de partenaires, ainsi que les agents introduits localement.
Microsoft indique également qu'elle étend Microsoft Entra Agent ID avec des types d'identité destinés à d'autres modèles d'agents, notamment les agents locaux et les agents inconnus précédemment détectés par des capteurs de sécurité. Selon l'entreprise, Project Perception et Microsoft Agent 365 partagent des signaux et utilisent un registre unifié.
Pour les administrateurs, ce modèle transforme la découverte des agents en un problème de gestion d'actifs : une organisation ne peut pas appliquer de contrôles d'accès significatifs si elle ne sait pas quels agents existent, qui en est responsable et ce qu'ils font.
Bac à sable et accès aux outils médiatisé
Microsoft recommande d'exécuter les modèles et leurs infrastructures d'encadrement dans des environnements contrôlés, plutôt que de leur laisser hériter de tous les privilèges d'un appareil.
Elle cite Microsoft Execution Container (MXC) comme exemple de bac à sable conçu pour appliquer un accès aux ressources contrôlé par des politiques. La frontière d'application doit se trouver à l'extérieur de l'agent, plutôt que de dépendre d'instructions contenues dans le modèle.
Le cadre rejette également la découverte d'outils sans restriction. Un agent ne doit pas pouvoir invoquer automatiquement chaque API, chaque serveur MCP, chaque ressource réseau, chaque outil local ou chaque autre agent qu'il rencontre. Les contrôles locaux, réseau et sur les données doivent servir d'intermédiaires pour ces connexions.
L'inspection du contenu est un autre élément de la conception. Les systèmes de sécurité doivent évaluer la sensibilité et l'origine des informations qui entrent dans un agent ou en sortent, y compris le fait qu'un élément non fiable puisse influencer ses décisions.
Microsoft illustre ce risque avec un agent d'approbation de notes de frais. Un tel agent peut légitimement avoir besoin de lire des demandes de remboursement, de les comparer à la politique interne et d'autoriser les remboursements courants. Il n'a pas besoin de toutes les autorisations détenues par son parrain. Si un document externe contient une injection de prompt, la configuration de l'agent peut rester inchangée, alors que son comportement, et donc son risque, a changé.
Des permissions qui expirent avec la tâche
Microsoft présente Dynamic Permissions comme un moyen de n'accorder aucun accès permanent à un agent par défaut. L'agent ne recevrait que l'autorité nécessaire à une tâche approuvée, et uniquement pendant la durée de cette tâche.
Une politique à l'échelle de l'organisation définirait la limite maximale. En particulier, un agent ne pourrait pas obtenir une autorité que son utilisateur parrain ne possède pas. Les permissions pourraient être limitées à une tâche, expirer après une période déterminée ou être réduites au fil de l'avancement de la tâche. Les opérations à fort impact pourraient exiger une approbation humaine vérifiée.
L'employé conserverait son propre accès, tandis que l'agent disposerait d'une identité distincte et de ses propres permissions liées à la tâche. Cette séparation vise à rendre l'imputation et la révocation plus précises que si un agent réutilisait les identifiants et les privilèges d'une personne.
Microsoft décrit aussi Dynamic Agent Risk comme un score mis à jour en continu, construit à partir de signaux liés à l'identité, aux terminaux, aux données, au cloud, au réseau, à l'exécution et à l'activité des agents. L'évaluation prend en compte la configuration de sécurité de l'agent, les ressources auxquelles il peut accéder, l'impact probable d'une défaillance et les signes que ses actions s'écartent de l'intention de l'utilisateur ou de l'organisation.
Un schéma accompagnant l'annonce montre Microsoft Sentinel, Entra, Intune, Purview, Global Secure Access et Defender fournissant des signaux pour l'analyse contextuelle et l'évaluation du risque en temps réel. Microsoft relie cette évaluation à Dynamic Conditional Access, selon lequel la politique peut modifier ce qu'un agent peut lire, modifier, invoquer ou approuver à un moment donné.
Il s'agit des descriptions par Microsoft de ses capacités et de son architecture prévue, et non de preuves issues d'un déploiement démontré de manière indépendante.
L'automatisation surveillera également les agents
Microsoft soutient que l'examen manuel ne pourra pas passer à l'échelle lorsque les organisations déploieront « des milliers ou des centaines de milliers » d'agents. Sa réponse proposée comprend les Guardian Agents, des systèmes d'IA chargés d'aider à superviser d'autres agents tout en restant soumis à des limites définies par des humains.
Un rapport de Security Affairs publié le 20 octobre 2026 indique que les Guardian Agents peuvent suivre des playbooks créés par les opérateurs, enquêter sur les changements de risque, recommander ou appliquer des réponses et utiliser les résultats pour affiner la politique. Les humains continueraient de fixer les objectifs et d'approuver les décisions importantes.
Cette approche soulève un défi central de conception : l'application des règles ne peut pas dépendre uniquement d'un autre modèle, dont le comportement peut lui aussi varier. La réponse affichée par Microsoft consiste à garder les contrôles décisifs en dehors des modèles, là où les agents ne peuvent pas les modifier.
Pour les organisations qui adoptent les agents dès maintenant, ce cadre se traduit par des priorités concrètes : découvrir les agents locaux comme ceux déployés centralement, attribuer à chacun une identité distincte, supprimer les privilèges utilisateur hérités, limiter les chemins d'exécution et d'accès aux outils, inspecter les entrées non fiables, et exiger une approbation humaine ou un isolement lorsqu'un changement de risque rend une action dangereuse.
