Microsoft gab am 7. Oktober 2026 die allgemeine Verfügbarkeit von Microsoft Execution Containers (MXC) bekannt. Für Teams, die von einem KI-Agenten vorgeschlagene Befehle ausführen, lautet die praktische Frage: Auf welche Dateien und Netzwerkverbindungen muss der Befehl zugreifen, und welches MXC-Backend kann diese Grenzen durchsetzen? Der Ankündigungsbeitrag beschreibt das Ziel der Abschottung; die Benutzerdokumentation des Repositorys enthält die Konfigurationsdetails. Dieser Leitfaden folgt diesen Dokumenten. BIG CHANGE hat MXC weder installiert noch einen abgeschotteten Workload ausgeführt.

Die große Änderung

  • Was sich geändert hat: Entwickler können einen Befehl und seine Ressourcenrichtlinie an eine einzige MXC-SDK-Schnittstelle übergeben, die ein unterstütztes Host-Backend auswählt. Die Veröffentlichung vom 7. Oktober bietet einen dokumentierten Integrationsweg für Agentenwerkzeuge, statt darauf zu vertrauen, dass ein Modell Richtlinien freiwillig befolgt.
  • Warum das wichtig ist: Ein Team kann einem Programmierbefehl Zugriff auf sein Arbeitsverzeichnis gewähren und zugleich andere Dateipfade und ausgehende Verbindungen außerhalb der Befugnisse des Workloads halten. Die Wirkung hängt vom ausgewählten Backend und Host ab. Deshalb muss das Team prüfen, was das Backend tatsächlich durchsetzt, bevor es sich auf eine Einschränkung verlässt.
  • Worauf zu achten ist: Die Richtlinienmodi von Microsoft helfen, blockierte Vorgänge auf unterstützten Windows-ProcessContainer-Hosts zu diagnostizieren. Als Nächstes ist praktisch zu entscheiden, ob jede vorgeschlagene Berechtigung notwendig ist und ob der Produktionslauf nach dem Einschränken der Richtlinie den Durchsetzungsmodus verwendet.

Zuerst Host und Befehl festlegen

MXC ist eine Bibliothek, die in die Anwendung integriert wird, welche den Workload startet. Die README-Datei führt SDKs für Rust, .NET und Node sowie native ausführbare Dateien für Anwendungen auf, die kein SDK einbetten können. Das Node-Paket enthält native Laufzeitkomponenten und erfordert Node.js 24 oder neuer; für die native stdio-Übertragung unter Windows nennt das Repository Node 24.21.0 oder neuer beziehungsweise 26.8.0 oder neuer. Die öffentliche API wird aus @microsoft/mxc-sdk/v1 importiert, nicht aus dem Paketstamm. Auch das .NET-Paket enthält native Komponenten. Das Rust-Crate integriert SDK, Engine und ausgewählte Backends in die aufrufende Anwendung. Native ausführbare Dateien erfordern einen plattformspezifischen Build des Repositorys.

Wählen Sie das Backend, bevor Sie eine Richtlinie schreiben. Laut Repository ist processcontainer das Standard-Backend für Windows 11, bubblewrap das Standard-Backend für Linux und seatbelt das Standard-Backend für macOS. Windows bietet außerdem wslc und isolation_session; windows_sandbox, microvm und hyperlight sind als experimentell gekennzeichnet. Unter Linux ist die gewählte Laufzeitumgebung erforderlich, etwa Bubblewrap für das Standard-Backend. Die Windows-Versionsübersicht nennt die Mindest-Builds für ProcessContainer und IsolationSession. Prüfen Sie auf dem Rechner, der den Auftrag ausführt, ob der Host verfügbar ist und die angeforderte Richtlinie unterstützt.

Halten Sie den tatsächlichen Befehl, das Arbeitsverzeichnis, die zu lesenden und zu ändernden Dateien sowie benötigte Netzwerkziele fest. Behandeln Sie diese Angaben als Richtlinieneingaben der Anwendung oder des Betreibers. Microsoft zufolge liegt die Richtlinie außerhalb des Agenten-Workloads, sodass generierter Code seine eigenen Berechtigungen nicht erweitern kann. Die erwartete Befehlsausgabe umfasst stdout, stderr und den Exit-Status sowie mögliche Warnungen oder optionale SDK-Metadaten. Ein Aktivitätsbericht ist nur in dokumentierten Diagnosemodi auf unterstützten Windows-ProcessContainer-Hosts verfügbar.

Mit dem Node-SDK eine eng gefasste Richtlinie festlegen

Der Leitfaden für das Node-SDK dokumentiert dieses V1-Format. Installieren Sie das SDK in einer Anwendung, die eine unterstützte Node-Version verwendet:

Terminal
npm install @microsoft/mxc-sdk

Dieses Beispiel passt das „Run to Completion“-Beispiel von Microsoft an. Es fordert Lesezugriff auf das aktuelle Verzeichnis der Anwendung an und blockiert ausgehende Verbindungen. Der Befehl gibt lediglich eine Zeile aus und testet daher keine der beiden Einschränkungen. Das ist ein dokumentierter Ausgangspunkt, kein Test von BIG CHANGE. Ersetzen Sie Befehl und Pfade durch die Angaben des abzuschottenden Workloads; verwenden Sie readwritePaths nur für Verzeichnisse, die er ändern muss.

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 gibt erfasstes stdout und stderr, Exit-Code, Timeout-Status und Warnungen zurück. Ein blockierter Dateizugriff kann für den Workload wie ein gewöhnlicher Fehler „Zugriff verweigert“ aussehen. Ein erfolgreicher Abschluss beweist nicht, dass alle vorgesehenen Einschränkungen geprüft wurden. Um das Erfolgskriterium des Auftrags zu erfüllen, führen Sie auf dem gewählten unterstützten Backend einen vertrauenswürdigen Workload aus, der eine erlaubte Ressource nutzt, und testen Sie separat gezielt den Zugriff auf eine nicht freigegebene Ressource. Prüfen Sie das Ergebnis und die Diagnoseinformationen, bevor Sie die Richtlinie für agentengenerierte Befehle einsetzen. Die SDK-Beispiele behandeln Dateisystemberechtigungen, Netzwerksperren, Ausgabeerfassung und die Protokollierung abgelehnter Zugriffe. Dafür ist ein vorbereiteter Host erforderlich. BIG CHANGE hat keinen dieser Schritte ausgeführt.

Für Nutzer des nativen Executors ist das stabile JSON-Schema ist 1.0.0; eine vollständige Anfrage benötigt version, eine Auswahl der Abschottung und process.commandLine. Das aktuelle Entwicklungsschema lautet 1.1.0-alpha. Das V1-SDK wählt seinen Drahtvertrag selbst. Geben Sie daher im typisierten ContainerRequest keine Version des nativen Schemas an. Laut Schema-Leitfaden sind auch alte Felder wie network.defaultPolicy und allowedHosts außer Betrieb. Die aktuelle Richtlinie verwendet gerichtete network.egress und network.ingress; direkte Regeln und ein Laufzeit-Proxy unterscheiden sich in Verhalten und Backend-Unterstützung.

Ablehnungen diagnostizieren und dann die Richtlinie durchsetzen

Die Modusübersicht vom 7. Oktober von Microsoft unterscheidet drei Ergebnisse. Der Modus Enforcement blockiert nicht gewährten Zugriff und erstellt keinen Aktivitätsbericht. Der Modus Learning blockiert und protokolliert nicht gewährten Zugriff. Der Modus Permissive protokolliert Zugriffe, die von der Richtlinie abgelehnt würden, lässt sie aber zu. Die Referenz zur Erfassung abgelehnter Zugriffe von Microsoft beschränkt diese Learning-Funktionen auf Windows-ProcessContainer-Pfade auf AppContainer-Basis. Andere Hosts erhalten keine gleichwertigen Berichte, nur weil sie ein gemeinsames Richtlinienfeld akzeptieren.

Für ein vertrauenswürdiges Werkzeug während der Richtlinienerstellung unterstützt der native Windows-Executor einen --audit Ablauf, der Richtlinienartefakte erstellen kann. Microsoft warnt, dass dabei die Sandbox-Sicherheit für den analysierten Workload ausgeschaltet wird; für nicht vertrauenswürdige Befehle ist das ungeeignet. Wenn der Host es unterstützt, ist eine Erfassung mit Ablehnung und Protokollierung der sicherere Diagnoseweg: Der Zugriffsversuch bleibt blockiert, und der Bericht zeigt, was abgelehnt wurde. Prüfen Sie jeden protokollierten Pfad und jede Fähigkeit im Zusammenhang mit dem Auftrag, gewähren Sie nur die erforderlichen Rechte und führen Sie den endgültigen Workload im Enforcement-Modus aus. Berichte können sensible Ressourcennamen offenlegen; behandeln Sie sie entsprechend.

Die Wahl des Backends verändert, was die Richtlinie versprechen kann. Der Schema-Leitfaden besagt, dass isolation_session das Netzwerk nicht einschränken kann und eine ausdrücklich uneingeschränkte Netzwerkkonfiguration voraussetzt. Außerdem werden UI-Einschränkungen von Windows ProcessContainer und macOS Seatbelt durchgesetzt, von anderen Backends jedoch nicht implementiert; WSLC und IsolationSession lehnen eine übermittelte UI-Richtlinie ab. Der Seatbelt-Leitfaden erklärt, dass das native macOS-Profil keine einzelnen Remote-Hosts filtern kann. Der Bubblewrap-Leitfaden beschreibt die Laufzeit- und Netzwerkvoraussetzungen für Linux. Ein JSON-Feld, das von mehreren SDK-Typen angenommen wird, beweist daher keine gleichwertige Durchsetzung auf allen Plattformen. Prüfen Sie den Leitfaden des ausgewählten Backends und validieren Sie die Anfrage auf dem Zielhost.

Das Repository von Microsoft steht unter MIT-Lizenz; die Benutzerdokumentation nennt jedoch keinen Preis für das MXC-Paket. Kosten für Host, Rechenleistung und Modellanbieter fallen jeweils separat an. Die Windows-Ankündigung bezeichnet MXC als allgemein verfügbar, mehrere Backend-Optionen sind jedoch weiterhin experimentell und das native Entwicklungsschema ist noch Alpha. Berücksichtigen Sie diese Release-Stufen getrennt, wenn Sie den Ausführungsort eines Workloads festlegen.

Quellen und weiterführende Informationen

  • Microsoft Windows Developer Blog, 7. Oktober 2026belegt die Ankündigung, den vorgesehenen Einsatz mit Agenten und die Definitionen der drei Modi. Es handelt sich um die Produktbeschreibung von Microsoft, nicht um einen Sicherheitstest von BIG CHANGE.
  • README des MXC-Repositoryslistet SDKs, Host-Standards, experimentelle Backends, Build-Voraussetzungen und den Weg zum nativen Executor auf. Das Repository ändert sich; die Angaben wurden am 8. Oktober 2026 geprüft.
  • Benutzerleitfaden des Node-SDKnennt Node-Voraussetzungen, den V1-Import, die typisierte Anfrage und die erfasste Ausgabe. Der obige Code wurde aus dem Beispiel angepasst, hier aber nicht ausgeführt.
  • Leitfaden zum Konfigurationsschemaunterscheidet das stabile native JSON-Schema 1.0.0 vom veränderlichen 1.1.0-alpha und dokumentiert Richtlinienfelder sowie backend-spezifische Grenzen.
  • Referenz zu Learning-Modus und Erfassung abgelehnter Zugriffedokumentiert die Windows-ProcessContainer-Diagnose und warnt vor Audits im Permissive-Modus. Die Berichte hängen von Host und Modus ab.
  • Backend-Leitfäden und die Windows-Versionsübersicht helfen bei der Prüfung eines bestimmten Hosts; dieser Artikel zertifiziert keine Konfiguration auf dem Rechner der Lesenden.