OpenClaw ist eine architektonisch anspruchsvolle Plattform, die als einziges, langlebiges Gateway für KI-Agenten über verschiedene Oberflächen hinweg, einschließlich WhatsApp, Telegram, Slack und Discord, konzipiert wurde. Durch die Verbindung dieser Messaging-Ebenen mit lokalen Knoten und Ausführungstools bietet sie Gründern und CTOs einen leistungsstarken Weg zu autonomen Workflows. Das Sicherheitsprofil von OpenClaw wird jedoch von den Teams, die es in risikoreichen Umgebungen einsetzen, häufig missverstanden.

Die eigene Dokumentation von OpenClaw ist eindeutig: Das Gateway behandelt authentifizierte Anrufer als vertrauenswürdige Operatoren, und eine einzelne Instanz stellt keine Sicherheitsgrenze für feindliche Mandanten dar. Wenn CTOs dieses Design der persönlichen Ebene in gemeinsame Teampostfächer oder kundenorientierte Workflows integrieren, ohne Isolation und Governance neu zu gestalten, übernehmen sie ein Vertrauensmodell, das nicht zu der Aufgabe passt, die das System erfüllt.

Dieser Artikel behandelt die operativen Fehlermodi, die aus dieser Diskrepanz resultieren, sowie einen Meta-Fehler, der sie verstärkt: die Behandlung von Self-Hosting als Ersatz für Governance.

Wie Sicherheitslücken in OpenClaw wirklich aussehen

Um zu beurteilen, ob OpenClaw für einen bestimmten Anwendungsfall sicher ist, müssen Unternehmen über die Suche nach benannten Schwachstellen hinausgehen und fünf verschiedene Kategorien operativer Fehler betrachten.

1. Risiko des Bereitstellungsmodells

Die Dokumentation von OpenClaw ist eindeutig: Ein einzelnes Gateway ist keine Multi-Tenant-Sicherheitsgrenze, und der Betrieb eines solchen für sich gegenseitig nicht vertrauende oder gegnerische Operatoren wird nicht unterstützt. Auf einer gemeinsamen Instanz kann ein Operator die Session-Historie und Tool-Aufrufe eines anderen sehen und, je nach Konfiguration, deren Anmeldeinformationen. Ein Team, das dies als Produktionsgrenze einsetzt, hat eine gemeinsame Workstation, keinen segmentierten Dienst.

2. Nicht vertrauenswürdige Eingaben fließen in vertrauenswürdige Tools

Alle Bytes, die den Agenten über einen Messaging-Kanal, eine Websuche, eine E-Mail oder einen Anhang erreichen, sind vom Angreifer kontrolliert, bis das Gegenteil bewiesen ist. Dies ist Prompt Injection, und der Mechanismus ist banal. Eine Seite, die der Agent zusammenfassen soll, enthält Anweisungen, den Inhalt eines anderen Dokuments an eine externe Adresse zu senden, und das Modell befolgt diese. OpenClaw behandelt eingehende Inhalte per Design als nicht vertrauenswürdig. Die meisten Teams konfigurieren die umgebenden Tools in der Praxis nicht so, dass diese Grenze durchgesetzt wird.

3. Tool- und Ausführungs-Blast-Radius

Teams geben OpenClaw-Agenten Shell-Zugriff, Node-Befehle und Dateisystemzugriff, weil die Workflows dies erfordern. Die Plattform liefert Ausführungsfreigaben und Whitelists als Schutzmechanismen, und diese erfüllen ihren beabsichtigten Zweck: einen Operator daran zu hindern, versehentlich einen destruktiven Befehl auszuführen. Sie sind nicht dazu gedacht, einen feindlichen Benutzer einzudämmen, der denselben Agenten steuert. 

GHSA-48wf-g7cp-gr3m veranschaulicht die Lücke. Eine Umgehung der Ausführungssperre über env -S ließ den Policy-Analyzer einen anderen Befehl sehen, als die Laufzeit ausführte. Whitelists, die auf statischer Analyse der Shell-Semantik basieren, weisen eine wiederkehrende Historie dieser Art von Diskrepanz auf. Sie als Sicherheitsgrenze für nicht vertrauenswürdige Eingaben zu behandeln, bedeutet, diese Fehlerkategorie als aktives Risiko zu akzeptieren.

4. Risiko gemeinsamer Posteingänge und Session-Überschreitungen

OpenClaw leitet eingehende Nachrichten an Sessions weiter. In einem gemeinsamen Slack-Kanal oder Gruppenchat bindet die Standard-Routing-Einstellung mehrere Benutzer an eine einzige "Haupt"-Session, was bedeutet, dass die Frage eines Benutzers Kontext aus einer früheren Konversation eines anderen Benutzers aufdecken kann, einschließlich Dokumentinhalten und Tool-Ergebnissen. Die Lösung ist eine Konfigurationszeile: session.dmScope: 'per-channel-peer'. Die meisten Teams stellen dies nicht ein, weil die Standardeinstellung keinen Fehler erzeugt. Es gibt keine Warnung, nur Leckagen.

5. Governance-Theater

Die vorangegangenen vier Risiken sind technischer Natur. Das fünfte ist organisatorisch und steht über ihnen: die Behandlung von "wir hosten selbst" als aussagekräftige Sicherheitsaussage. Selbst-Hosting bestimmt, wo die Bytes liegen. Es kartiert keine Risiken, misst keine Kontrollen und legt keine Verantwortlichkeiten für die Reaktion auf Vorfälle fest, wenn ein Agent einen Befehl ausführt, den er nicht hätte ausführen dürfen. Teams, die diese Ebene überspringen, enden mit einer Infrastruktur, die sie betreiben, und einem Agentenverhalten, das sie nicht erklären können – ein Zustand, der zu den schlimmsten Postmortems führt.

Wo das OpenClaw-Sicherheitsrisiko zu steigen beginnt

Drei Variablen treiben das OpenClaw-Risiko in der Praxis an: die Anzahl der Operatoren, die die Instanz teilen, die Funktionsfläche des Agenten und die Sensibilität der Daten, die darüber laufen. Jede erhöht die erforderlichen Kontrollstufen unabhängig voneinander. Das Skalieren einer dieser Variablen, während die anderen unbehandelt bleiben, führt zu einer Bereitstellung, die bis zum ersten Vorfall reibungslos funktioniert.

• Gateway-Freigabe. Sobald zwei unabhängige Operatoren dieselbe Instanz nutzen, benötigen Sie eine Isolation pro Operator oder ein separates Gateway pro Team.
• Lokaler Infrastrukturzugriff. Wenn der Agent lokale Dateien lesen, einen Bildschirm erfassen oder system.run auf einem Knoten ausführen kann, behandeln Sie jedes Tool als ein zu gestaltendes Privileg, nicht als eine zu aktivierende Annehmlichkeit.
• Öffentliche oder halböffentliche Kanäle. Jeder Teilnehmer in einem Slack-Raum oder Gruppenchat wird Teil der Angriffsfläche. Einer von ihnen muss nur den Agenten dazu bringen, etwas zu lesen.
• Regulierte Daten. Sobald personenbezogene Kundendaten (PII), Finanzdaten oder NDA-gebundenes Material in den Datenfluss gelangen, ist die Frage nicht, ob Sie Governance benötigen, sondern ob die vorhandene Governance überprüfbar ist.

So reduzieren Sie das OpenClaw-Risiko, bevor es die Produktion erreicht

Diese Risiken sind real, und es ist weitaus besser, sie anzugehen, bevor sie zu Vorfällen werden. Bei Codebridge empfehlen wir, mit den unten aufgeführten Kontrollen zu beginnen, um das OpenClaw-Risiko zu reduzieren und eine stärkere Sicherheitsgrundlage zu schaffen.

• Getrennte Vertrauensgrenzen. Mindestens ein Gateway pro Benutzergruppe. Ein VPS- oder OS-Benutzer pro Gruppe, wenn die Datensensibilität dies erfordert. Teilen Sie kein Gateway zwischen Teams mit unterschiedlichen Berechtigungsstufen.
• Tool-Berechtigungen standardmäßig entziehen. Beginnen Sie jeden Workflow mit einem minimalen Profil und fügen Sie Fähigkeiten nur hinzu, wenn der Anwendungsfall es erfordert. Legen Sie tools.fs.workspaceOnly: true fest, um den Dateisystemzugriff auf ein bestimmtes Verzeichnis zu beschränken.
• Behandeln Sie Nachrichten als feindliche Eingabe. Aktivieren Sie session.dmScope: 'per-channel-peer' auf jeder gemeinsam genutzten Oberfläche. Isolieren Sie jeden Agenten, der Webseiten, E-Mails oder Anhänge liest, die das Team nicht selbst erstellt hat.
• Halten Sie Anmeldeinformationen von Prompts fern. Verwenden Sie Umgebungsvariablen oder einen verschlüsselten Secret-Anbieter. Ein in einen Prompt eingefügtes Secret ist nun Teil des Transkripts, der Protokolle und potenziell des Kontexts jedes Modells, das es verarbeitet hat.
• Etablieren Sie eine überprüfbare Governance. Dokumentieren Sie die Fähigkeiten des Agenten, verfolgen Sie, wie oft Genehmigungen ausgelöst werden, und weisen Sie die Verantwortlichkeit für Vorfälle zu. Das NIST AI RMF (Govern, Map, Measure, Manage) ist ein geeignetes Gerüst, falls Sie noch keines haben.

OpenClaw Checkliste zur Produktionshärtung

Self-Hosted vs. Managed: Wo OpenClaw GDN zum Einsatz kommt

Der Großteil der oben genannten Liste ist wiederholbare Infrastrukturarbeit und keine Produktarbeit. OpenClaw GDN übernimmt die Gateway-, Isolations-, Berechtigungs- und Audit-Ebenen auf Plattformebene, wodurch die Workflow-Gestaltung Ihrem Team überlassen bleibt. Teams, die diesen Stack nicht neu aufbauen möchten, können eine isolierte GDN-Instanz unter Openclaw.gdnbereitstellen.

GDN stellt pro Kunde eine dedizierte VM mit Firewall-Schutz und dem, was seine Architektur als Zero-Access bezeichnet, bereit: Nach der Bereitstellung entfernt GDN seinen eigenen SSH-Pfad zur Instanz, sodass API-Schlüssel und Laufzeitdaten auf der VM des Kunden und nirgendwo sonst verbleiben. Dies schließt eine Klasse von Operator-Insider-Risiken aus, die die meisten selbst gehosteten Bereitstellungen implizit lassen.

Managed Hosting reduziert das Infrastrukturrisiko. Es reduziert jedoch nicht das Workflow-Risiko. Ein Team auf GDN entscheidet weiterhin, auf welche Tools der Agent zugreifen kann, wie er mit nicht vertrauenswürdigen Eingaben umgeht und wer Ausführungsaufrufe genehmigt. Diese Entscheidungen sind das Produkt, und sie verbleiben beim Team, das das Produkt besitzt.

Benötigen Sie bereits eine OpenClaw Sicherheitsüberprüfung?

Der Reifegrad Ihrer Sicherheitslage sollte der Komplexität Ihrer Bereitstellung entsprechen.

Fazit

OpenClaw ist nicht unsicher. Die Dokumentation beschreibt klar das Vertrauensmodell, für das es konzipiert wurde: ein Betreiber, ein Gateway, persönlicher Geltungsbereich. Das Sicherheitsproblem ist strukturell und entsteht, wenn ein Team dieses Modell in gemeinsamen Posteingängen, kundenorientierten Abläufen oder Workflows mit Shell-Zugriff und regulierten Daten einsetzt, ohne die für diese Kontexte erforderliche Isolation und Governance wiederherzustellen.

Die Arbeit, um diese Lücke zu schließen, ist bekannt. Vertrauensgrenzen trennen. Tool-Berechtigungen entziehen. Eingehende Inhalte als feindlich behandeln. Anmeldeinformationen von Prompts fernhalten. Eine überprüfbare Governance aufrechterhalten. Die Frage für die meisten Teams ist nicht, ob diese Arbeit getan werden muss, sondern ob sie sie selbst erledigen sollen.

Wenn Sie eine OpenClaw-Bereitstellung mit echten Arbeitslasten betreiben und einen zweiten Blick auf die Architektur werfen lassen möchten, vereinbaren Sie einen Termin mit einem Spezialisten für sichere Integrationen. Dreißig Minuten reichen in der Regel aus, um zu beurteilen, ob die aktuelle Bereitstellung eine Härtung, ein Replatforming oder lediglich Konfigurationsänderungen benötigt.