AI-translated from English; not yet reviewed by a fluent editor.

# Configurer une stratégie MXC pour les commandes générées par un agent

> Le SDK MXC de Microsoft permet aux développeurs de définir une commande ainsi que ses stratégies d’accès aux fichiers et au réseau. Ce guide fondé uniquement sur la documentation présente la configuration avec Node V1, les modes de diagnostic et les limites des backends.

By BIG CHANGE Editorial

Published: 2026-10-08T05:14:55.341Z
Updated: 2026-10-08T05:14:55.341Z
Canonical: https://bigchange.ai/blog/mxc-agent-command-containment-guide

![Conceptual charcoal illustration of a small computer with an external drive connected and a network cable lying unplugged beside its port.](https://bigchange.ai/api/media/file/mxc-explicit-connections-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no MXC product interface, hardware, security test or enforcement result is depicted.

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](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) décrit l’objectif de confinement ; la [documentation destinée aux utilisateurs du dépôt](https://github.com/microsoft/mxc) 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](https://github.com/microsoft/mxc) 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](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) 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](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) documente cette structure V1. Installez le SDK dans une application utilisant une version compatible de Node :

```bash
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](https://github.com/microsoft/mxc/blob/main/samples/README.md) 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](https://github.com/microsoft/mxc/blob/main/docs/schema.md) 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](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) 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](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) 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](https://github.com/microsoft/mxc/blob/main/docs/schema.md) 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](https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md) indique que le profil natif de macOS ne peut pas filtrer des hôtes distants individuels, tandis que le [guide Bubblewrap](https://github.com/microsoft/mxc/blob/main/docs/backends/bwrap/bubblewrap-backend.md) 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](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)é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 MXC](https://github.com/microsoft/mxc)ré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 Node](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md)pré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 configuration](https://github.com/microsoft/mxc/blob/main/docs/schema.md)distingue 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 refus](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md)documente 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](https://github.com/microsoft/mxc/tree/main/docs/backends) et le [tableau des versions de Windows](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) sont les références à consulter pour un hôte donné ; cet article ne certifie aucune configuration sur la machine du lecteur.

## Sources

- [Lancement de Microsoft Execution Containers](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) — Annonce de disponibilité générale, limites de la charge de travail et des ressources, et définitions des trois modes ; les affirmations du fournisseur ne sont pas des tests indépendants.
- [README du dépôt MXC](https://github.com/microsoft/mxc) — SDK, backends par défaut des hôtes, labels des backends expérimentaux, parcours de l’exécuteur natif, licence du code source et prérequis de compilation.
- [README du SDK MXC pour Node](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) — Importation V1, version minimale de Node, requête typée, sortie d’exécution et découverte de l’hôte. L’exemple est adapté, il n’a pas été exécuté.
- [Guide du schéma MXC](https://github.com/microsoft/mxc/blob/main/docs/schema.md) — Contrats JSON natifs stables 1.0.0 et de développement 1.1.0-alpha, stratégie réseau et limites des backends et de l’interface.
- [Guide MXC de capture des refus](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) — Comportement des modes Learning et Permissive dans Windows ProcessContainer, avertissement de sécurité sur --audit et limites de sortie.
- [Exemples du SDK MXC](https://github.com/microsoft/mxc/blob/main/samples/README.md) — Index officiel des exemples de système de fichiers, réseau, capture de sortie et capture des refus.
- [Compatibilité de MXC avec les versions de Windows](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) — Builds Windows minimum pour ProcessContainer et IsolationSession.
- [Guide du backend Bubblewrap de MXC](https://github.com/microsoft/mxc/blob/main/docs/backends/bwrap/bubblewrap-backend.md) — Prérequis du backend Linux par défaut et prise en charge réseau.
- [Guide du backend Seatbelt de MXC](https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md) — Limites du profil natif de macOS et du filtrage des hôtes distants.