OpenClaw: Autonomer KI-Agent mit Versteckten Risiken
200.000 GitHub-Sterne in wenigen Monaten. Ein Plugin-Marktplatz mit über 10.000 Community-Fähigkeiten. Eine Architektur, die so ausgefeilt ist, dass ernsthafte Ingenieure sie als echten Durchbruch im Design autonomer KI bezeichnen.
Und 30.000 Live-Instanzen, die aktuell ungeschützt im öffentlichen Internet laufen — viele mit Standard-Ports und unverschlüsselten Zugangsdaten.
Das ist OpenClaw in einem Satz. Und genau deshalb habe ich die letzte Woche damit verbracht, die Architektur zu analysieren, die Sicherheitsberichte zu lesen und herauszufinden, wie „sichere Nutzung" tatsächlich aussieht – im Vergleich zu dem, was Menschen in der Praxis tun.
Hier ist meine ehrliche Einschätzung als jemand, der professionell KI-Systeme entwickelt: Das Design von OpenClaw ist wirklich beeindruckend. Die Entscheidungen des Teams rund um Sitzungsisolierung, Speicherarchitektur und Fähigkeitsausführung basieren auf Mustern aus Betriebssystemen und Datenbanken – nicht auf dem typischen KI-Startup-Skript von „erst zum Laufen bringen, den Rest später". Das sind gute Ideen, durchdacht umgesetzt.
Die Sicherheitslage ist eine andere Geschichte. Im Januar erlaubte eine kritische Schwachstelle jeder bösartigen Webseite, heimlich Authentifizierungstoken zu stehlen, indem eine fehlende WebSocket-Ursprungsprüfung ausgenutzt wurde. Eine koordinierte Kampagne verbreitete Malware im Plugin-Marktplatz, die auf kryptografische Schlüssel und Agenten-Zugangsdaten abzielte. Meta hat das Tool intern verbannt.
Das sind keine Randfall-Probleme. Sie sind die Lücke zwischen „architektonisch elegant" und „bereit für den unbeaufsichtigten Einsatz auf deinem persönlichen Computer."
Beide Seiten zu verstehen – die Raffinesse und die Gefährdung – ist das Thema dieses Artikels. Wenn du ein KI-Entwickler oder ein sicherheitsbewusster Entwickler bist, der autonome Agenten bewertet, brauchst du das vollständige Bild. Nicht nur die Demo. Nicht nur die CVE-Liste. Beides.
Was OpenClaw Ist — Und Warum Es Sich von Jedem KI-Tool Unterscheidet, das Du Verwendet Hast
Jedes KI-Tool, das du wahrscheinlich verwendet hast, funktioniert reaktiv. Du öffnest ChatGPT, tippst eine Frage, erhältst eine Antwort. Du öffnest Copilot, schreibst etwas Code, erhältst Vorschläge. Die KI bleibt inaktiv, bis du sie explizit aufrufst.
OpenClaw wartet nicht.
Es ist ein selbst gehosteter autonomer Agent, der kontinuierlich auf deinem Gerät läuft – Laptop, VPS, Mac Mini, was auch immer du einsetzt – und proaktiv auf Basis von Auslösern handelt. Eine E-Mail kommt an, die einem bestimmten Muster entspricht: OpenClaw wird aktiv, verarbeitet sie, entwirft eine Antwort, plant eine Nachverfolgung. Ein Kalenderereignis ist achtundvierzig Stunden entfernt: Der Agent beginnt, relevante Kontextinformationen zu sammeln und Briefings vorzubereiten. Eine Datei in einem überwachten Ordner ändert sich: Ein Workflow startet automatisch.
Es integriert sich mit WhatsApp, Slack, Telegram, Discord, Signal, iMessage, deinen E-Mail-Clients, deinem Kalender und deinem Dateisystem. Nicht über umständliche APIs, die manuelle Webhook-Konfiguration erfordern – sondern über einen lokalen Gateway-Server, der als einheitlicher Nachrichtenbroker für all diese Plattformen fungiert.
Diese „immer aktive" Architektur macht OpenClaw kategorisch anders als die Tools, mit denen die meisten Entwickler vertraut sind. Der Vergleich gilt nicht ChatGPT oder Copilot. Es ähnelt eher einem Junior-Mitarbeiter, der Zugang zu all deinen Kommunikationskanälen hat und in deinem Namen handeln kann – ohne jedes Mal um Erlaubnis zu fragen.
Diese Beschreibung sollte sofort sowohl Begeisterung als auch Bedenken auslösen. Beide Reaktionen sind richtig.
Die Architektur: Warum Ingenieure Das Ernst Nehmen
Bevor wir die Sicherheitsprobleme besprechen, verdient das Design eine eigene Betrachtung. Denn das Team hat Entscheidungen getroffen, die die meisten KI-Projekte nicht treffen – Entscheidungen, die echtes Systemdenken zeigen.
OpenClaw läuft auf einer Vier-Schichten-Architektur.
Das Gateway ist ein lokaler WebSocket-Server, der als Nachrichtenbroker und Orchestrator fungiert. Jede verbundene Plattform – jede Messaging-App, jeder E-Mail-Client, jede Integration – läuft über das Gateway. Es verwaltet Authentifizierung, Routing und Koordination zwischen den anderen Schichten.
Die Reasoning-Schicht hostet das Sprachmodell. Aber es ist kein einfaches Durchleitungssystem. Die Reasoning-Schicht kombiniert eingehende Nachrichten mit Systemkontext, verwaltet Token-Budgets über die Gesprächsgeschichte und verarbeitet die Modellauswahl basierend auf der Aufgabenkomplexität. Einfache Aufgaben werden an schnellere, günstigere Modelle weitergeleitet. Schwere Reasoning-Aufgaben werden eskaliert. Das ist nicht nur eine Kostenoptimierung – es ist eine Architekturentscheidung, die das System reaktionsfähig hält.
Das Speichersystem speichert den Zustand in einfachen Markdown-Dateien auf der Festplatte. Sitzungsprotokolle, Benutzerpräferenzen, semantische Erinnerungen, Aufgabenkontext – all das liegt in lesbaren Dateien statt in einer Datenbank. Der Komprimierungsmechanismus entlehnt Muster vom Write-Ahead-Logging in Datenbanken und virtuellem Speicher-Paging in Betriebssystemen: Wenn der Kontext wächst, werden ältere Einträge komprimiert und archiviert, während der aktuelle Kontext aktiv bleibt.
Die Entscheidung, Markdown-Dateien statt einer Datenbank zu verwenden, ist bedenkenswert. Sie hält das Speichersystem für Menschen lesbar und prüfbar – du kannst eine Datei öffnen und genau sehen, was der Agent weiß, Einträge manuell ändern oder Kontext löschen, den du nicht behalten möchtest. Eine traditionelle Datenbank würde besser skalieren, aber der Transparenz-Kompromiss ist für einen lokalen Agenten sinnvoll, bei dem Vertrauen und Überprüfbarkeit wichtiger sind als Abfragegeschwindigkeit.
Fähigkeiten und Ausführung ist der Bereich, in dem der Agent tatsächlich Dinge tut. Befehle ausführen, Skripte ausführen, den Browser steuern, externe APIs aufrufen. Fähigkeiten sind in Markdown-Dateien definiert – lesbar, prüfbar, modifizierbar. Der Claw Hub-Marktplatz listet über 10.000 Community-Fähigkeiten.
Die Sitzungsisolierung wird durch Docker-Container gehandhabt. Jeder Kommunikationskanal erhält seinen eigenen Container, um zu verhindern, dass Kontext zwischen Gesprächen durchsickert.
Das sind ausgereifte Entwurfsmuster, die durchdacht auf einen KI-Agenten-Kontext angewendet werden. Das Speichersystem ist es wert, studiert zu werden, auch wenn du OpenClaw nie einsetzt – es ist eine praktische Lösung für ein Problem, das jeder langlebige KI-Agent lösen muss.
Die Januar-Schwachstelle: Wie Eine Webseite Deinen Agenten Übernehmen Konnte
Im Januar wurde eine kritische Sicherheitslücke aufgedeckt, die das Risiko perfekt veranschaulichte.
Der Gateway-Server – der Hub, durch den alles läuft – validierte keine WebSocket-Ursprungs-Header. Die praktische Konsequenz war: Jede bösartige Webseite konnte verstecktes JavaScript enthalten, das eine WebSocket-Verbindung zu deinem lokalen Gateway öffnete und deine Authentifizierungstoken stahl.
Kein Passwort erforderlich. Keine zusätzliche Authentifizierung. Besuche die falsche Seite, und ein Angreifer erhält die vollständige Fernsteuerung über deine OpenClaw-Instanz.
Der Angriff erfordert nicht, dass das Opfer etwas anderes tut, als eine Website zu besuchen, während seine OpenClaw-Instanz läuft. Das bösartige JavaScript läuft still im Browser, die fehlende Validierung lässt die Verbindung durch, und der Angreifer kann jetzt Befehle an deinen Agenten ausgeben – Befehle, die mit deinen Berechtigungen auf jeder integrierten Plattform ausgeführt werden.
Ein Agent, der mit deiner E-Mail, deinem Slack, deinem WhatsApp, deinem Dateisystem verbunden ist und Befehle eines Angreifers ausführt. Der Schaden ist erheblich.
Diese Schwachstelle wurde behoben. Aber ihre Existenz offenbart etwas Wichtiges über die Lücke zwischen architektonischen Ambitionen und Sicherheitsimplementierung. Die Sitzungsisolierung zwischen Containern war durchdacht konzipiert. Der einzige Schwachpunkt am Gateway – der am stärksten exponierte Bestandteil des gesamten Systems – war es nicht.
Weitere seitdem offenbarte Schwachstellen umfassen Server-Side Request Forgery, Path-Traversal-Angriffe und Authentifizierungsumgehungen. Das sind keine obskuren Randfälle – es sind die grundlegenden Sicherheitskategorien, die jeder netzwerkzugängliche Dienst vor dem Einsatz adressieren muss.
Der Plugin-Marktplatz: 20% von 10.000 Fähigkeiten Waren Bösartig
Das ist der Befund, der mich wirklich alarmierte.
Sicherheitsaudits von Claw Hub – dem Community-Plugin-Marktplatz – identifizierten etwa 800 bösartige Plugins von über 10.000 verfügbaren. Das ist eine Malware-Rate von etwa 20%, konzentriert auf eine koordinierte Kampagne mit einer spezifischen Zielstrategie.
Die bösartigen Plugins waren kein zufälliger Schrott oder offensichtliche Fälschungen. Es waren funktionale, nützlich aussehende Fähigkeiten, die auch drei spezifische Dateien extrahierten:
openclaw.json— die Gateway-Authentifizierungstokendevice.json— kryptografische Schlüssel für sichere Kopplungsoulm— die Persönlichkeits- und Verhaltensdefinitionen des Agenten
Warum diese drei? Weil ein Angreifer mit openclaw.json und device.json authentifizierten Zugriff auf deine Agenten-Instanz hat. Mit soulm verstehen sie, wie dein Agent sich verhält, und können Anweisungen formulieren, die mit bestehenden Verhaltensmustern übereinstimmen.
Die Raffinesse des Targetings – genau zu wissen, welche Dateien die Zugangsdaten und Konfigurationen enthalten, die wichtig sind – deutet auf Akteure hin, die die Systemarchitektur speziell studiert haben, um maximalen Nutzen aus einem Kompromiss zu ziehen.
Der Vergleich mit npm ist explizit zu machen. Das npm-Ökosystem hatte wiederholt Supply-Chain-Angriffe. Das KI-Fähigkeits-Marktplatz-Problem ist strukturell identisch, aber mit einem bedeutend höheren Schadensradius: Ein bösartiges npm-Paket hat typischerweise Zugriff auf deine Entwicklungsumgebung. Eine bösartige OpenClaw-Fähigkeit hat Zugriff auf deine Kommunikation, deinen Kalender, deine Dateien und die Fähigkeit, auf jeder Plattform als du zu handeln.
OpenClaw hat seitdem einen integrierten Sicherheitsscanner eingeführt – OpenClaw Doctor –, der riskante Richtlinien, Fehlkonfigurationen und fehlende Authentifizierung in installierten Fähigkeiten erkennt. Das ist eine bedeutende Verbesserung. Aber die Basis-Malware-Rate von 20% bedeutet, dass jede Fähigkeit, die vor den jüngsten Sicherheitsverbesserungen installiert wurde, nachträglich geprüft werden sollte.
OpenClaw Ohne Probleme Betreiben: Das Eigentliche Setup
Wenn du damit experimentieren möchtest – und es lohnt sich zu experimentieren, die Architektur ist wirklich interessant – hier erfährst du, wie du es tust, ohne dich den offensichtlichen Risiken auszusetzen.
Niemals auf dem persönlichen Computer betreiben. Das ist die Grundlage. Dein persönlicher Laptop hat Zugangsdaten, Schlüssel, sensible Dateien und direkten Zugriff auf deine echten Kommunikationskonten. Verwende einen dedizierten VPS oder eine isolierte Maschine.
Zwei-Schichten-Container-Isolierung ist das Minimum. Ein Container für das Gateway, separate Sandbox-Container für die Ausführung von Fähigkeiten. Die Fähigkeits-Container sollten standardmäßig keinen Netzwerkzugriff haben, wo möglich schreibgeschützte Dateisysteme haben und Speicherlimits haben, die Ressourcenerschöpfungsangriffe verhindern.
Verwende Podman statt Docker. Podman läuft rootlos – es gibt keinen Root-Daemon-Prozess, der die Container-Laufzeit besitzt. Wenn ein Container-Ausbruch stattfindet, ist der Schaden auf die Berechtigungen des Benutzers begrenzt, nicht auf Root.
Binde das Gateway nur an localhost. Das Gateway läuft standardmäßig auf Port 18789. Dieser Port sollte niemals direkt dem Internet ausgesetzt werden. Wenn du Fernzugriff auf deinen Agenten benötigst, stelle einen Reverse-Proxy davor mit TLS-Terminierung und Authentifizierung.
Lies den Quellcode von Fähigkeiten vor der Installation. Jede Fähigkeit ist eine Markdown-Datei mit eingebettetem Code. Sie sind für Menschen lesbar. Verwende OpenClaw Doctor als ersten Filter, aber behandle einen sauberen Scan nicht als Garantie.
Halte die Angriffsfläche der Fähigkeiten minimal. Je mehr Fähigkeiten du installierst, desto größer ist die Angriffsfläche. Beginne mit den Kernfähigkeiten, die du wirklich benötigst.
Rotiere Zugangsdaten nach jeder ungeprüften Installation. Wenn du Fähigkeiten installiert hast, bevor der Marktplatz-Audit abgeschlossen war, tue das jetzt. Gehe davon aus, dass jede Fähigkeit, die vor den jüngsten Sicherheitsverbesserungen von Claw Hub installiert wurde, potenziell bösartig war.
Überprüfe die Aktionsprotokolle des Agenten regelmäßig. Plane jede Woche Zeit ein, um zu überprüfen, was der Agent tatsächlich getan hat – welche Befehle er ausgeführt hat, auf welche Dateien er zugegriffen hat, welche Nachrichten er gesendet oder entworfen hat.
Die Ehrliche Einschätzung: Wer OpenClaw Eigentlich Betreiben Sollte
OpenClaw ist derzeit das richtige Tool für eine begrenzte Anzahl von Anwendungsfällen.
Entwickler, die die Architektur autonomer Agenten in einer kontrollierten Umgebung studieren möchten – speziell das Speichersystem und das Design der Sitzungsisolierung – werden echten Mehrwert aus dem Betrieb einer gehärteten lokalen Instanz ziehen.
Sicherheitsforscher haben offensichtliche Gründe, interessiert zu sein. Die Angriffsfläche ist reich und die Offenlegungen sind gut dokumentiert.
Gründer und Entwickler, die bewerten, ob autonome KI-Agenten in ihr Produkt oder ihre Infrastruktur gehören, sollten eine Sandbox-Instanz betreiben und sie gegen das Bedrohungsmodell stress-testen, das zu ihrem Anwendungsfall passt.
Wer OpenClaw derzeit nicht betreiben sollte: jeder, der es mit Produktionssystemen, echten Kommunikationskonten oder wichtigen Dateien verbinden möchte, ohne in die Containerisierung und Sicherheitsüberprüfung zu investieren, die der Einsatz erfordert.
Metas internes Verbot ist keine willkürliche Vorsicht. Es spiegelt ein Sicherheitsteam wider, das auf die historische Schwachstellengeschichte und die Malware-Rate im Marktplatz blickt und zu dem Schluss kommt, dass das Risiko für den organisatorischen Einsatz nicht gerechtfertigt ist. Das ist eine vernünftige Schlussfolgerung.
Was OpenClaw Uns Über die Zukunft von KI-Agenten Erzählt
Die interessante Frage ist nicht, ob die aktuelle Sicherheitshaltung von OpenClaw problematisch ist – das ist sie offensichtlich. Die interessante Frage ist, was die Existenz von OpenClaw, seine 200.000 Sterne und seine architektonische Raffinesse uns darüber erzählen, wohin das Agenten-Ökosystem sich entwickelt.
Autonome KI-Agenten mit persistentem Zustand, proaktivem Auslösen und tiefer Integration in Kommunikations- und Dateisysteme kommen, unabhängig davon, ob ein spezifisches Projekt die Sicherheit beim ersten Versuch richtig hinbekommt. Das fehlende Stück ist das Sicherheitsrahmenwerk, das diese Systeme vertrauenswürdig genug für breiten Einsatz macht.
Was das Plugin-Marktplatz-Problem von OpenClaw illustriert, ist, dass das aktuelle Vertrauensmodell – Community-beigesteuerte Fähigkeiten, Benutzerermessen – nicht mit dem Bedrohungsmodell eines Agenten skaliert, der Zugriff auf alles hat. Die Sicherheitsarchitektur muss unter der Annahme entworfen werden, dass Fähigkeiten bösartig sein werden, nicht der Annahme, dass sie es nicht sein werden.
Die Teams, die autonome KI-Agenten mit produktionsreifer Sicherheit entwickeln, werden echte Vorteile gegenüber denen haben, die zuerst entwickeln und später patchen. Die Architektur von OpenClaw ist es wert, studiert zu werden. Die aktuelle, weit verbreitete Einsatzpraxis ist es wert, vermieden zu werden.
🤝 Lass Uns Zusammenarbeiten
Möchtest du KI-Systeme aufbauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.
- 🔗 Fiverr (individuelle Entwicklung & Integrationen): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (Unternehmenslösungen): ramlit.com
- 🎨 ColorPark (Design & Branding): colorpark.io
- 🛡 xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
