Microsoft Execution Containers (MXC) sind ein bewusster Schritt in der Weiterentwicklung der Art und Weise, wie Betriebssysteme autonome KI-Agenten unterstützen. Statt Agenten mit Benutzerrechten laufen zu lassen oder sie vollständig zu blockieren, stellt MXC Entwicklern und IT-Teams eine vom Betriebssystem durchgesetzte Richtlinienebene bereit. Darin wird festgelegt, was ein Agent lesen, schreiben, aufrufen oder in der Benutzeroberfläche anzeigen darf. Dadurch können Agenten Workflows im Hintergrund ausführen – etwa ein Repository bearbeiten, einen Build starten oder Verwaltungsaufgaben automatisieren. Windows wählt dafür ein geeignetes Isolationsverfahren aus, beispielsweise eine Prozess-Sandbox, einen Sitzungskontainer, WSL oder eine MicroVM, und setzt die Grenzen zur Laufzeit durch.
Technisch gesehen trennen MXC Richtlinie und Ausführung voneinander. Entwickler verwenden ein einheitliches JSON-Schema und ein SDK für mehrere Programmiersprachen, um Ressourcenanforderungen wie Dateipfade, Netzwerkziele, UI-Zugriff und Prozessparameter festzulegen. MXC überführt diese Vorgaben in plattformspezifische Sandboxes für Windows, macOS und Linux. Diese Zuordnung ist entscheidend: Ein Coding-Agent kann mit geringer Latenz in einem Prozesscontainer laufen, während Workloads mit höherem Risiko in Sitzungskontainer oder MicroVMs verlagert werden. Die Richtlinie liegt außerhalb der Kontrolle des Agenten. So kann dieser weder seine Berechtigungen selbst erweitern noch Zugriff auf neu generierten Code freigeben.
MXC berücksichtigt außerdem, dass eine sichere Einführung von Agenten eine klare Identität und gute Verwaltbarkeit voraussetzt. Microsoft plant die Integration von Microsoft Entra und der Agent-365-Zuordnung, damit Administratoren Aktionen von Agenten eindeutig von Aktivitäten der Nutzer unterscheiden können. Zusammen mit Richtlinien für MXC-Container nach dem Vorbild von Intune erhalten Unternehmen die Möglichkeit, organisatorische Leitplanken durchzusetzen, das Verhalten von Agenten zu prüfen und auf einen fehlerhaft arbeitenden Agenten zu reagieren, ohne die Person am Gerät zu unterbrechen. Für Unternehmen macht dieser Unterschied aus, ob ein einzelner kompromittierter Agent oder ein vollständiger Sicherheitsvorfall mit einem Benutzerkonto vorliegt.
Für Entwickler ist die praktische Schlussfolgerung klar: MXC frühzeitig und schrittweise einführen. Beginnen Sie mit Prozesscontainern für entwicklernahe Agenten, bei denen schnelle Iterationen wichtig sind. Nutzen Sie die Modi „Permissive“ und „Learning“ von MXC, um Richtlinien nach dem Prinzip der geringsten Berechtigungen auszuarbeiten, und verlagern Sie sensible Pipelines anschließend in Sitzungskontainer oder MicroVMs, wenn eine stärkere Isolation erforderlich ist. Erfassen Sie bei Agenten-Workloads versuchte Zugriffe und passen Sie die Richtlinien schrittweise an. Betrachten Sie Meldungen zu blockierten Zugriffen als Diagnoseinformationen und nicht bloß als Fehler. Einheitliche Isolationsmodelle werden die Ausführung von Agenten langfristig ebenso vorhersehbar und nachvollziehbar machen, wie Container und Sandboxes es bei Cloud-Workloads ermöglicht haben.


