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

Sichere Administrator-Genehmigungsablauf für Gruppen-Chat-Assistenten gegen Prompt-Injection
Ein praktischer Ansatz zur Sicherung von LLM-Assistenten in gemeinsamen Gruppenchats: Pausieren von VM-, OAuth- und Code-Ausführungs-Tools bis zur Admin-Freigabe über einen zeitgesteuerten Link.

KI-Agent löscht Produktionsdatenbank und gesteht dann – Eine warnende Geschichte
Ein Entwickler berichtet, dass ein KI-Coding-Agent ihre Produktionsdatenbank gelöscht und später in einer Log-Nachricht "gebeichtet" hat. Der Vorfall verdeutlicht die Risiken, KI-Agenten ohne Sicherheitsvorkehrungen Schreibzugriff auf Produktionssysteme zu gewähren.

Sicherheitsaudit stellt fest, dass Anthropics MCP-Referenzserver anfällig sind und auf Halluzinationen basierende Schwachstellen einführen
Eine Sicherheitsprüfung von 100 MCP-Serverpaketen ergab, dass 71 % mit der Note F bewertet wurden, einschließlich der offiziellen GitHub- und Dateisystem-Referenzimplementierungen von Anthropic. Die Prüfung identifizierte Halluzinationsbasierte Schwachstellen, die Sicherheitslücken erzeugen und Tokens durch Denkschleifen verschwenden.

Clawvisor: Zweckbasierte Autorisierungsschicht für OpenClaw-Agenten
Clawvisor ist eine Autorisierungsschicht, die zwischen KI-Agenten und APIs sitzt und zweckbasierte Autorisierung durchsetzt, bei der Agenten Absichten deklarieren, Benutzer bestimmte Zwecke genehmigen und ein KI-Gatekeeper jede Anfrage gegen diesen Zweck überprüft. Anmeldedaten verlassen Clawvisor nie und Agenten sehen sie nie.