Agenten-Sandbox GA, Verwaltung nicht: Was Microsofts MXC wirklich durchsetzt

Am 7. Oktober 2026 hat Microsoft Windows Execution Containers (MXC) freigegeben, am selben Tag bekam das Projekt im Repo die Versionsnummer 1.0.0, der Tag liegt auf 05:54 UTC. Dazu kamen Geräte mit Nvidias RTX Spark, eine Vorführung lokal laufender Coding-Modelle und die Ansage, Windows solle die sicherste Plattform für Agenten werden.

Der für uns interessante Satz fiel im Repo: MXC liegt offen unter MIT-Lizenz, mit SDKs für Rust, .NET und Node, und der Standard-Backend unter Linux heißt Bubblewrap. Wir haben Repo, Backend-Doku, Entwicklerblog und GitHub-Doku gelesen und nachgezählt, was davon trägt.

Wie MXC eine Richtlinie durchsetzt

MXC ist eine Ausführungsschicht. Ein Programm übergibt Containertyp, Regeln und Befehl, MXC prüft, wählt den Backend und startet die Arbeit darin. Die Richtlinie liegt außerhalb des Agenten, ein Modell kann sie mitten in der Aufgabe nicht erweitern. Abgeschottet werden Dateien, Netzwerk, Prozesse und Oberfläche.

Nach der Übersicht im MXC-Repo, Stand 8. Oktober 2026. Experimentell markiert sind dort windows_sandbox, microvm und hyperlight, also die Abschirmungen, die eine zusätzliche Ebene zwischen Agent und Rechner legen.

Dazu kommen drei Modi. Der Lernmodus blockiert eine verweigerte Aktion und schreibt eine JSON-Aktivitätsdatei, der durchsetzende Modus blockiert ohne diesen Bericht, die Permissive-Stufe lässt durch und protokolliert nur.

Das Linux-Backend ist weiter als der Name

Die Dokumentation zu Bubblewrap trägt den Vermerk „Status: Stable, the default Linux backend". Nötig sind ein Kernel ab 3.8 mit User-Namensräumen und Bubblewrap ab 0.5.0, weil die Vorlage --ro-bind-try und die Umgebungsreinigung --clearenv braucht. Netzwerkabschirmung über Proxy oder Richtungsregeln verlangt zusätzlich slirp4netns, nsenter und ein iptables-Werkzeug mit nftables-Backend, dazu das Kernel-Modul nf_conntrack, das ein unprivilegierter Container nicht nachladen kann. Bei iptables-legacy lehnt die Prüfung validate ab, denn der unprivilegierte Helfer bekommt die Sperre /run/xtables.lock nicht gesetzt. IPv6 bleibt in diesen Modi unerreichbar, auch wenn eine Regel es erlaubte.

Was bei uns fehlt, haben wir auf dem Agent-Host nachgesehen statt vermutet.

Der Kernel ist vorbereitet, die Werkzeuge sind es nicht. Ein Testlauf braucht zwei Pakete und eine Richtlinie.

Was die Freigabe abdeckt und was nicht

Freigegeben sind Engine, Richtlinie und SDKs. Intune-Steuerung, die Trennung von Agenten- und Personenaktivität über Entra und die Agent-365-Steuerung für lokale Agenten bezeichnet Microsoft als kommend. Ein eigenständiger Agent läuft als eigener Windows-Account mit eigenem Desktop, eigener Zwischenablage und eigenem Speicherpfad, ohne Verknüpfung mit einer Verzeichniskennung. Mit Windows 365 for MXC läuft der Container wahlweise in einer Cloud-Sitzung.

Vier Punkte stehen in Microsofts eigenen Texten und gehören vor jeden Pilotversuch.

Der durchsetzende Modus liefert keine Aktivitätsberichte. Was ein Agent in einer produktiven Aufgabe gebraucht hätte, steht dann in keiner Aufstellung des Containers. Die Richtlinie muss aus einer Vorlaufphase kommen und dort archiviert werden.

Fähigkeiten, die ein Backend nicht bietet, fallen weg. Microsoft schreibt, dass der Container dann mit verringerter Abschottung laufen kann, und empfiehlt, die zurückgegebene wirksame Richtlinie zu prüfen. Eine geschriebene Richtlinie ist damit noch keine gültige Richtlinie, und diese Prüfung gehört an den Anfang einer Pilotbeschreibung.

Der Prüfschalter --audit schaltet nach der Warnung im Repo sämtliche Sandbox-Sicherheit für die untersuchte Arbeit aus. Ein Schalter, der vor dem Start die Abschottung löst, schützt im Ablauf nichts.

Die GitHub-Doku zu Copilot nennt zwei Grenzen. Die eingebauten Dateiwerkzeuge laufen innerhalb von Copilot selbst, dort prüft eine Prüfstelle im Prozess gegen die Richtlinie, eine Betriebssystemisolierung des Kindprozesses fehlt. Eingebundene MCP-Dienste liegen außerhalb des Containers. Als Vorgabe steht dort ein offener Internetzugriff bei geschlossenem lokalen Netz.

Die offenen Baustellen sind ein guter Maßstab für die Reife. Auf dem Linux-Zweig stehen ein Wettlauf beim Netzaufbau kurzlebiger Prozesse (1378) und ein fehlendes Standard-Verweigerungsprofil für seccomp (1443). Auf Windows scheitern MSYS2 und git-bash am Prozesscontainer (1061), im experimentellen MicroVM-Backend überstimmt blockedHosts die Richtlinie defaultPolicy=block (786). Geschlossen wurde am 7. Oktober ein Seatbelt-Leak, der auf gesperrten Pfaden über stat() Größe und Zeitstempel las.

Der Widerspruch seit Februar

Am 19. Februar 2026 beschrieben Microsofts Defender Security Researcher selbst betriebene Agent-Laufzeiten am Beispiel von OpenClaw. Das Zitat dort: OpenClaw sei „not appropriate to run on a standard personal or enterprise workstation". Wer es prüfen müsse, brauche eine vollständig isolierte Umgebung, eigene virtuelle Maschine, eigene unprivilegierte Anmeldedaten, Überwachung und Neuaufbauplan. Davor steht dort der Satz, dass ein Skill zu installieren im Wesentlichen privilegierten Code installiert.

Am 7. Oktober 2026 steht OpenClaw auf der Liste der Agenten, die MXC bereits nutzen, neben GitHub Copilot, OpenAI Codex, Replit, LM Studio und Unsloth. Beide Texte sind von Microsoft.

Aufgelöst wird der Widerspruch über die Backendatenbank. Ein Prozesscontainer ist ein abschirmender Prozess, keine Maschine. Er verkleinert Dateiraum, Netzraum und Oberfläche, während die Anmeldedaten des Agenten und die Zulaufstraße für Skills unberührt bleiben. MXC begrenzt den Schaden und ersetzt die Isolation aus dem Februar nicht.

Lokale Modelle sind keine offene Rechnung

Die Hardware-Seite heißt Surface Laptop Ultra mit RTX Spark, vorbestellbar seit 7. Oktober, ausgeliefert ab 16. Oktober. Für die lokale Coding-Stufe nennt Microsoft ein eigenes Modell, MAI Code 1.1 Flash, ein Mixture-of-Experts-Modell mit 137 Milliarden Gesamtparametern und 6,8 Milliarden aktiven. Die Fassung für Geräte kommt mit gemischter Quantisierung von rund 3,3 Bit je Gewicht, das sind 53 GB und eine Verkleinerung um 80 Prozent, dazu spekulative Dekodierung und Ausführung über die llama.cpp-Laufzeitumgebung.

Diese Zahlen stehen im Microsoft-Beitrag vom 7. Oktober 2026, gemessen hat sie der Hersteller selbst. Auf Terminal-Bench liegt die quantisierte Fassung über der unquantisierten, eine Erklärung fehlt im Text, und der Vergleich läuft gegen eine Community-Kopie von GPT OSS mit 80-Prozent-Quantisierung. Die Fußnote zu den Durchsatzwerten nennt 923,5 und 769,8 Token pro Sekunde bei 64K und 128K Kontext für die Vorverarbeitung der Eingabe, beschreibt dieselben Ergebnisse aber als Durchsatz der Ausgabe. Diese Zahl bekommt man nur mit Vorbehalt.

Unsere eigene Rechnung dazu, mit Nvidias veröffentlichter Bandbreite von 273 GB/s für DGX Spark mit GB10; die des RTX Spark N1X ist nicht veröffentlicht. Ein Modell mit 53 GB Gewichten, das pro Ausgabetoken alle Gewichte läse, käme auf gut fünf Token pro Sekunde. Bei 6,8 Milliarden aktiven Parametern und 3,3 Bit sind es rund 2,5 GB je Token, also eine Obergrenze um hundert Token pro Sekunde, vor allen Verlusten. „Frontier lokal" heißt hier: ein Mixture-of-Experts-Modell mit wenigen aktiven Parametern plus ein gemeinsamer Speicherpool. Das schnelle Notebook allein erklärt die Zahl nicht. Bei 256K Kontext beziffert Microsoft den Höhepunkt des Speichers auf 75,5 GB, davon bis zu 22 GB Schlüssel-Wertecache.

Bei den offenen Gewichten hat die Vorführung mehr gezeigt, als die Lizenzliste hergibt. DeepSeek V4 Flash liegt auf Hugging Face unter deepseek-ai/DeepSeek-V4-Flash, Lizenz MIT, rund 996.000 Abrufe. Die Konfiguration listet 43 Schichten, 256 Expertennetzwerke mit 6 aktiven je Token und FP8-Gewichte, also ist jede 2-Bit-Stufe eine weitere Quantisierung durch Dritte. Die auf der Bühne gezeigte 1,6-Bit-Stufe stammt aus der Nachbesprechung der Vorführung, im Blogeintrag steht sie nicht. Microsofts eigenes MAI-Modell fehlt dort, die Organisation microsoft listet nur maira-2 und MAI-DS-R1; diese Gewichte kommen mit dem Produkt. Nvidias Modell über 70 Milliarden Parameter in 2 Bit bleibt ohne Namen. Auch die Vergleichszahlen zum Mac stammen laut Anmerkung des Beitrags aus einem Auftragstest im September 2026 auf Vorseriengeräten, mit einem einzigen Textmodell und einem Vier-Schritt-Durchlauf bei Bildern.

Der Build entscheidet, nicht die Produktversion

MXC läuft nicht auf jedem Windows 11. Die Repo-Dokumentation schreibt Mindeststände je Release fest, und die Tabelle zeigt, dass zwei kumulative Updates nötig sein können, weil Sitzungsisolierung eine höhere Build-Nummer verlangt.

Nach der Übersichtsseite im MXC-Repo, Stand 8. Oktober 2026. Für Windows verlangt die GitHub-Doku zu Copilot 25H2 mit KB5124010 oder später, alternativ 26H1 mit KB5124006, und für Linux Bubblewrap ab 0.5.0 mit slirp4netns.

In unserer Inventur standen am 7. Oktober 2026 sechs Gastsysteme mit Windows-11-Kennzeichen und fünfzehn laufende Windows-Server-Gäste, darunter zwei Domänencontroller, vier Terminalserver, zwei ERP-Systeme und die MailStore-Instanz. Gezählt haben wir über die Proxmox-API, im Homelab läuft kein Windows-Gast. Die Kennzeichen sind unsere Klassifizierung, die kumulativen Updates der sechs Geräte sind noch ablesbar und noch nicht abgelesen.

Was wir daraus mitnehmen

Zuerst die wirksame Richtlinie lesen. Microsoft sagt selbst, dass nicht unterstützte Fähigkeiten wegfallen. Ein Testlauf, der die zurückgegebene Richtlinie nicht auswertet, belegt nur, dass ein Container gestartet ist.

Vor der Durchsetzung kommt der Lernbericht. Der Lernmodus schreibt eine JSON-Aufstellung aller erlaubten und verweigerten Vorgänge. Diese Datei ist der ehrlichste Weg zu einer passenden Richtlinie und die einzige, die sich archivieren lässt, solange der Durchsetzungsmodus nichts aufschreibt.

Auf eigenen Linux-Hosts lässt sich derselbe Mechanismus ohne Windows prüfen: zwei Pakete, eine Richtlinie mit Verweigerungsstandard für ausgehende Verbindungen, ein Blick auf nf_conntrack. Aufgebaut haben wir das am 7. Oktober nicht, der Stand ist trotzdem sichtbar: Kernel bereit, Pakete fehlen.

Bei der Identität bleibt die eigene Arbeit. Microsoft liefert die Trennung von Agent und Person über Entra noch nicht, wir führen Agenten heute über Dienstzugänge am LiteLLM-Gateway. Ein Agent mit unseren Anmeldedaten bleibt unser Risiko, wie dicht sein Container auch ist.

In Windows-Umgebungen zuerst messen, dann genehmigen: Build-Stände ablesen, Pilot im Lernmodus auf einem Gerät, Flächenfreigabe halten, bis Intune-Steuerung und Bericht im Durchsetzungsmodus da sind. Für die sechs Geräte unserer Inventur ist das eine Stunde Arbeit.

Offen bleibt die Reihenfolge. Wer Agenten über eine Verzeichniskennung anmeldet, braucht einen Verzeichnisdienst, und den führen wir für Menschen. Ein Agent mit eigenem Konto und eigenen Rechten ist eine Identitätsentscheidung, keine Containerfrage.

Weiterführende Quellen

• Windows Developer Blog: Microsoft Execution Containers, Policy-driven containment for AI agents (7. Oktober 2026)
• MXC-Repo auf GitHub, MIT-Lizenz, v1.0.0
• Bubblewrap-Backend im MXC-Repo
• Unterstützte Windows-Stände je Release im MXC-Repo
• Windows Experience Blog: Building Windows for hybrid intelligence
• Command Line: Bringing local models and sandboxed tools to Windows and GitHub Copilot (7. Oktober 2026)
• GitHub Docs: Using local sandboxing
• Microsoft Security Blog: Running OpenClaw safely, identity, isolation and runtime risk (19. Februar 2026)
• Nvidia DGX Spark User Guide, Hardware-Übersicht mit 273 GB/s
• Hugging Face: deepseek-ai/DeepSeek-V4-Flash
• heise online: Microsoft stellt Agentic Windows Desktop und neue Hardware vor
• Claude Mods: Was das neue Plugin-Format in Claude Code wirklich darf
• Coding-Agenten unter Windows im Praxistest
• Lokale KI im Selbstversuch: Eine Woche ohne Cloud-Modelle
• Agentic Coding: Wie KI-Agenten den Dev-Alltag verändern