Windows 365 for Agents macht den Cloud PC zur Agent-Runtime: Was CTOs vor dem Roll-out festschreiben sollten

Microsoft hat KI-Agents soeben einen vollständigen Windows-Desktop übergeben. Das ist kein Feature-Update. Es ist eine neue Klasse von Enterprise-Angriffsfläche, und die Governance-Uhr läuft bereits.

Am 28. Mai 2026 öffnete Microsoft die öffentliche Vorschau von Windows 365 for Agents in den USA. Dabei handelt es sich um eine speziell entwickelte agentische Cloud-PC-Runtime, mit der KI-Agents in einer verwalteten Windows-Umgebung arbeiten können. Wie Help Net Security berichtete, ist das eine eigenständige Produktlinie, die sich vom menschlichen Windows 365 Cloud PC unterscheidet und speziell für nicht-menschliche Nutzer entwickelt wurde. Es ist die dritte Runtime in einer Enterprise-Agent-Architektur, die viele CTOs noch nicht vollständig entworfen haben.

Was Microsoft tatsächlich geliefert hat

Das Kernstück dieser Veröffentlichung ist ein neues Infrastrukturmodell, das Microsoft „hosted on behalf of" nennt, abgekürzt HOBO. Unter der HOBO-Architektur erhält jeder Agent seine eigene Single-Instance-Azure-VM. Diese VM läuft im Azure-Abonnement von Microsoft, wird aber durch die Microsoft Intune (Mobile Device Management) Richtlinien des Kunden gesteuert und über Microsoft Entra ID (die früher als Azure Active Directory bekannte Enterprise-Identitätsplattform) abgesichert.

Ihr IT-Team konfiguriert und prüft die Maschine; Microsoft übernimmt das Hosting. Die Microsoft Learn-Dokumentation zu Windows 365 for Agents erläutert das technische Modell, einschließlich der in der Vorschau unterstützten Agent-Typen.

Die Lizenzierung erfordert drei Dinge: die neue Agent 365-Lizenz für 15 USD pro Nutzer und Monat, ein bestehendes Intune-Abonnement und ein aktives Azure-Abonnement. Das ist kein eigenständiger Kauf, sondern setzt voraus, dass Sie bereits den Enterprise-Management-Stack von Microsoft betreiben.

Was der Agent erhält, ist ein vollständiger Windows-Desktop, kein API-Endpunkt, keine sandboxed Shell. Eine Taskleiste, Browser, Dateisystem und die Möglichkeit, durch Anwendungsoberflächen zu klicken. Das ist der Sinn. Und das ist auch das Risiko.

Die drei Runtimes sind jetzt sichtbar

Wenn Sie die Rework-Berichterstattung zum Microsoft-Agent-Stack dieser Woche verfolgt haben, kennen Sie bereits zwei der drei Runtimes. Microsoft Agent 365 hat die Control Plane etabliert, eine Governance-Schicht zur Registrierung von KI-Agents als identifizierbare Assets. Anthropics self-hosted Sandboxes repräsentieren das Perimeter-Modell: code-first, API-orientierte Agent-Ausführung innerhalb Ihrer eigenen Firewall.

Windows 365 for Agents ist das dritte Element. Nennen wir das die Three Runtimes Lens, ein Framework zur Erfassung, wo ein KI-Agent lebt, worauf er zugreifen kann und welche Kontrollen gelten:

Die Three Runtimes Lens ist wichtig, weil die meisten Enterprise-Agent-Strategien in eine einzige Frage kollabieren: „Sollen wir KI-Agents einsetzen?" Die eigentliche Frage lautet: „Welche Runtime passt zu diesem Workflow, und welche Sicherheitsvorkehrungen gehören zu jeder?"

Jede Runtime erhöht die Sicherheits- und Governance-Anforderungen um eine Stufe. Ein Control-Plane-Agent, der eine API aufruft, ist durch den API-Scope begrenzt. Eine API-first-Sandbox, die Code ausführt, ist durch den Netzwerkperimeter begrenzt. Ein UI-gesteuerter Cloud-PC-Agent kann fast alles tun, was ein menschlicher Mitarbeiter mit dieser Windows-Sitzung tun könnte. Das ist ein wesentlich anderes Risikoprofil.

Wo die UI-gesteuerte Runtime ihren Wert beweist

Der Fall für Windows 365 for Agents ist dort am stärksten, wo ein menschlicher Mitarbeiter heute durch Bildschirme klickt, um Arbeit zu erledigen, die ein gut konzipierter Agent konsistenter erledigen könnte. Einige konkrete Kategorien:

Legacy-ERP-Systeme. SAP GUI und Oracle Forms wurden für Menschen entwickelt, nicht für APIs. Viele Unternehmen haben SAP ECC-Installationen, bei denen die REST-API-Oberfläche dünn oder nicht vorhanden ist. Ein Agent mit einer Windows-Sitzung navigiert durch diese Bildschirme und liefert Ergebnisse, ohne ein mehrjähriges API-Modernisierungsprojekt zu erfordern.

Citrix- und RDP-gehostete Anwendungen. Ein erheblicher Anteil der Enterprise-Software in regulierten Branchen läuft in Citrix- oder Remote Desktop Protocol-Sitzungen. Die Automatisierung dieser Umgebungen erforderte bisher teure Citrix-spezifische Tooling. Ein agentischer Cloud PC verändert diese Kalkulation.

AS/400- und Terminal-Emulator-Workflows. IBM-AS/400-Systeme und 5250-Terminal-Emulatoren steuern bei Tausenden von Unternehmen noch immer Kerngeschäftslogik. Agents, die einen Terminal-Emulator bedienen können, automatisieren Beschaffungs-, Bestands- und Produktionsworkflows, die andernfalls individuelle Middleware erfordern würden.

Drittanbieter-SaaS ohne APIs. Manche SaaS-Tools bieten keinen API-Zugriff für das Tier, das die meisten Kunden kaufen. Ein UI-gesteuerter Agent übernimmt diese Fälle, ohne ein Tier-Upgrade oder eine Anbieterverhandlung zu erfordern.

Das Windows-365-Blog beschrieb diese Richtung bereits im Januar 2026 und stellte das nächste Kapitel des Cloud PC als Erweiterung der Plattform auf nicht-menschliche Nutzer dar. Der Launch vom 28. Mai machte das praktisch.

Wo es Risiken einführt, die Sie vorher nicht hatten

Wichtigste Fakten

• Windows 365 for Agents ging am 28. Mai 2026 in die öffentliche Vorschau, zum Preis von 15 USD/Nutzer/Monat für die Agent 365-Lizenz (Quelle: Help Net Security)
• Die HOBO-Architektur platziert VMs im Azure-Abonnement von Microsoft, verwaltet über das Intune des Kunden. Die Windows-Sitzung des Agents hat denselben OS-Level-Zugriff wie ein menschlicher Cloud-PC-Nutzer (Quelle: Microsoft Learn)
• Gartner prognostizierte, dass 40 % der Enterprise-Anwendungen bis 2026 eingebettete KI-Agents enthalten werden, was die Angriffsfläche UI-gesteuerter Automatisierung erheblich vergrößert (Quelle: Gartner, 2025)

Ein vollständiger Windows-Desktop ist eine deutlich größere potenzielle Schadenszone als ein API-Aufruf. Das ist der Kompromiss, den CTOs explizit benennen müssen, bevor sie das einführen.

Größere Oberfläche als jeder API-Scope. Ein Agent, der jede Anwendung in seiner Windows-Sitzung starten kann, kann alles erreichen, worauf die Berechtigungen dieser Benutzeridentität zugreifen. Wenn diese Entra-ID-Berechtigungen überprovisioniert sind, ein in reifen Unternehmen häufiger Zustand, erbt der Agent diese Überprovisionierung.

Prüfbarkeit ist schwieriger als API-Protokolle. API-first-Agents erzeugen diskrete, strukturierte Prüfprotokolle. Ein UI-gesteuerter Agent, der durch einen Bildschirm navigiert, erzeugt Sitzungsaufzeichnungen nur, wenn Sie diese konfiguriert haben. Das Rekonstruieren einer Entscheidungsabfolge aus Bildschirmaufnahmen erfordert mehr Aufwand als das Parsen eines API-Protokolls. Sie benötigen explizite Sitzungsaufzeichnungsrichtlinien in Intune, bevor Sie dem in einem Produktionsworkflow vertrauen.

Intune-Konfigurationsdrift. Das HOBO-Modell macht Intune-Richtlinien zur primären Sicherheitsvorkehrung. Wenn diese Richtlinien driften, veraltete Baselines, nicht überprüfte Ausnahmen, falsch konfigurierter bedingter Zugriff, spiegelt die Windows-Sitzung des Agents diesen Drift wider. Eine Windows-Sitzung, die Ihren Intune-Stand erbt, erbt auch Ihre Intune-Altlasten.

Lizenzausbreitung. Agent 365 für 15 USD/Nutzer/Monat kommt zu Intune und Azure hinzu. Ohne Ausgaben-Governance werden Agent-Lizenzen schnell zu einem großen, undurchsichtigen Posten ohne klare Wertezuordnung.

Jedes dieser Risiken ist handhabbar. Aber alle erfordern bewusste Richtlinienentscheidungen, bevor der erste Agent in Betrieb geht, nicht danach. Der richtige Ausgangspunkt ist das agentische KI-Governance-Modell, denn die Governance-Lücke verschwindet nicht, weil Sie eine neue Runtime hinzugefügt haben.

Die CTO-Aktionsliste für die nächsten 60 Tage

Die Einführung von Windows 365 for Agents ohne Grenzrichtlinie schafft eine neue Klasse nicht verwalteter Assets in Ihrer Umgebung. Was zu tun ist, bevor die Vorschau zur Produktion wird:

1. Prüfen Sie zuerst UI-gebundene Workflows. Erfassen Sie jeden Workflow, bei dem ein Mensch durch Bildschirme klickt, weil es keine API-Alternative gibt. Das ist Ihre Kandidatenliste und Ihr Risikoregister. Jeder Workflow, der zu einem agentischen Cloud PC wechselt, braucht eine eigene Risikoeinstufung.

2. Testen Sie EINEN Agent mit read-only-Bereich. Beginnen Sie nicht mit schreibfähigen Agents. Wählen Sie einen Workflow, bei dem der Agent Daten liest und meldet, ohne den Zustand zu ändern. Das liefert Ihnen Sitzungsaufzeichnungsdaten, Intune-Richtlinienvalidierung und eine Notfallübung.

3. Schreiben Sie die Grenzrichtlinie, bevor Sie skalieren. Legen Sie fest, welche Intune-Richtlinien für Agent-Cloud-PCs gelten, welche Anwendungskategorien gesperrt sind, auf welche Datenklassifizierungen der Agent zugreifen darf und was eine automatische Sitzungsbeendigung auslöst. Machen Sie daraus ein benanntes Dokument, das Ihr Sicherheitsteam genehmigt.

4. Setzen Sie Ausgabengrenzen pro Workflow. Agent 365 für 15 USD/Nutzer/Monat wächst schnell. Weisen Sie jeder Runtime ein Budget zu, das an den Workflow gebunden ist, den sie automatisiert, mit einem benannten Eigentümer, der Erhöhungen genehmigt.

5. Definieren Sie eine Deaktivierungsregel bei Missbrauch. Was muss der Agent tun, oder unterlassen, damit eine Sitzungssuspendierung ausgelöst wird? Definieren Sie das im Voraus, automatisieren Sie es über Intune-Compliance-Richtlinien und lassen Sie keine Diskussionen nach einem Vorfall zu.

6. Entscheiden Sie, wer die Cloud-PC-als-Runtime-Taxonomie besitzt. Ist ein Agent-Cloud-PC ein Sicherheits-Asset, ein IT-Asset oder ein Engineering-Asset? Bleibt das undefiniert, werden drei Teams aufeinander zeigen, wenn etwas schiefgeht.

FAQ

Ist Windows 365 for Agents allgemein verfügbar?

Nein. Stand 28. Mai 2026 befindet es sich in der öffentlichen Vorschau in den USA. Ein GA-Termin wurde nicht angekündigt. Behandeln Sie den aktuellen Zustand als reine Pilotumgebung, nutzen Sie ihn, um Governance-Modelle zu testen, nicht um Produktionsworkloads zu betreiben.

Ersetzt Windows 365 for Agents Microsoft Agent 365?

Nein. Die beiden Produkte befinden sich auf unterschiedlichen Schichten. Agent 365 ist die Control Plane, die Identität, Berechtigungen und Prüfprotokolle für alle Agents in Ihrem Tenant steuert. Windows 365 for Agents ist eine Runtime, die einem Agent einen Betriebsort gibt. Sie benötigen beides. Eine Runtime ohne Governance ist eine nicht verwaltete Agent-Sitzung.

Wie verhält es sich im Vergleich zu Anthropics self-hosted Sandboxes?

Unterschiedliche Anwendungsfälle. Anthropics self-hosted Sandboxes und MCP Tunnels sind für Code-Tool-Agents optimiert, die APIs aufrufen und Daten innerhalb Ihrer eigenen Firewall verarbeiten. Windows 365 for Agents übernimmt UI-gesteuerte Workflows, bei denen das Zielsystem keine API hat. Wenn der Agent eine API aufrufen muss, nutzen Sie eine sandboxed Runtime. Wenn er durch einen Bildschirm klicken muss, nutzen Sie Windows 365 for Agents.

Weiterlesen

• Microsoft Agent 365 ist live: Warum jeder CTO jetzt eine KI-Agent-Control Plane braucht
• Anthropic hat KI-Agents hinter Ihre Firewall gebracht: Was Self-Hosted Sandboxes und MCP Tunnels für CTOs bedeuten
• 86 % der CEOs erhöhen KI-Budgets, aber nur 1 von 5 hat die Governance dafür
• Das ACE Framework: Eine periodische Tabelle für Business AI

Das öffentliche Vorschaufenster ist Ihr Planungsfenster. Jede jetzt aufgeschobene Governance-Entscheidung wird nach dem ersten Vorfall zur Nachrüstung. Beginnen Sie mit der Grenzrichtlinie, wählen Sie einen read-only-Piloten und lassen Sie die Three Runtimes Lens bestimmen, wo Windows 365 for Agents seinen Platz hat und wo nicht.