Windows Execution Containers : isoler les agents autonomes au niveau de l'OS

De quoi s’agit-il ?

Le 2 juin 2026, lors de Build 2026, Microsoft a publié Windows platform security for AI agents, annonçant une préversion anticipée du SDK Microsoft Execution Containers (MXC) — une couche d’exécution multiplateforme et pilotée par politique pour les agents IA sur Windows et WSL. L’approche est structurelle : plutôt que de demander à chaque framework d’agent de réinventer son sandbox, MXC fait descendre le confinement, l’identité et l’application des politiques dans le système d’exploitation, où ils sont appliqués de façon cohérente à l’exécution.

Cette démarche répond à un problème que nous couvrons sous de nombreux angles : un agent autonome qui lit des fichiers, invoque des outils et génère son propre code à l’exécution hérite de toute l’autorité de la session utilisateur, sauf si quelque chose vient l’encadrer activement. MXC est la tentative de Microsoft de faire de cette frontière une primitive de l’OS de première classe, et non un ajout greffé après coup sur chaque application.

Comment ça fonctionne

L’idée centrale, que Microsoft appelle le sandbox composable, tient en un seul modèle de politique et un seul SDK qui se projettent sur différents mécanismes d’isolation selon le risque de la charge de travail. Le développeur déclare ce qu’il faut contraindre, et Windows l’applique, sans que personne ait à écrire à la main l’isolation de bas niveau. Deux niveaux de confinement figurent dans la préversion.

L’isolation de processus est le niveau léger. Elle exécute le code généré par le modèle dans une frontière de processus dédiée qui restreint l’accès aux fichiers et aux domaines réseau hors politique définie, tout en gardant la boucle de développement réactive. GitHub Copilot CLI a déjà adopté ce mode pour limiter ce que son code généré dynamiquement peut atteindre.

L’isolation de session est le niveau renforcé. Elle sépare l’exécution de l’agent du bureau interactif de l’utilisateur, du presse-papiers, de l’interface et des périphériques d’entrée — atténuant l’usurpation d’interface, l’injection d’entrées et la fuite de données entre sessions. Point essentiel : les sessions s’exécutent sous des comptes utilisateurs distincts ; Windows attribue à chaque agent une identité locale ou adossée à Entra et rattache toute son activité à cette identité, de sorte que les actions humaines et celles de l’agent restent nettement séparables et auditables. La politique d’accès s’applique via Microsoft Entra et Intune, ce qui permet aux entreprises de gouverner les garde-fous de manière centralisée.

La feuille de route étend le même SDK aux micro-VM (isolation adossée à l’hyperviseur pour les charges à plus haut risque ou le code non fiable, explicitement présentée comme une réponse à des travaux montrant que les LLM développent des capacités d’évasion de sandbox), aux conteneurs Linux via WSL, et à Windows 365 for Agents, où le rayon d’impact d’un agent compromis se limite à un Cloud PC jetable. Le SDK est public sur GitHub.

Pourquoi c’est important

Le confinement est l’un des trois pieds de la triade létale : si un agent qui ingère du contenu non fiable et peut agir doit rester sûr, il faut bien que quelque chose délimite le sens du verbe « agir ». Historiquement, cette tâche revenait à chaque framework, de façon inégale — c’est précisément pourquoi les RCE d’agents de code et les défaillances de frontière de privilèges se répètent. Standardiser le confinement au niveau de l’OS, avec une identité par agent qui rend les actions attribuables, est le type de changement structurel qui relève le plancher pour tout le monde, au lieu de corriger un produit à la fois.

Les réserves sont tout aussi structurelles. MXC est une préversion anticipée, le support initial de session est non interactif, et la frontière la plus robuste — la micro-VM — reste sur la feuille de route, pas en production. L’isolation de processus est qualifiée de robustesse modérée par Microsoft elle-même ; ce n’est pas un mur d’hyperviseur. Et le confinement au niveau de l’OS traite le pied action de la triade, pas le pied injection : un agent confiné par une politique peut toujours être orienté vers un mauvais usage de l’autorité que cette politique lui accorde. La nouvelle détection d’injection de prompt de Windows Defender est un contrôle complémentaire, pas un substitut au traitement du contenu récupéré comme non fiable.

Défenses

Considérez MXC comme une fondation sur laquelle bâtir, pas comme une garantie achevée. Adaptez le niveau de confinement à la charge : isolation de processus pour les agents de code réactifs, isolation de session (avec son compte utilisateur distinct et son auditabilité complète) pour l’automatisation de longue durée qui tourne aux côtés d’un humain, et prévoyez une isolation micro-VM ou Cloud PC lorsqu’un agent traite des données sensibles ou exécute du code non fiable. Dans la mesure du possible, donnez à chaque agent sa propre identité et appliquez une politique de fichiers et de réseau au moindre privilège via Entra et Intune, afin que l’activité de l’agent soit attribuable et révocable indépendamment de l’utilisateur. Maintenez la défense en profondeur : associez le confinement à des contrôles côté entrée — traitement du contenu non fiable, filtrage des sorties et détection d’injection — car un agent bien confiné peut toujours être trompé pour détourner ses capacités autorisées. Enfin, ces fonctionnalités vivant dans des builds Insider et des préversions, testez-les avant d’en dépendre, et ne laissez pas « appliqué par l’OS » devenir une raison de confier à un agent plus d’autorité qu’il n’en a besoin.

Statut

MXC a été annoncé le 2 juin 2026 à Build 2026 par Dana Huang et Logan Iyer (Microsoft), le SDK étant publié en préversion anticipée sur GitHub et l’isolation de processus/session visée pour les builds Windows Insider peu après Build. Il s’agit d’une contribution défensive de plateforme, pas d’une divulgation de vulnérabilité — aucun CVE, aucun exploit associé. Parmi les partenaires cités par Microsoft figurent GitHub Copilot CLI (isolation de processus, déjà livrée), OpenShell de NVIDIA, OpenClaw, Codex d’OpenAI, Manus et Hermes Agent de Nous Research. À lire comme le signe que le confinement des agents passe de l’improvisation au niveau des frameworks vers une primitive de l’OS — une orientation à suivre, et à éprouver, avant de lui accorder sa confiance.