Microsoft a annoncé la disponibilité générale de Microsoft Execution Containers (MXC) le 7 octobre 2026. Pour les équipes qui exécutent des commandes proposées par un agent d’IA, la question pratique est de savoir quels fichiers et quelles connexions réseau la commande doit pouvoir utiliser, et quel backend MXC peut imposer ces limites. La publication de lancement décrit l’objectif de confinement ; la documentation destinée aux utilisateurs du dépôt fournit les détails de configuration. Ce guide suit ces documents. BIG CHANGE n’a pas installé MXC ni exécuté de charge de travail confinée.

Le grand changement

  • Ce qui a changé : Les développeurs peuvent transmettre une commande et sa stratégie de ressources à une interface unique du SDK MXC, qui sélectionne un backend hôte compatible. La version du 7 octobre fournit aux outils d’agents un parcours d’intégration documenté, au lieu de compter sur la bonne volonté du modèle pour respecter une stratégie.
  • Pourquoi c’est important : Une équipe peut autoriser une commande de programmation à accéder à son répertoire de travail tout en excluant d’autres emplacements de fichiers et les connexions sortantes de son périmètre d’action. Le résultat dépend du backend et de l’hôte choisis ; l’équipe doit donc vérifier l’application effective du backend avant de se fier à une restriction.
  • Points à surveiller : Les modes de création de stratégie de Microsoft aident à diagnostiquer les opérations bloquées sur les hôtes Windows ProcessContainer compatibles. La prochaine décision pratique consiste à déterminer si chaque autorisation proposée est nécessaire et si l’exécution en production utilise le mode d’application après le resserrement de la stratégie.

Commencez par l’hôte et la commande

MXC est une bibliothèque intégrée à l’application qui lance la charge de travail. Son fichier README répertorie les SDK Rust, .NET et Node, ainsi que des exécutables natifs pour les applications qui ne peuvent pas intégrer de SDK. Le paquet Node comprend des ressources d’exécution natives et nécessite Node.js 24 ou une version ultérieure ; sous Windows, le dépôt indique Node 24.21.0 ou ultérieur, ou Node 26.8.0 ou ultérieur, pour le transfert natif par stdio. L’API publique s’importe depuis @microsoft/mxc-sdk/v1, et non depuis la racine du paquet. Le paquet .NET comprend également des ressources natives. Le crate Rust intègre le SDK, le moteur et les backends sélectionnés dans l’application qui l’utilise. Les exécutables natifs nécessitent une compilation du dépôt pour la plateforme concernée.

Choisissez le backend avant de rédiger une stratégie. Le dépôt indique que processcontainer est le backend par défaut de Windows 11, bubblewrap celui de Linux et seatbelt celui de macOS. Windows propose aussi wslc et isolation_session ; windows_sandbox, microvm et hyperlight sont indiqués comme expérimentaux. Linux nécessite le runtime choisi, par exemple Bubblewrap pour son backend par défaut. Le tableau des versions de Windows indique les builds minimum requis pour ProcessContainer et IsolationSession. Vérifiez la disponibilité de l’hôte et sa compatibilité avec la stratégie demandée sur la machine qui exécutera la tâche.

Notez la commande réelle, le répertoire de travail, les fichiers qu’elle doit lire et modifier, ainsi que les destinations réseau nécessaires. Traitez ces éléments comme des paramètres de stratégie fournis par l’application ou l’opérateur. Selon Microsoft, la stratégie se trouve hors de la charge de travail de l’agent ; le code généré ne peut donc pas étendre ses propres autorisations. La sortie habituelle de la commande comprend stdout, stderr et le code de sortie, auxquels peuvent s’ajouter des avertissements ou des métadonnées facultatives du SDK. Un rapport d’activité n’est disponible que dans les modes de diagnostic documentés sur les hôtes Windows ProcessContainer compatibles.

Définissez une stratégie minimale avec le SDK Node

Le guide du SDK Node documente cette structure V1. Installez le SDK dans une application utilisant une version compatible de Node :

Terminal
npm install @microsoft/mxc-sdk

Cet exemple adapte l’exécution jusqu’à son terme présentée par Microsoft. Il demande un accès en lecture seule au répertoire actuel de l’application et bloque les connexions sortantes. La commande se contente d’afficher une ligne : elle ne teste donc aucune des deux restrictions. Il s’agit d’un point de départ documenté, pas d’un test réalisé par BIG CHANGE. Remplacez la commande et les chemins par ceux de la charge de travail à confiner ; utilisez readwritePaths uniquement pour les répertoires qu’elle doit modifier.

TypeScript
import { getPlatformSupport, run } from '@microsoft/mxc-sdk/v1';
import type { ContainerRequest } from '@microsoft/mxc-sdk/v1';

if (!getPlatformSupport().isSupported) {
  throw new Error('MXC is not available on this host');
}

const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  filesystem: { readonlyPaths: [process.cwd()] },
  network: { egress: { default: 'deny' } },
  timeoutMs: 30_000,
};

const result = await run(request);
console.log(result.stdout, result.stderr, result.exitCode, result.warnings);

run renvoie stdout et stderr capturés, le code de sortie, l’état du délai d’expiration et les avertissements. Un accès aux fichiers bloqué peut apparaître comme une erreur ordinaire d’accès refusé pour la charge de travail ; une sortie réussie ne prouve pas à elle seule que toutes les restrictions prévues ont été testées. Pour respecter le critère de réussite de la tâche, exécutez une charge de travail fiable qui utilise une ressource autorisée, puis effectuez séparément une tentative délibérée d’accès à une ressource non autorisée sur le backend compatible choisi. Vérifiez l’opération et les diagnostics avant d’appliquer la stratégie à des commandes générées par un agent. Les exemples du SDK couvrent les autorisations du système de fichiers, le blocage réseau, la capture de sortie et la journalisation des refus. Ils nécessitent un hôte préparé. BIG CHANGE n’a effectué aucune de ces étapes.

Pour les utilisateurs de l’exécuteur natif, le schéma JSON stable est 1.0.0 ; une requête complète nécessite un version, un choix de confinement et process.commandLine. Le schéma de développement actuel est 1.1.0-alpha. Le SDK V1 choisit lui-même son contrat de transmission ; n’ajoutez donc pas de version du schéma natif au ContainerRequest typé. Le guide du schéma précise aussi que les anciens champs tels que network.defaultPolicy et allowedHosts sont obsolètes. La stratégie actuelle utilise les network.egress et network.ingress directionnels ; les règles directes et un proxy d’exécution ont des comportements et une compatibilité backend différents.

Diagnostiquez les refus, puis appliquez la stratégie

Le tableau des modes du 7 octobre de Microsoft distingue trois résultats. Le mode Application bloque les accès non autorisés et ne produit aucun rapport d’activité. Le mode Learning bloque et consigne les accès non autorisés. Le mode Permissive consigne les accès que la stratégie refuserait, mais les laisse se poursuivre. La référence de Microsoft sur la capture des refus limite ces fonctions d’apprentissage aux chemins Windows ProcessContainer fondés sur AppContainer. Les autres hôtes n’obtiennent pas un rapport équivalent du simple fait qu’ils acceptent un champ de stratégie commun.

Pour un outil fiable utilisé pendant la création de la stratégie, l’exécuteur natif de Windows prend en charge un flux --audit qui peut produire des artefacts de stratégie. Microsoft avertit qu’il désactive la sécurité du bac à sable pour la charge de travail analysée ; il ne convient donc pas aux commandes non fiables. Lorsqu’il est pris en charge par l’hôte, une capture qui refuse et consigne l’accès constitue une voie de diagnostic plus sûre : la tentative reste bloquée et le rapport indique ce qui a été refusé. Examinez chaque chemin ou capacité consigné au regard de la tâche, n’accordez que ce dont la commande a besoin et exécutez la charge de travail finale en mode Application. Les rapports peuvent révéler des noms de ressources sensibles ; traitez-les en conséquence.

Le choix du backend modifie les garanties offertes par la stratégie. Le guide du schéma indique que isolation_session ne peut pas restreindre le réseau et exige une configuration explicitement sans restriction réseau. Il précise également que les restrictions d’interface sont appliquées par Windows ProcessContainer et macOS Seatbelt, mais pas par les autres backends ; WSLC et IsolationSession refusent toute stratégie d’interface fournie. Le guide Seatbelt indique que le profil natif de macOS ne peut pas filtrer des hôtes distants individuels, tandis que le guide Bubblewrap décrit les prérequis du runtime et du réseau sous Linux. L’acceptation d’un champ JSON par plusieurs types de SDK ne prouve donc pas une application identique partout. Consultez le guide du backend choisi et validez la requête sur l’hôte cible.

Le dépôt de Microsoft est sous licence MIT, mais sa documentation destinée aux utilisateurs ne donne pas le prix du paquet MXC. L’hôte, le calcul et tout fournisseur de modèles ont leurs propres coûts. L’annonce Windows qualifie MXC de disponibilité générale, tandis que plusieurs options de backend restent expérimentales et que le schéma de développement natif est en version alpha. Tenez compte séparément de ces stades de publication lorsque vous choisissez où exécuter une charge de travail.

Sources et lectures complémentaires

  • Microsoft Windows Developer Blog, 7 octobre 2026établit l’annonce du lancement, l’usage prévu avec des agents et les définitions des trois modes. Il s’agit de la description du produit par Microsoft, pas d’un test de sécurité de BIG CHANGE.
  • README du dépôt MXCrépertorie les SDK, les backends par défaut des hôtes, les backends expérimentaux, les prérequis de compilation et le parcours de l’exécuteur natif. Le dépôt évolue ; les détails ont été vérifiés le 8 octobre 2026.
  • Guide utilisateur du SDK Nodeprécise les prérequis Node, l’importation V1, la requête typée et la sortie capturée. Le code ci-dessus est adapté à partir de son exemple ; il n’a pas été exécuté ici.
  • Guide du schéma de configurationdistingue le JSON natif stable 1.0.0 du 1.1.0-alpha évolutif, et documente les champs de stratégie ainsi que les limites propres à chaque backend.
  • Référence sur le mode Learning et la capture des refusdocumente les diagnostics Windows ProcessContainer et met en garde contre l’audit permissif. Les rapports dépendent de l’hôte et du mode.
  • Guides des backends et le tableau des versions de Windows sont les références à consulter pour un hôte donné ; cet article ne certifie aucune configuration sur la machine du lecteur.