Microsoft a rendu les conteneurs d’exécution (MXC) disponibles de manière générale sur Windows 11, offrant aux développeurs et aux administrateurs informatiques un moyen de limiter les fichiers, réseaux et ressources système auxquels les agents d’IA peuvent accéder. Cette technologie crée des frontières imposées par le système d’exploitation autour des agents qui exécutent du code, utilisent des outils de développement ou effectuent des tâches au nom d’un utilisateur.
Annoncée le 7 oct., cette version introduit plusieurs options de confinement, notamment des processus isolés et des sessions Windows distinctes. Toutefois, toutes les fonctionnalités ne sont pas prêtes pour une utilisation en production. La prise en charge des MicroVM reste expérimentale, tandis que la gestion centralisée via Microsoft Intune et l’élargissement des contrôles d’identité des agents sont toujours en cours de développement.
Selon l’annonce de Microsoft, MXC applique les règles de ressources indépendamment de l’agent lui-même. Un agent d’IA ne peut pas simplement s’accorder un accès supplémentaire aux fichiers ou au réseau lorsque sa tâche nécessite des autorisations qui dépassent la limite approuvée.
Pour les équipes de sécurité qui déploient des agents d’IA, l’avantage immédiat réside dans un meilleur contrôle de ce que peuvent atteindre le code généré par les agents et les outils automatisés. Les organisations doivent néanmoins sélectionner le niveau d’isolation approprié, définir des règles d’accès et vérifier que ces restrictions restent appliquées.
Comment les conteneurs d’exécution Microsoft isolent les agents d’IA
MXC utilise un schéma de configuration JSON unifié et un SDK pour définir les éléments auxquels une charge de travail peut accéder. Les développeurs peuvent restreindre la lecture et l’écriture de fichiers, les connexions réseau, l’exécution de processus et les interactions avec le bureau de l’utilisateur.
Par exemple, un agent de programmation pourrait être autorisé à modifier les fichiers d’un dépôt logiciel tout en étant empêché de changer la configuration des serveurs de production ou d’accéder aux documents personnels d’un employé.
Microsoft identifie quatre moteurs de confinement aux propriétés de sécurité différentes.
- Conteneurs de processus : Disponibles sur Windows 11, macOS et Linux. Ils assurent une isolation légère des processus grâce à AppContainer sur Windows, Seatbelt sur macOS et Bubblewrap sur Linux.
- Conteneurs de session : Disponibles sur Windows 11. Les agents s’exécutent sous un compte et dans une session Windows distincts, isolant leur bureau, leur presse-papiers, leur interface utilisateur et leurs entrées de ceux de l’utilisateur interactif.
- Conteneurs WSL : Disponibles sur Windows 11. Ils fournissent des environnements d’exécution Linux pour les outils des agents et les charges de travail de développement qui reposent sur le Sous-système Windows pour Linux.
- Conteneurs MicroVM : Expérimentaux sur Windows 11 et Linux. Ils utilisent la virtualisation matérielle pour les charges de travail nécessitant une isolation renforcée.
Le moteur approprié dépend de la charge de travail. Un assistant de programmation peut avoir besoin d’un accès réactif aux outils de développement, tandis qu’un agent qui manipule des fichiers sensibles peut nécessiter une séparation plus forte de la session de l’utilisateur.
L’isolation des sessions est particulièrement pertinente pour les agents qui interagissent avec des applications de bureau. En séparant le bureau et l’environnement de saisie d’un agent de ceux de l’utilisateur, Windows peut limiter les possibilités d’interactions involontaires avec les applications exécutées dans la session de l’employé.
Ces contrôles étendent le modèle de sécurité de Windows 11, qui utilise déjà les protections du système d’exploitation pour restreindre les privilèges des applications et leur accès aux ressources sensibles.
Modes d’application, d’apprentissage et permissif
MXC comprend trois modes de fonctionnement qui déterminent le comportement des restrictions d’accès configurées.
Mode d’application bloque les opérations qui sortent de la règle approuvée. Les activités autorisées se poursuivent, tandis que les demandes de ressources dépassant la limite définie sont refusées.
Mode d’apprentissage bloque également les opérations non autorisées, mais les consigne dans un rapport d’activité JSON. Les développeurs et les administrateurs peuvent utiliser ces informations pour repérer les autorisations manquantes et ajuster les règles sans désactiver le confinement.
Mode permissif consigne les activités que la règle MXC refuserait, mais les autorise, sous réserve des autres restrictions applicables du système d’exploitation et de l’organisation.
Cette distinction est importante pour les équipes de sécurité. Le mode permissif aide les développeurs à comprendre les besoins d’un agent en matière de ressources, mais il n’applique pas les restrictions MXC configurées.
Les organisations devraient utiliser le mode d’application pour les charges de travail de production qui nécessitent ces restrictions et réserver le mode permissif au développement et aux tests contrôlés des règles.
Microsoft prend également en charge des contrôles organisationnels capables de restreindre davantage les autorisations demandées par les développeurs d’agents.
Toutefois, la gestion centralisée des règles Intune pour les conteneurs de processus MXC n’est pas encore disponible de manière générale. Microsoft indique que cette fonctionnalité sera proposée dans une prochaine version, afin de permettre aux équipes informatiques de régir la création des conteneurs et l’accès aux ressources sur les appareils Windows administrés.
L’identité des agents est un autre composant en cours de développement. Microsoft prévoit d’intégrer les fonctionnalités d’identité Entra à Microsoft Agent 365 afin que les organisations puissent distinguer l’activité des agents de celle des employés et appliquer des contrôles à chaque agent.
Ces fonctionnalités sont distinctes de la technologie de confinement désormais disponible de manière générale.
Quels agents d’IA prennent en charge MXC et quels contrôles les équipes de sécurité doivent effectuer
Microsoft cite GitHub Copilot, OpenAI Codex, OpenClaw, Replit, LM Studio, NVIDIA OpenShell et Unsloth AI parmi les agents et frameworks qui prennent déjà en charge MXC.
D’autres intégrations sont prévues pour Anthropic Claude Code, Box, Egnyte, Manus, Perplexity et plusieurs autres produits.
La prise en charge d’une intégration ne signifie pas nécessairement que toutes les fonctionnalités d’un agent ou toutes les configurations de déploiement s’exécutent dans un conteneur MXC. Les organisations doivent vérifier les options de confinement prises en charge par l’agent choisi et la manière dont ses autorisations sont appliquées.
Cette distinction est importante pour les déploiements d’agents en entreprise pouvant accéder à des ressources sensibles. Les préoccupations récentes concernant des agents Claude accédant à des systèmes en production montrent qu’il est nécessaire de définir les autorisations opérationnelles avant d’autoriser les agents à interagir avec des environnements de production.
Le confinement de l’exécution a également ses limites.
Un conteneur peut empêcher un agent de lire des fichiers non autorisés ou d’atteindre des destinations réseau interdites. Il ne peut pas déterminer si l’agent a été manipulé pour effectuer une action indésirable en utilisant des ressources auxquelles il était légitimement autorisé à accéder.
Par exemple, une attaque par injection de prompt pourrait convaincre un agent de divulguer des informations via une destination approuvée. Si le transfert respecte les autorisations configurées, le confinement seul ne suffirait pas nécessairement à l’arrêter.
Les organisations qui déploient des agents d’IA ont donc besoin de contrôles de sécurité pour les agents d’IA supplémentaires concernant l’autorisation des outils, l’accès aux données sensibles et l’approbation humaine des actions à haut risque.
Les équipes de sécurité qui évaluent MXC devraient donner la priorité à quatre contrôles :
- Sélectionner le moteur approprié. Adapter les options d’isolation prises en charge — processus, session ou autres — à la sensibilité de la charge de travail.
- Appliquer des règles de moindre privilège. N’accorder l’accès qu’aux fichiers, outils, destinations réseau et ressources d’interface utilisateur nécessaires.
- Vérifier les paramètres d’application. Confirmer que les charges de travail de production utilisent le mode d’application lorsque les restrictions doivent bloquer les opérations non autorisées.
- Tester le comportement de l’agent. Utiliser le mode d’apprentissage pour repérer les autorisations manquantes, examiner les demandes de ressources inattendues et affiner les règles avant le déploiement.
Les équipes doivent également confirmer la configuration Windows prise en charge et les exigences du moteur MXC pour les charges de travail envisagées. Microsoft documente la disponibilité des moteurs selon le système d’exploitation, mais les prérequis de déploiement peuvent varier.
Les conteneurs d’exécution Microsoft permettent de limiter les ressources disponibles pour les agents d’IA sans leur donner un accès sans restriction à l’environnement de l’utilisateur. Leur valeur en production dépendra de la manière dont les organisations configurent ces limites et les associent à des contrôles d’identité, à la surveillance et à des exigences d’approbation.
À lire aussi : Les organisations qui déploient des outils autonomes peuvent renforcer leur supervision en gouvernant les agents d’IA d’entreprise et en limitant leur accès aux systèmes sensibles.