Markdown-Ausgabe

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

# So legen Sie eine MXC-Richtlinie für agentengenerierte Befehle fest

> Mit dem MXC-SDK von Microsoft können Entwickler einen Befehl sowie seine Datei- und Netzwerkrichtlinie festlegen. Dieser ausschließlich auf Dokumentation beruhende Leitfaden zeigt den Konfigurationsweg für Node V1, Diagnosemodi und Grenzen der 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 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](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) beschreibt das Ziel der Abschottung; die [Benutzerdokumentation des Repositorys](https://github.com/microsoft/mxc) 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](https://github.com/microsoft/mxc) 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](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) 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](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) dokumentiert dieses V1-Format. Installieren Sie das SDK in einer Anwendung, die eine unterstützte Node-Version verwendet:

```bash
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](https://github.com/microsoft/mxc/blob/main/samples/README.md) 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](https://github.com/microsoft/mxc/blob/main/docs/schema.md) 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](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) 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](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) 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](https://github.com/microsoft/mxc/blob/main/docs/schema.md) 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](https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md) erklärt, dass das native macOS-Profil keine einzelnen Remote-Hosts filtern kann. Der [Bubblewrap-Leitfaden](https://github.com/microsoft/mxc/blob/main/docs/backends/bwrap/bubblewrap-backend.md) 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 2026](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/)belegt 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-Repositorys](https://github.com/microsoft/mxc)listet 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-SDK](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md)nennt 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 Konfigurationsschema](https://github.com/microsoft/mxc/blob/main/docs/schema.md)unterscheidet 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 Zugriffe](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md)dokumentiert die Windows-ProcessContainer-Diagnose und warnt vor Audits im Permissive-Modus. Die Berichte hängen von Host und Modus ab.
- [Backend-Leitfäden](https://github.com/microsoft/mxc/tree/main/docs/backends) und die [Windows-Versionsübersicht](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) helfen bei der Prüfung eines bestimmten Hosts; dieser Artikel zertifiziert keine Konfiguration auf dem Rechner der Lesenden.

## Sources

- [Einführung von Microsoft Execution Containers](https://blogs.windows.com/windowsdeveloper/2026/10/07/microsoft-execution-containers-policy-driven-containment-for-ai-agents/) — Ankündigung der allgemeinen Verfügbarkeit, Grenzen für Workloads und Ressourcen sowie Definitionen der drei Modi; Anbieteraussagen sind keine unabhängigen Tests.
- [README des MXC-Repositorys](https://github.com/microsoft/mxc) — SDKs, Host-Standards, Kennzeichnungen experimenteller Backends, Weg zum nativen Executor, Quelltextlizenz und Build-Voraussetzungen.
- [README des MXC-Node-SDK](https://github.com/microsoft/mxc/blob/main/sdk/node/README.md) — V1-Import, Mindestversion von Node, typisierte Anfrage, Laufzeitausgabe und Host-Erkennung. Das Beispiel wurde angepasst, aber nicht ausgeführt.
- [MXC-Schema-Leitfaden](https://github.com/microsoft/mxc/blob/main/docs/schema.md) — Verträge für stabiles natives JSON 1.0.0 und Entwicklung 1.1.0-alpha, Netzwerkrichtlinie sowie Backend- und UI-Grenzen.
- [MXC-Leitfaden zur Erfassung abgelehnter Zugriffe](https://github.com/microsoft/mxc/blob/main/docs/logging-access-denied.md) — Verhalten von Learning und Permissive in Windows ProcessContainer, Sicherheitswarnung zu --audit und Ausgabegrenzen.
- [MXC-SDK-Beispiele](https://github.com/microsoft/mxc/blob/main/samples/README.md) — Offizielles Verzeichnis für Beispiele zu Dateisystem, Netzwerk, Ausgabeerfassung und Erfassung abgelehnter Zugriffe.
- [MXC-Unterstützung für Windows-Versionen](https://github.com/microsoft/mxc/blob/main/docs/backends/process-container/os-version-support.md) — Mindest-Builds von Windows für ProcessContainer und IsolationSession.
- [MXC-Leitfaden zum Bubblewrap-Backend](https://github.com/microsoft/mxc/blob/main/docs/backends/bwrap/bubblewrap-backend.md) — Voraussetzungen des Linux-Standard-Backends und Netzwerkunterstützung.
- [MXC-Leitfaden zum Seatbelt-Backend](https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md) — Grenzen des nativen macOS-Profils und der Filterung entfernter Hosts.