OpenClaw-Sicherheitsansatz unter Verwendung von LLM-Router und zrok Private Sharing

Ein Entwickler hat seinen Ansatz detailliert beschrieben, OpenClaw und einen LLM-Router mit einem einzigen Befehl in einer VM+Kubernetes-Umgebung auszuführen, wobei der Fokus auf der Bewältigung von Sicherheitsbedenken rund um "Little Lobster"-Agentensysteme liegt.
Sicherheitsproblem und erster Ansatz
Das Projekt entstand aus Bedenken hinsichtlich der Sicherheit von OpenClaw-ähnlichen Agentensystemen. Der Entwickler stellt fest, dass Sandboxing allein das grundlegende Sicherheitsproblem nicht löst: Solange der Agent Ausführungsberechtigungen hat, könnte eine einfache Skill-Injection etwas wie printenv aufrufen und alle injizierten API-Schlüssel offenlegen. Das Entfernen von Ausführungsberechtigungen würde etwa 90 % der Funktionalität eliminieren, und ohne das Injizieren eines LLM-API-Schlüssels kann der Agent das Modell überhaupt nicht aufrufen.
LLM-Router-Lösung
Der Entwickler erwog zunächst die Verwendung eines Service Mesh mit einem Sidecar zur Handhabung der Authentifizierungsheader-Injection, doch OpenClaws HTTPS-Erzwingung machte dies unpraktisch. Stattdessen wechselte er zur Verwendung eines LLM-Routers, der die API-Schlüssel-Injection auf Router-Ebene ermöglicht. Dieser Ansatz bietet den zusätzlichen Vorteil, dass Benutzer Konversationsprotokolle einsehen und eigene Überwachungs-Plugins erstellen können, wie z. B. die Verwendung von Claude Code, um den Agenten im Auge zu behalten.
Fernzugriff über zrok
Eine weitere Herausforderung war die Integration mit Kommunikations-Apps wie Slack oder Telegram, die das Injizieren von Tokens für den Fernzugriff erfordert. Die Lösung nutzt zrok Private Sharing, wodurch ein Remote-Host über privates Teilen auf den Admin-Chat des Agenten zugreifen kann, ohne auf Messaging-Apps angewiesen zu sein. Der Entwickler räumt ein, dass dies einige Fähigkeiten einschränkt – es ist ein Kompromiss. Vollständige Unterstützung für Kommunikations-Apps unter diesem Modell würde erfordern, dass das Gateway und der Agent in separaten Containern laufen, was noch nicht implementiert wurde.
Projektdetails
Dem Projekt wurde der chinesische Name "Xiao Long Xia" (小笼虾) gegeben, wobei das Zeichen "笼" von "xiaolongbao" (Suppenknödel) stammt. Die Implementierung führt OpenClaw und den LLM-Router mit einem einzigen Befehl in einer VM+Kubernetes-Umgebung aus.
📖 Read the full source: r/openclaw
👀 Siehe auch

Sicherheitsanalyse der Extraktion von OpenClaw-Komponenten für benutzerdefinierte KI-Agenten
Ein Entwickler analysierte den Quellcode von OpenClaw, um festzustellen, welche Komponenten sicher für den Einsatz in benutzerdefinierten KI-Agenten extrahiert werden können, und bewertete jede mit dem Lethal Quartet-Framework. Die Analyse zeigt erhebliche Sicherheitsrisiken in Komponenten wie Semantic Snapshots und BrowserClaw.

Sicherheitswarnung: Schadcode in LiteLLM könnte API-Schlüssel stehlen
Eine kritische Sicherheitslücke wurde in LiteLLM identifiziert, die API-Schlüssel offenlegen könnte. Nutzer von OpenClaw oder nanobot könnten betroffen sein und sollten die im Quelllink genannten GitHub-Issues prüfen.

Declawed: Ein fortschrittlicher gemeinschaftsgetriebener Malware-Scanner für ClawHub SKILL.md-Dateien
Declawed ist ein Sicherheitstool zum Scannen von SKILL.md-Dateien auf ClawHub, das Prompt-Injection, bösartige Inhalte und Informationsstealer erkennt, und dabei auf von der Community entwickelte Regelsets zurückgreift.

Zwei Ansätze zur Reduzierung des Datenleak-Risikos bei KI-Agenten
Ein Reddit-Beitrag beschreibt zwei Methoden für Entwickler, um zu kontrollieren, wohin ihre KI-Agenten-Daten fließen: entweder eigene API-Schlüssel direkt bei Anbietern wie OpenAI oder Anthropic verwenden, um Zwischenhändler auszuschalten, oder Open-Source-Modelle lokal mit Tools wie Ollama und OpenClaw ausführen.