Microsoft: OpenClaw nicht auf normalen Arbeitsrechnern ausführen

Am 19. Februar 2026 veröffentlichte das Microsoft Defender Security Research Team einen Beitrag mit dem Titel „OpenClaw sicher ausführen: Identität, Isolation und Laufzeitrisiko“ und sprach darin eine Empfehlung aus, die das Orca AI Incident Archive bei keinem anderen Eintrag verzeichnet: OpenClaw „sollte als nicht vertrauenswürdige Codeausführung mit persistenten Anmeldeinformationen behandelt werden“ und „Es ist nicht angemessen, sie auf einem Standard-Personal- oder Unternehmensarbeitsplatz auszuführen.“ OpenClaw ist eine selbstgehostete Agenten-Laufzeitumgebung – Benutzer installieren sie auf ihrem eigenen Rechner, gewähren ihr Konten und Tokens und lassen sie Skills aus einer öffentlichen Registry installieren und auf Text reagieren, den sie von überall liest. Microsofts Argumentation ist architektonisch, kein Fehlerbericht: Die Laufzeitumgebung verlagert den Ausführungspunkt von statischem Anwendungscode auf Inhalte, die zur Laufzeit bereitgestellt werden, und die Kontrollen für Identität, Eingabebehandlung und Berechtigungen wurden nicht mit angepasst. Der Beitrag nennt weder eine CVE noch eine Kampagne oder ein Opfer und verzeichnet keine Kompromittierung. Der vollständige Eintrag befindet sich im Orca AI Incident Archive, wo er als wegweisender Policy-Eintrag mit Konfidenzgrad A und ohne dokumentierten realen Schaden eingestuft ist.

Was in dem Beitrag stand – und was nicht.

Der Beitrag umfasst etwa zwölf Minuten Lesezeit und enthält keinerlei Offenlegungsmechanismen: keine CVE-Kennung, keinen Bereich betroffener Versionen, keinen festen Build, keinen Indikator für eine Kompromittierung, der an eine reale Bereitstellung gebunden ist. Microsoft Defender Security Research nennt Idan Hen als Mitwirkenden. Was er stattdessen enthält, ist ein Bedrohungsmodell und eine Bereitstellungsregel, weshalb das Archiv ihn als Richtlinieneintrag statt als Vorfall ablegt – Schweregradinformationen, Konfidenzgrad A, kein dokumentierter realer Schaden, ein einzelnes Datum mit Tagesgenauigkeit.

Die Begründung ist in einem einzigen einleitenden Absatz zusammengefasst. OpenClaw „enthält nur begrenzte integrierte Sicherheitskontrollen“, schreibt das Team, weil die Laufzeitumgebung „nicht vertrauenswürdigen Text aufnehmen, Skills (d. h. Code) aus externen Quellen herunterladen und ausführen sowie Aktionen mit den ihr zugewiesenen Anmeldedaten durchführen kann“. Die Konsequenz wird im selben Atemzug genannt: Dies „verschiebt die Ausführungsgrenze effektiv vom statischen Anwendungscode hin zu dynamisch bereitgestellten Inhalten und Fähigkeiten von Drittanbietern, ohne gleichwertige Kontrollen in Bezug auf Identität, Eingabeverarbeitung oder Berechtigungsabgrenzung“.

Es folgen drei Risiken, und es lohnt sich, sie in Microsofts eigenen Worten zu lesen, weil der Großteil der anschließenden Berichterstattung sie zu vagen Aussagen umformuliert hat:

• "Zugangsdaten und zugängliche Daten können offengelegt oder exfiltriert werden."

• „Der persistente Zustand bzw. das ‚Gedächtnis‘ des Agenten kann verändert werden, wodurch er im Laufe der Zeit vom Angreifer vorgegebenen Anweisungen folgt.“

• „Die Host-Umgebung kann kompromittiert werden, wenn der Agent dazu verleitet wird, bösartigen Code abzurufen und auszuführen.“

Beachten Sie, was in dieser Liste fehlt. Es gibt keine ausgenutzte Schwachstelle, keine anfällige Funktion, keinen Patch, der ausgeliefert werden müsste. Microsoft sagt nicht, dass OpenClaw einen Sicherheitsfehler hat; es sagt, dass ein Programm, das zur Laufzeit anhand von Text, den es abgerufen hat, und mit Anmeldedaten, die ihm übergeben wurden, entscheidet, was zu tun ist, auf einem Rechner, auf dem sich auch die eigentliche Arbeit des Betreibers befindet, durch Konfiguration nicht sicher gemacht werden kann. Die daraus folgende Empfehlung ist entsprechend deutlich — für die meisten Umgebungen „kann die angemessene Entscheidung darin bestehen, es nicht einzusetzen.“

Zwei Lieferketten, eine Ausführungsschleife

Der Mechanismus, den der Beitrag beschreibt, ist die Konvergenz dessen, was er die beiden Lieferketten eines selbst gehosteten Agenten nennt: nicht vertrauenswürdiger Code, also Skills und Erweiterungen, und nicht vertrauenswürdige Anweisungen, also externer Text. Die meiste Software hat das eine oder das andere. Ein Paketmanager lädt nicht vertrauenswürdigen Code, liest aber nicht im Internet und entscheidet nicht, was als Nächstes ausgeführt wird; ein Chatmodell liest nicht vertrauenswürdigen Text, kann aber nichts installieren. OpenClaw macht beides in einer einzigen Schleife, und die Schleife läuft unter der eigenen Identität des Nutzers.

„Einen Skill zu installieren bedeutet im Grunde, privilegierten Code zu installieren“, heißt es in dem Beitrag. Skills würden „häufig über ClawHub entdeckt und installiert, die öffentliche Skill-Registry für OpenClaw“, und in permissiven Bereitstellungen „darf die Runtime den Installationsablauf möglicherweise ohne menschliche Genehmigung ausführen“. Die zweite Lieferkette wird von Moltbook abgewickelt, das der Beitrag als agentenorientierte Plattform und Identitätsschicht beschreibt, in der Agenten über APIs posten, lesen und sich authentifizieren – und damit, so die Formulierung, „einen hochvolumigen Strom von Angreifern beeinflussbarer Inhalte, den Agenten nach Zeitplan aufnehmen“. Die Verdichtung ist der Punkt: „Ein einzelner bösartiger Beitrag kann daher mehrere Agenten erreichen.“

Der Beitrag unterteilt die Vertrauensgrenze dann in drei Komponenten, was der am besten wiederverwendbare Teil des gesamten Dokuments ist: Identität, also die Tokens, die der Agent verwendet, um über SaaS-APIs, Repositories, E-Mail und Cloud-Control-Planes hinweg zu arbeiten; Ausführung, also die Tools, die er ausführen kann, um Zustand zu ändern, einschließlich Dateien, Shell, Infrastruktur und Nachrichten; und Persistenz, also die Möglichkeiten, mit denen er Änderungen über Läufe hinweg beibehalten kann, durch Aufgaben, Konfiguration und Zeitpläne. Ein Agent, der alle drei besitzt, ist keine Anwendung mit einer Berechtigungsaufforderung. Er ist ein Principal.

Die vergiftete Fähigkeit in fünf Stufen

Microsoft liefert eine ausgearbeitete Kompromittierungskette, die als repräsentatives Szenario und nicht als Fallbericht gekennzeichnet ist, und es lohnt sich, sie durchzugehen, denn ihre letzten beiden Schritte sind diejenigen, die gewöhnliche Endpoint-Abwehr aushebeln. Der Beitrag leitet sie mit einer Behauptung über die Außenwelt ein – „Öffentliche Berichte haben dokumentiert, dass bösartige Skills in öffentlichen Registries auftauchen“, und in manchen Fällen „seien Registry-Inhalte schlicht als Skill verpackte Malware gewesen statt eines subtilen Lookalikes“ –, nennt aber keinen Registry-Eintrag, keine Kampagne, keinen Akteur und kein Opfer; daher ist die Kette ein Plausibilitätsargument, keine Rekonstruktion.

• Verbreitung. Ein Angreifer veröffentlicht einen bösartigen Skill auf ClawHub, der manchmal als nützliches Tool getarnt und manchmal offen bösartig ist, und bewirbt ihn über Community-Kanäle; in anderen Fällen wird er organisch über die Suche gefunden und installiert, weil die Installation mit geringem Aufwand verbunden ist.

• Installation. Ein Entwickler oder der Agent selbst startet die Installation, weil die Fähigkeit für die Aufgabe relevant erscheint. In einer permissiven Bereitstellung genehmigt kein Mensch sie.

• Zugriff auf den Zustand. Der Angreifer hat es auf Tokens, zwischengespeicherte Anmeldeinformationen, Konfigurationsdaten und Transkripte abgesehen, außerdem auf die dauerhaften Instruktionskanäle – Aufgabendateien, geplante Aktionen, Agentenkonfiguration –, die künftige Ausführungen steuern.

• Wiederverwendung von Berechtigungen. Mit gültigem Identitätsmaterial agiert der Angreifer über Standard-APIs und -Tools, und die Aktivität „wirkt oft wie legitime Automatisierung, es sei denn, es sind starke Überwachungs- und Protokollierungskontrollen vorhanden.“

• Persistenz durch Konfiguration. Was bleibt, ist eine dauerhafte Konfigurationsänderung: „neue OAuth-Zustimmungen, geplante Ausführungen, geänderte Agent-Aufgaben oder Tools, die dauerhaft genehmigt bleiben.“

Der fünfte Schritt enthält den schärfsten Satz des Beitrags und denjenigen, der am besten erklärt, warum dies ein Richtlinienproblem und kein Malware-Problem ist: „Das Ziel besteht weniger darin, Malware einzusetzen, als vielmehr darin, langfristige Kontrolle über den Automatisierungspfad zu behalten.“ Sicherheitstools, die nach einer Nutzlast suchen, werden nichts finden. Was sie erkennen müssten, ist eine Zustimmungserteilung, ein Cron-Eintrag oder ein Tool, das stillschweigend genehmigt zurückgelassen wurde.

Die Mindesthaltung, die Microsoft akzeptieren wird

Microsoft lässt die Leserschaft nicht mit einem bloßen „Don’t“ zurück. Es liefert eine Mindestvorgabe für Organisationen, die die Laufzeitumgebung trotzdem bewerten wollen, und diese Mindestvorgabe ist strenger als eine Sandbox. Die Umgebung sollte „eine dedizierte virtuelle Maschine oder ein separates physisches Gerät sein, das nicht für die tägliche Arbeit verwendet wird“, und sie sollte als wegwerfbar behandelt werden. Anmeldeinformationen sollten ausschließlich für den Zweck des Agenten erstellt werden, nicht privilegiert sein und unter der Annahme rotiert werden, dass sie bereits kompromittiert sind. Es sollten nur nicht sensible Daten erreichbar sein. Die gespeicherten Anweisungen und der gespeicherte Zustand des Agenten sollten regelmäßig auf unerwartete dauerhafte Regeln, neu als vertrauenswürdig eingestufte Quellen oder Verhalten, das sich zwischen Ausführungen ändert, überprüft werden. Und ein Neuaufbau sollte eine erwartete Kontrollmaßnahme statt eines Notfalls sein: regelmäßig neu installieren und bei anormalem Verhalten sofort neu aufbauen.

Ein Detail in dem Beitrag ist nützlicher, als seine Länge vermuten lässt. Das Sichern von .openclaw/workspace/ erfasst den Arbeitszustand des Agenten, ohne Zugangsdaten einzuschließen; das Sichern des gesamten .openclaw/ Verzeichnisses ist einfacher wiederherzustellen, erfasst aber auch Tokens und Zugangsdaten, und der Beitrag warnt, dass dies unangemessen sein kann, wenn der Verdacht besteht, dass Zugangsdaten kompromittiert wurden. Ein Team, das das gesamte Verzeichnis sichert und es Notfallwiederherstellung nennt, hat das archiviert, was der Angreifer wollte.

Die Anleitung ist auch eine Produktübersicht.

Die zweite Hälfte des Beitrags ordnet jede empfohlene Kontrolle einem Microsoft-Produkt zu: Microsoft Entra ID für Least Privilege und bedingten Zugriff auf Agent-Identitäten, Microsoft Defender for Cloud Apps App Governance für OAuth-Inventarisierung und Consent-Drift, Microsoft Defender for Endpoint für den Agent-Host, Microsoft Defender XDR für die Korrelation, Microsoft Purview für Data Loss Prevention auf Endpunkten, Microsoft Defender for Cloud für Netzwerk-Egress und Microsoft Sentinel, wo längere Aufbewahrung oder Automatisierung erforderlich ist. Das ist übliche Praxis für einen Sicherheitsblog eines Anbieters, und es lohnt sich, es klar zu benennen: Das Dokument, das empfiehlt, eine Agent-Runtime eines Drittanbieters einzudämmen, wird von einem Unternehmen veröffentlicht, das die Eindämmung verkauft.

Der Hunting-Inhalt ist der Teil, der diese Einordnung übersteht, weil er konkret ist. Der Beitrag liefert KQL-Abfragen gegen Defender XDR-Tabellen – DeviceProcessEvents, CloudProcessEvents, DeviceFileEvents, DeviceNetworkEvents und OAuthAppInfo –, die nach Prozessbefehlszeilen und Dateinamen suchen, die „openclaw“, „moltbot“ oder „clawdbot“ enthalten, sowie nach Aufrufen von clawhub install mit seltenen Skill-Slugs, nach Änderungsaktivität in Erweiterungsordnern auf Entwickler-Endpunkten, nach neuen OAuth-Anwendungen mit hohen Berechtigungen, nach von Agent-Prozessen geöffneten lauschenden Diensten und danach, dass Agent-Runtimes cmd.exe, powershell.exe, pwsh.exe, bash, sh, curl oder wget starten. Was man auch von der Produktzuordnung halten mag: Diese Abfragen sind von jedem Defender XDR-Kunden am Tag der Veröffentlichung ausführbar, und sie setzen kein Vorwissen darüber voraus, welche Hosts die Runtime ausführen.

Was gilt als gesichert und was nicht

Gesichert und bestätigt: Microsoft veröffentlichte den Beitrag am 19. Februar 2026, und die obigen Zitate stammen daraus. Cybernews meldete die Warnung am 23. Februar 2026, TechRadar am 24. Februar 2026; beide wiederholten die beiden zentralen Sätze und die Isolationsempfehlung, statt sie zu prüfen. Wiederholte Suchen brachten keine Berichterstattung in The Register, BleepingComputer, Wired oder TechCrunch zutage, daher war die Presswelle um diesen Beitrag klein und unselbstständig; keine unabhängige Partei hat einen Test der architektonischen Behauptung von Microsoft veröffentlicht, und die verfügbare Bestätigung belegt, was Microsoft gesagt hat, nicht, ob es richtig ist.

Die Weiterleitung enthielt außerdem einen Fehler, der erwähnt werden sollte, denn er zeigt, wie schnell aus der Warnung eines Anbieters vor einem Drittanbieter-Tool eine Warnung des Anbieters vor seinem eigenen Tool wird. Der Bericht von Cybernews beginnt mit der Beschreibung von OpenClaw als „Microsofts KI-Assistent“; das ist es nicht. OpenClaw ist eine selbst gehostete Laufzeitumgebung, die die Defender-Forscher von Microsoft untersucht haben, und der Beitrag selbst nimmt die Unterscheidung strukturell vor, indem er selbst gehostete Laufzeitumgebungen – bei denen „Sie für den Blast Radius verantwortlich sind“ und Host, Plugins und lokaler Zustand alle innerhalb der Vertrauensgrenze liegen – verwalteten Assistenten und Agentenplattformen gegenüberstellt, bei denen die Laufzeit und Updates zentral verwaltet werden und sich die Kontrollen auf Identitätsbereiche, Connector-Governance und Datengrenzen konzentrieren.

Nicht belegt: dass irgendeine bestimmte Organisation in der vom Beitrag beschriebenen Weise kompromittiert wurde. Microsoft behauptet, die öffentliche Berichterstattung habe bösartige Skills in öffentlichen Registries dokumentiert, doch der Beitrag nennt weder einen Kampagnennamen noch eine Anzahl, ein Datum oder ein Opfer, und dieser Eintrag belegt daher keinen tatsächlichen Schaden. Ebenso wenig ist die Empfehlung bindend. Keine Aufsichtsbehörde hat sie erlassen, keine Normungsstelle hat sie übernommen, und nichts in den Unterlagen zeigt, dass ein Kunde, Prüfer oder Versicherer sie als Anforderung behandelt. Es ist die Meinung eines Anbieters dazu, wie seine eigenen Kunden mit einem Tool umgehen sollten, das er nicht kontrolliert – ungewöhnlich kategorisch und nicht durchsetzbar.

Was der Beitrag jedoch ändert, ist die Form der Frage, die ein Sicherheitsteam beantworten muss. Vor dem 19. Februar 2026 ließ sich die Entscheidung, OpenClaw auf einem Arbeitslaptop auszuführen, als Angelegenheit der Konfiguration und der Pilotgenehmigung darlegen. Danach muss die Argumentation gegen ein Dokument geführt werden, das besagt, dass das Design der Laufzeit selbst – nicht ihre Einstellungen – das ist, was den Rechner gefährdet, und das keine Version zum Aktualisieren, keinen Patch zum Anwenden und keine Korrektur auf der Roadmap bietet. Seine Abhilfe ist ein Bereitstellungsmuster: die Laufzeit isolieren, einschränken, worauf sie zugreifen kann, sie kontinuierlich überwachen und darauf vorbereitet sein, sie ohne Verzögerung neu aufzubauen.