OpenClaw und Schatten-KI: Risikobewertung und Reaktion

Der Open-Source-KI-Assistent OpenClaw (zuvor „Clawdbot“ und „Moltbot“ genannt) ist in aller Munde. Er kann lokal auf einem Gerät installiert werden. Er lässt sich in beliebte Chat-Plattformen wie WhatsApp, Telegram, Signal, Discord und Slack einbinden, über die der Assistent auch die Befehle seines Besitzers erhält. Er kann das lokale Dateisystem bedienen. Und er hat Zugriff auf den Kalender, die E-Mails und den Browser und kann sogar Betriebssystembefehle über die Befehlszeile ausführen.

Schon der Einsatz auf Privatrechnern gibt reichlich Anlass für Sicherheitsbedenken und kann nervös machen. Wenn der KI-Agent jedoch im geschäftlichen Umfeld genutzt wird, kann einem wirklich unheimlich werden. Führt das nicht direkt ins Chaos? Einige Experten bezeichnen OpenClaw bereits als die größte Insider-Bedrohung des Jahres 2026. Die Probleme mit OpenClaw sind kaum zu überblicken und umfassen praktisch alle Gefahrenbereiche, die in der aktuellen Studie Top-10 der Risiken für KI-Agenten-Anwendungen aufgezählt werden.

OpenClaw kann ein beliebiges lokales oder cloudbasiertes LLM einbinden und eine Vielzahl zusätzlicher Dienste integrieren. Sein Herzstück ist ein Gateway, das Befehle über eine Chat-App oder eine Web-UI entgegennimmt und an die entsprechenden KI-Agenten weiterleitet. Die erste Version wurde im November 2025 als „Clawdbot“ veröffentlicht. Im Januar 2026 war er bereits überall in den Schlagzeilen – und hatte jede Menge Sicherheitsprobleme im Gepäck. Innerhalb einer Woche wurden mehrere kritische Schwachstellen bekannt, im Skill-Verzeichnis tauchten bösartige Fähigkeiten auf und aus Moltbook (das „Reddit für Bots“) waren Geheimnisse durchgesickert. Damit nicht genug: Anthropic forderte wegen Markenrechtsverletzungen im Zusammenhang mit „Claude“, das Projekt umzubenennen, und bei X übernahmen Kryptobetrüger den Kontonamen des Projekts.

Bekannte OpenClaw-Probleme

Obwohl der Entwickler des Projekts über die Sicherheitsprobleme Bescheid weiß, gibt es keine speziellen Ressourcen für das Schwachstellen-Management oder andere wichtige Sicherheitsaspekte des Produkts. In dieser Hinsicht erinnert es bisher eher an ein Hobbyprojekt.

OpenClaw-Schwachstellen

Die gefährlichste bekannte Schwachstelle in OpenClaw ist CVE-2026-25253 (CVSS 8.8). Ein Exploit führt zur vollständigen Kompromittierung des Gateways. Im Ernstfall kann ein Angreifer beliebige Befehle ausführen. Noch erschreckender ist, wie einfach sich die Schwachstelle ausnutzen lässt: Wenn der Agent die Website eines Angreifers besucht oder der Nutzer auf einen bösartigen Link klickt, wird das primäre Authentifizierungs-Token preisgegeben. Mit diesem Token erhält der Angreifer die komplette administrative Kontrolle über das Gateway. Diese Schwachstelle wurde in Version 2026.1.29 gepatcht.

Außerdem wurden zwei gefährliche Schwachstellen bei der Befehlseingabe gefunden (CVE-2026-24763 und CVE-2026-25157).

Riskante Standardeinstellungen und Funktionen

Eine Vielzahl von Standardeinstellungen und Implementierungsmängeln machen einen Angriff auf das Gateway zum Kinderspiel:

• Die Authentifizierung ist standardmäßig deaktiviert, sodass das Gateway einfach über das Internet erreichbar ist.
• Der Server akzeptiert WebSocket-Verbindungen, ohne deren Quelle zu überprüfen.
• Localhost-Verbindungen werden als vertrauenswürdig behandelt. Dies kann zum Desaster werden, wenn der Host einen Reverseproxy ausführt.
• Im Gastmodus ist der Zugriff auf verschiedene Tools möglich, darunter auch auf einige gefährliche.
• Kritische Konfigurationsparameter werden in mDNS-Broadcast-Nachrichten offen über das lokale Netzwerk weitergegeben.

Unverschlüsselte Geheimnisse

Die Konfiguration, der „Speicher“ und die Chat-Protokolle von OpenClaw enthalten API-Schlüssel, Passwörter und andere Anmeldeinformationen für LLMs und Integrationsdienste im Klartext. Dies ist eine kritische Bedrohung: Es wurden bereits Versionen der Infostealer RedLine und Lumma gefunden, in denen OpenClaw-Dateipfade als Diebstahlobjekte ausgewiesen waren. Außerdem wurde der Infostealer Vidar beim Stehlen von Geheimnissen aus OpenClaw erwischt.

Schädliche Fähigkeiten

Die Funktionalität von OpenClaw kann durch „Skills“ erweitert werden, die im Repository ClawHub zu haben sind. Da Skills von beliebigen Personen hochgeladen werden können, dauerte es nicht lange, bis Angreifer den macOS-Infostealer AMOS in ihre Uploads „einfädelten“ und neue Bedrohungen erschufen. Innerhalb kürzester Zeit gab es Hunderte von bösartigen Skills. Die Entwickler trafen schnell eine Vereinbarung mit VirusTotal. Jetzt werden alle hochgeladenen Skills nicht nur anhand von Malware-Datenbanken untersucht, sondern auch unter Einsatz von LLMs einer Code- und Inhaltsanalyse unterzogen. Das bedeutet aber keine Entwarnung: Diese Methode ist kein Allheilmittel.

Strukturelle Fehler des OpenClaw-KI-Agenten

Natürlich können Schwachstellen geschlossen und Einstellungen verbessert werden. Einige der Probleme von OpenClaw beruhen jedoch auf der Konzeption. Das Produkt enthält mehrere kritische Funktionen, die in der vorliegenden Kombination gefährlich sind:

• OpenClaw hat privilegierten Zugriff auf sensible Daten auf dem Host-Rechner und auf die persönlichen Benutzerkonten des Besitzers.
• Der Assistent ist offen für nicht vertrauenswürdige Daten: Der Agent empfängt Nachrichten über Chat-Apps und via E-Mail, durchsucht selbstständig Webseiten und vieles mehr.
• Da LLMs im Spiel sind, kann er Befehle und Daten nicht zuverlässig voneinander trennen, was Prompt-Injektionen ermöglicht.
• Der Agent speichert wichtige Erkenntnisse und Artefakte aus seinen Aufgaben, um sie für zukünftige Aktionen zu verwenden. Die Folge: Eine einzige erfolgreiche Injektion kann den Speicher des Agenten „vergiften“ und sein Verhalten langfristig beeinflussen.
• OpenClaw kann mit der Außenwelt kommunizieren: E-Mails senden, API-Aufrufe ausführen und andere Methoden verwenden, um interne Daten abzugreifen.

Natürlich ist OpenClaw ein extremes Beispiel. Die obige Liste der „Schrecklichen Fünf“ trifft jedoch für fast alle Mehrzweck-KI-Agenten zu.

Risiken von OpenClaw für Unternehmen

Wenn ein Mitarbeiter den Agenten auf einem Unternehmensgerät installiert und ihn auch nur mit grundlegenden Diensten verbindet (z. B. Slack und SharePoint), droht eine tiefgreifende Netzwerkkompromittierung. Die Gründe liegen in der Kombination aus autonomer Befehlsausführung, weitreichendem Zugriff auf das Dateisystem und übermäßigen OAuth-Berechtigungen. Die Angewohnheit des Bots, unverschlüsselte Geheimnisse und Token an einem Ort zu horten, birgt extreme Gefahren. Und diese können leicht zur Katastrophe führen, selbst wenn der KI-Agent selbst nicht kompromittiert wird.

Darüber hinaus verstoßen solche Konfigurationen in mehreren Ländern und Branchen gegen behördliche Anforderungen, was zu Bußgeldern und Auditproblemen führen kann. Aktuelle Vorschriften (etwa im KI-Gesetz der EU oder im NIST AI Risk Management Framework) schreiben für KI-Agenten ausdrücklich eine strenge Zugriffskontrolle vor. Der Konfigurationsansatz von OpenClaw verfehlt diese Standards.

Der Clou ist jedoch: OpenClaw kann auch dann auf den privaten Geräten von Mitarbeitern landen, wenn die Installation dieser Software auf geschäftlichen Geräten untersagt ist. Und daraus ergeben sich die folgenden Risiken für das gesamte Unternehmen:

• Auf Privatgeräten werden häufig Zugriffsdaten für Unternehmenssysteme gespeichert, beispielsweise geschäftliche VPN-Konfigurationen oder Browser-Token für E-Mail und interne Tools. Diese können gestohlen werden, um in die Infrastruktur des Unternehmens einzudringen.
• Da der Agent über Chat-Apps gesteuert wird, ist nicht nur der Mitarbeiter ein Ziel von Social Engineering, sondern auch sein KI-Agent. Mögliche Folgen: Übernahme von KI-Konten, Identitätsdiebstahl in Chats mit Kollegen und eine Vielzahl anderer Betrugsmethoden. Selbst wenn in privaten Chats nur gelegentlich über die Arbeit gesprochen wird, können sensible Informationen gestohlen werden.
• Wenn ein KI-Agent auf einem privaten Gerät mit einem Unternehmensdienst (E-Mail, Messenger, Dateispeicher) verknüpft ist, können Angreifer den Agenten so manipulieren, dass er Daten absaugt. Für die Überwachungssysteme des Unternehmens sind solche Vorgänge äußerst schwer zu durchschauen.

OpenClaw erkennen

Je nachdem, über welche Tracking- und Reaktionsoptionen ein SOC-Team verfügt, lassen sich Verbindungsversuche mit dem OpenClaw-Gateway auf privaten Geräten oder in der Cloud nachverfolgen. Darüber hinaus können bestimmte Kombinationen verdächtiger Merkmale darauf hinweisen, dass OpenClaw auf einem Unternehmensgerät vorhanden ist:

• die Verzeichnisse ~/.openclaw/, ~/clawd/ oder ~/.clawdbot auf Host-Computern
• HTML-Fingerabdrücke der Clawdbot-Kontrollfelder (sie können durch einen Netzwerk-Scan mit internen oder öffentlichen Tools wie Shodan identifiziert werden)
• WebSocket-Datenverkehr auf den Ports 3000 und 18789
• mDNS-Broadcast-Nachrichten auf Port 5353 (insbesondere openclaw-gw.tcp)
• ungewöhnliche Authentifizierungsversuche in Unternehmensdiensten über OAuth: Versuche, neue App-IDs zu registrieren, OAuth-Consent-Ereignisse oder User-Agent-Zeichenfolgen, die für Node.js und andere nicht standardmäßige Benutzeragenten typisch sind
• Zugriffsmuster, die für die automatisierte Datenerfassung charakteristisch sind: Lesen großer Datenmengen (Vernichten aller Dateien oder aller E-Mails) oder regelmäßig wiederkehrendes Scannen von Verzeichnissen außerhalb der Geschäftszeiten

Schatten-KI kontrollieren

Eine Reihe von Sicherheitsmaßnahmen kann den Einsatz von Schatten-IT und Schatten-KI effektiv reduzieren und die Installation von OpenClaw in einem Unternehmen erheblich erschweren:

• Verwende Allow-Listen auf Host-Ebene, um sicherzustellen, dass nur genehmigte Anwendungen und Cloud-Integrationen installiert werden. Für Produkte, die Erweiterungen unterstützen (z. B. Chrome-Erweiterungen, VS Code-Plug-ins oder OpenClaw-Skills) eignet sich zusätzlich ein Katalog mit genehmigten Add-ons.
• Alle Produkte und Dienste (auch KI-Agenten) müssen eine vollständige Sicherheitsanalyse durchlaufen, bevor eine Verbindung mit Unternehmensressourcen gestattet wird.
• Für KI-Agenten müssen genauso strenge Sicherheitsanforderungen gelten wie für Server, die öffentlich zugänglich sind und sensible Unternehmensdaten verarbeiten.
• Implementiere das Prinzip der geringsten Berechtigungen für alle Nutzer und andere Identitäten.
• Administratorrechte werden nur erteilt, wenn dies aus geschäftlichen Gründen notwendig ist. Nutzer dürfen erhöhte Berechtigungen nur für bestimmte Aufgaben verwenden und nicht ständig mit privilegierten Benutzerkonten arbeiten.
• Konfiguriere die Unternehmensdienste so, dass technische Integrationen (z. B. Apps, die OAuth-Zugriff anfordern) nur die minimal erforderlichen Berechtigungen erhalten.
• Untersuche regelmäßig die Integrationen, OAuth-Token und Berechtigungen, die Drittanbieter-Apps zugewiesen werden. Überprüfe gemeinsam mit der Unternehmensleitung, ob diese Rechte und Dienste erforderlich sind. Übermäßige Berechtigungen müssen proaktiv widerrufen und veraltete Integrationen deaktiviert werden.

Sichere Bereitstellung von KI-Agenten

Wenn ein Unternehmen KI-Agenten zu experimentellen Zwecken zulässt (beispielsweise für Entwicklungstests oder zur Effizienzbewertung) oder bestimmte KI-Anwendungsfälle für einen breiteren Mitarbeiterkreis erlaubt, sind zuverlässige Maßnahmen zur Überwachung, Protokollierung und Zugriffskontrolle unerlässlich:

• Stelle die Agenten in einem isolierten Subnetz mit strengen Regeln für den ein- und ausgehenden Datenverkehr bereit und beschränke die Kommunikation auf vertrauenswürdige Hosts, die für die jeweilige Aufgabe erforderlich sind.
• Empfehlenswert sind kurzlebige Zugriffstokens mit streng begrenzten Berechtigungen. Ein Agent darf niemals Tokens erhalten, die Zugriff auf primäre Server oder Dienste des Unternehmens ermöglichen. Im Idealfall sollten für jeden Test dedizierte Dienstkonten erstellt werden.
• Isoliere den Agenten von gefährlichen Tools und Dateien, die für seine spezifische Aufgabe irrelevant sind. Für eine experimentelle Bereitstellung empfiehlt es sich, den Agenten mit rein synthetischen Daten zu testen, die die Struktur echter Produktionsdaten nachahmen.
• Sorge dafür, dass alle Aktionen des Agenten genau protokolliert werden. Dazu gehören Ereignisprotokolle, Befehlszeilenparameter und Artefakte der Zwischenschritte, die mit einzelnen ausgeführten Befehlen verbunden sind.
• Verwende eine SIEM-Lösung zur Analyse anormaler Agentenaktivitäten. Hier kommen die gleichen Methoden und Regeln zum Einsatz wie bei der Erkennung von LotL-Angriffen. Allerdings muss zusätzlich definiert werden, wie die normale Aktivität eines konkreten Agenten aussieht.
• Wenn MCP-Server und zusätzliche Agenten-Skills verwendet werden, untersuche diese Elemente mit entsprechenden Sicherheitstools (z. B. skill-scanner, mcp-scanner oder mcp-scan). Speziell für OpenClaw-Tests wurden von mehreren Unternehmen bereits Open-Source-Tools zur Sicherheitsprüfung von Konfigurationen veröffentlicht.

Unternehmensrichtlinien und Mitarbeiterschulung

Ein kompromissloses Verbot aller KI-Tools wäre ein einfacher Weg, der sein Ziel aber kaum erreichen würde. Mitarbeiter finden in der Regel Ausweichmöglichkeiten, was das Problem in den Schatten drängt und noch schwieriger kontrollierbar macht. Stattdessen solltest du ein vernünftiges Gleichgewicht zwischen Produktivität und Sicherheit anstreben.

Implementiere transparente Richtlinien für die Nutzung von Agenten-KI. Lege fest, welche Datenkategorien von externen KI-Diensten verarbeitet werden dürfen und für welche Daten dies tabu ist. Die Mitarbeiter müssen verstehen, warum etwas verboten ist. Ein „Ja mit Einschränkungen“ wird immer besser aufgenommen als ein pauschales „Nein“.

Schulung mit praktischen Beispielen. Abstrakte Warnungen vor „Gefahr von Datenlecks“ sind meist wirkungslos. Du kannst aber beispielsweise demonstrieren, wie ein KI-Agent mit E-Mail-Zugriff durch eine unvermutet eingehende E-Mail dazu aufgefordert wird, vertrauliche Nachrichten weiterzuleiten. Wenn sich die Bedrohung echt anfühlt, wächst auch die Motivation, die Sicherheitsregeln zu befolgen. Ideal wäre ein kurzer KI-Sicherheits-Crashkurs für die gesamte Belegschaft.

Biete sichere Alternativen an. Wenn Mitarbeiter einen KI-Assistenten benötigen, stelle ein genehmigtes Tool bereit, das zentrale Verwaltung, Protokollierung und OAuth-Zugriffskontrolle bietet.