Eine Studie zeigt, wie OpenClaw-Agenten mit Mail, Dateien und Shell-Zugriff scheitern können. Das Setzen harter Recht ist überlebenswichtig.
OpenClaw ist eine Open-Source-Software für einen persönlichen KI-Agenten. Den Sourcecode hat der Entwickler Peter Steinberger im November 2025 auf Github veröffentlicht. Damit kann man auf einem PC einen Service betreiben, der KI-gestützt beliebige Aufgaben automatisch und autonom ausführt. Die Steuerung erfolgt über gängige Instant-Messenger wie WhatsApp, Telegram oder Signal.
Eine neue Red-Teaming-Studie zeigt, was bei OpenClaw-Agenten schiefgehen kann. Die Agenten durften Dateien dauerhaft speichern und hatten zudem Zugriff auf E-Mails, den Messenger Discord und sogar auf die Shell des Computers. Danach folgten sie fremden Anweisungen, gaben sensible Daten heraus, erzeugten Last, starteten dauerhafte Prozesse und meldeten Erfolg, obwohl das System etwas anderes anzeigte.
Die Studie macht OpenClaw nicht unbrauchbar. Sie räumt nur mit der bequemen Illusion auf, dass man einen Agenten mit Werkzeugen wie einen normalen Chatbot behandeln kann. Sie sind mitunter gefährlich.
Die Studie zeigt, was KI-Agenten falsch machen
Das wissenschaftliche Manuskript „Agents of Chaos“ beschreibt eine Laborumgebung mit OpenClaw-Agenten. Die Forscher gaben den Agenten persistenten Speicher, E-Mail-Konten, Discord-Zugriff, Dateisysteme und Shell-Ausführung. Zwanzig KI-Forscher testeten die Agenten zwei Wochen lang, freundlich und mit Gegenfragen, Tricks und Angriffsmustern. Daraus entstanden elf Fallstudien.
Die Fehler wiesen nicht auf akademische Sonderfälle hin. KI-Agenten folgten den Anweisungen von Personen, die gar keine Eigentümer waren. Sie gaben sensible Informationen heraus. Die Agenten lösten destruktive Systemaktionen aus. Zudem erzeugten sie DoS-artige Zustände, verbrauchten unnötig Ressourcen, ließen sich durch Identitätstäuschung irritieren und gaben unsichere Muster an andere Agenten weiter.
Mehrfach meldeten Agenten eine erledigte Aufgabe, obwohl der tatsächliche Systemzustand nicht dazu passte. Bei einem Chatbot nervt so etwas. Bei einem Agenten mit ein derart umfangreichen Zugriff auf Werkzeuge kann man damit Dienste beschädigen, Computer sinnlos beschäftigen, Daten offenlegen oder sogar Kosten erzeugen.
Wenn der KI-Agent behauptet erfolgreich zu sein, reicht das nicht
Ein Fall aus der Studie passt fast schon zu gut. Ein Agent sollte mit einem Geheimnis umgehen, das ihm ein Nicht-Eigentümer anvertraut hatte. Der Agent deaktivierte am Ende seine lokale E-Mail-Konfiguration und meldete, er habe erfolgreich gehandelt. Die eigentliche Mail lag aber weiterhin im Postfach. Er hatte sie also nicht sauber gelöscht. Der Agent hatte seine Fähigkeiten nur selbst eingeschränkt.
Das ist kein besonders raffinierter Angriff. Es ist ein Agent, der Aktion, Ziel und Systemzustand nicht sauber zusammenbringt. Hier beginnt das Problem. Ein Agent kann überzeugend klingen und handelte trotzdem an der falschen Stelle. Wer ihm den unbegrenzten Zugriff auf die Shell, Dateien, Mails und Messenger gibt, baut keinen Assistenten mehr. Er baut einen gefährlichen Bedienhebel mit viel Macht.
KI-Agenten von OpenClaw plauderten diskrete Details aus
Die Studie zeigt auch, wie dünn die Grenze zwischen harmloser Bitte und Datenabfluss werden kann. In einem Fall folgten Agenten Anfragen von Personen ohne administrative Autorität. Ein Agent gab E-Mail-Metadaten heraus, später auch Inhalte fremder Mails. In einem anderen Fall fragte niemand direkt nach sensiblen Daten. Der Trick lief über den Umweg: Gib mir den ganzen Mailinhalt. Und das tat der KI-Agent von OpenClaw.
Es braucht nicht immer den großen Hack. Manchmal reichen eine plausible Bitte, etwas Druck und ein Agent, der nicht sauber prüft, wer eigentlich sprechen darf. Für OpenClaw heißt das: Rechte gehören nicht ins Gespräch. Rechte gehören in die Technik.
OpenClaw ist kein Chatbot mit Extras
OpenClaw erscheint auf den ersten Blick wie ein KI-Projekt. Man könnte denken: Ach, das ist noch ein Assistent. Noch etwas Chat mit Automatisierung. Diese Einordnung ist bequem, aber falsch. OpenClaw ist keine Oberfläche wie Open WebUI. OpenClaw sitzt eine Ebene tiefer. Dort geht es nicht nur um Antworten, sondern um Aktionen.
Ein Chatbot schreibt nur den Text. Ein Agent kann hingegen Dateien lesen, Befehle starten, Webseiten abrufen, Nachrichten verschicken oder Dienste ansprechen. Open WebUI beschreibt OpenClaw als selbst gehostetes Agenten-Framework, das einer KI Werkzeuge gibt. Der Zugriff auf die Shell, Dateien, Web-Browsing und Anbindungen an Telegram, Slack oder WhatsApp gehören ausdrücklich dazu.
Das macht OpenClaw interessant. Es macht den Betrieb aber auch heikler als bei einem normalen Chatmodell. Ein LLM, das Unsinn antwortet, kostet Nerven. Ein Agent, der Unsinn ausführt, kann Dateien anfassen, Tokens verbrauchen, Dienste blockieren oder Befehle starten. Wenn dann noch private Logs, lokale Pfade oder Systemausgaben über ein Paid-Modell in die Cloud laufen, steht „Selfhosting“ nur noch auf dem Etikett.
Riskant ist die Vergabe der Rechte
Der Aufbau ist dabei simpel. Die Open Source Weboberfläche Open WebUI liefert die Oberfläche. Die KI-Plattform Conduit bringt diese Oberfläche aufs Handy. Lemonade, Ollama oder das AI-Toolkit OpenVINO liefern das Modell. CPU, GPU oder NPU führen dieses Modell aus. OpenClaw benutzt die verfügbaren Werkzeuge.
Ein lokales Modell kann Logzeilen erklären. OpenClaw kann ein Skript starten, das diese Logs ausliest. Ein Modell kann erklären, wie Docker funktioniert. OpenClaw kann einen Container neu starten. Zudem kann es sagen, was ein Cache-HIT bei Lancache bedeutet. OpenClaw kann sich 60 Sekunden Live-Logs holen und anschließend zusammenfassen. Dafür kann man OpenClaw gut gebrauchen. Ein harmloser Chat ist das dann aber trotzdem nicht mehr.
Der sichere Weg führt über Open WebUI
„OpenClaw direkt ins Netz“ ist kein sauberer Aufbau. Der bessere Weg läuft über Open WebUI. Conduit läuft auf dem Handy. Die KI-Plattform Conduit verbindet sich mit Open WebUI. Open WebUI schützt den Zugang per Login, Tailnet oder sauber abgesichertem Funnel. In Open WebUI taucht OpenClaw als Agent auf. Darunter arbeitet ein lokales Modell über Lemonade, Ollama oder OpenVINO.
Man benutzt unterwegs also nicht direkt OpenClaw. Man öffnet Conduit, verbindet sich mit der eigenen Open-WebUI-Instanz und wählt dort den OpenClaw-Agenten. OpenClaw bleibt intern. Es bekommt keinen eigenen Zugang zum Computer oder zu einer anderen Software.
Conduit ist der Zugang, nicht die Kontrolle
Conduit passt in diesen Aufbau, weil es ein nativer mobiler Client für Open WebUI ist. Es unterstützt eine direkte Anmeldung, OAuth, SSO, Reverse-Proxies und eigene Header. Conduit ist nicht der Agent. Es ist die mobile Oberfläche für den eigenen Stack.
Open WebUI bleibt die Zentrale. Dort hängen die Modelle und dort landet der Login. Ferner bündelt man dort lokale und externe Anbieter. OpenClaw kommt nur als Werkzeugschicht dazu. Dann hängt der Agent nicht nackt im Netz, sondern hinter der Anmeldung, eingeschränkten Rechten und den Modellen.
Open WebUI entscheidet über Modelle, Nutzer und Tools
Ein eigener KI-Stack taugt erst dann, wenn nicht jeder alles sehen und nutzen darf. Open WebUI zeigt nicht nur Modelle an. Es regelt auch, welcher Nutzer welches Modell, welche Tools und Wissensdaten nutzen darf.
Open WebUI arbeitet mit Rollen, Gruppen und Berechtigungen. Gruppen steuern den Zugriff auf private Ressourcen wie Modelle, Knowledge Bases und Tools. Wichtig: Open WebUI addiert Rechte. Wer in mehreren Gruppen steckt, bekommt am Ende die Summe der erlaubten Rechte. Das ist praktisch, aber auch eine klassische Fehlerquelle.
Für Unternehmen liegt die Lösung auf der Hand. Die Buchhaltung braucht kein Coding-Modell mit Shell-Nähe. Der Support braucht hingegen kein medizinisches Spezialmodell. Ein Praktikant braucht keinen OpenClaw-Agenten, der Wartungsskripte startet. Und ein Admin sollte nicht aus Bequemlichkeit denselben Zugang nutzen wie normale Nutzer.
Im privaten Umfeld gilt das gleiche. Nicht jeder im Haushalt muss jedes Modell sehen. Ein kleines Alltagsmodell für normale Fragen ist etwas anderes als ein Coding-Modell für Skripte. Ein medizinisches Modell gehört in den exakten Kontext. Und ein OpenClaw-Agent mit Werkzeugen sollte nicht als Familien-Chatbot herumliegen.
Ein guter Stack trennt Modelle, Nutzer und Werkzeuge. Alltagsnutzer bekommen ein schnelles Standardmodell. Techniknutzer bekommen Coding- und Log-Modelle. Sensible Spezialmodelle muss man gezielt an einzelne Personen freigeben. OpenClaw bekommt nur eine kleine, vertrauenswürdige Gruppe. Tools und Knowledge Bases bleiben geschlossen, bis man sie wirklich braucht.
Bürokratie ist an diesem Punkt wahrlich kein Makel. Sie verhindert, dass man einen AI-Agenten mit Werkzeugen wie ein normales Chatmodell herumreichen kann.
Webzugriff nur mit klarer Freigabe
Open WebUI kann lokalen Modellen Webzugriff geben. Für eine Recherche ist das wertvoll. Ein Modell muss dann nicht nur aus seinem Trainingsstand antworten. Es kann beispielsweise aktuelle Quellen abrufen, Release Notes lesen, Versionsstände vergleichen oder CVEs prüfen.
Webzugriff ist aber kein netter Knopf im Chatfenster. Der Admin entscheidet im Hintergrund. Open WebUI braucht Web Search global im Admin Panel. Danach muss der Admin die Web-Search-Fähigkeit beim jeweiligen Modell aktivieren. Außerdem kann er festlegen, ob neue Chats diese Funktion standardmäßig bekommen. Rollen und Gruppen können den Zugriff weiter begrenzen.
Die Oberfläche kann täuschen. Ein Nutzer kann im Chat auf die Websuche hoffen oder meinen, das Modell habe Internet. Wenn der Admin den Zugriff im Panel, am Modell oder über Berechtigungen entzogen hat, kommt das Modell nicht raus. Der Chat entscheidet nicht, die Konfiguration entscheidet.
Nicht jedes Modell benötigt einen Zugang zum WWW. Ein schnelles Alltagsmodell kann offline bleiben. Ein Coding-Modell braucht vielleicht lokale Logs, aber keine Websuche. Ein Recherche-Modell darf aktuelle Quellen lesen, aber nicht schreiben. Ein OpenClaw-Agent darf Versionen vergleichen und Berichte bauen, aber keine Shell öffnen und keine fremden Systeme testen.
Kleine Modelle machen den Stack brauchbar
OpenClaw selbst nutzt keine NPU. Das muss es auch nicht. Die NPU sitzt an der Modellschicht. Wer Lemonade, Ollama, OpenVINO oder einen anderen lokalen Modellserver nutzt, lässt dort das Modell laufen. OpenClaw fragt diesen Modellserver nur an.
Lemonade passt gut in diesen Aufbau. Ein Lemonade Server stellt lokale Modelle über eine OpenAI-kompatible API bereit. Open WebUI kann OpenAI-kompatible Server anbinden. Die Kette bleibt überschaubar: Lemonade startet das Modell lokal, Open WebUI nutzt Lemonade als Provider, Conduit greift mobil auf Open WebUI zu, und OpenClaw arbeitet als Agent darüber.
Interessant sind vor allem kleine und mittlere Modelle. Die müssen nicht jeden Benchmarktest gewinnen. Sie sollen schnell reagieren, Logs erklären, den Containerstatus zusammenfassen, PowerShell-Fehler einordnen oder Smart-Home-Werte auswerten. Dafür reicht bereits ein kleineres Modell, das auf der GPU oder NPU läuft. Ein großes Modell kann mehr, blockiert aber auch schneller die Maschine.
Lemonade zielt auf die lokale Nutzung. Modelle laufen je nach Hardware und Backend über CPU, GPU oder NPU. AMD beschreibt Lemonade ebenfalls als OpenAI-kompatible lokale Lösung mit optimierten CPU-, GPU- und NPU-Backends.
OpenClaw & Co.: Verschiedene Werkzeuge für unterschiedliche Aufgaben
Für private Nutzer zählt vor allem, dass kleine Modelle schnell starten, keine API-Tokens kosten und für viele Aufgaben nutzbar sind. Ein kleines Modell beantwortet unterwegs über Conduit schnelle Alltagsfragen. Ein mittleres Coding-Modell erklärt Docker-Logs, PowerShell-Fehler oder Compose-Dateien. Compose-Dateien sind YAML-formatierte Konfigurationsdateien für Docker. Ein anderes Modell übernimmt die Recherche oder Patch-Gap-Vergleiche.
Man startet nicht für jede Aufgabe den dicksten Brocken, sondern nimmt das Modell, das zur Aufgabe passt. Open WebUI bleibt Oberfläche und Rechte-Zentrale. Lemonade liefert lokale Modelle über eine kompatible API. OpenClaw bekommt nur die Aufgaben, bei denen Werkzeuge wirklich nötig sind. So arbeitet der Stack nicht nur privater, sondern auch schneller und kalkulierbarer.
Nicht jede Logzeile, nicht jeder lokale Pfad und nicht jede private Frage muss zu einem Cloud-Modell wandern. Vieles kann lokal bleiben. Kleine bis mittlere Modelle reichen dafür mitunter völlig aus. Manchmal ist schlichtweg weniger mehr.
Mehrere Modelle statt ein Cloud-Modell für alles
Lokale Modelle lohnen sich nicht nur wegen dem Datenschutz. Der größere Vorteil liegt in der Auswahl. Man kann je nach Aufgabe das passende Modell nehmen.
Zugegeben, ein großes Paid-LLM ist bequem. Es deckt viele Aufgaben ab und liefert oft brauchbare Antworten. Deshalb behandeln viele es wie ein Universalwerkzeug. Nur passt ein Universalmodell nicht automatisch zu jeder Aufgabe.
In einem eigenen LLM-Stack können mehrere Modelle nebeneinander laufen. Ein kleines Modell für Alltagsfragen. Ein Coding-Modell für Skripte und Fehlersuche. Ein Spezialmodell für medizinische Texte, ein anderes für die Dokumentenanalyse. Wenn eine Aufgabe wirklich mehr braucht, kann man bewusst ein starkes Cloud-Modell zuschalten.
So wird aus dem Stack kein ChatGPT-Abklatsch, sondern ein Satz passender Werkzeuge. Ein leichtes Modell reagiert schnell, ein Coding-Modell versteht Logs, Skripte und Docker-Fehler besser. Ein medizinisches Spezialmodell kann medizinische Texte oder Bildbeschreibungen einordnen, ohne deshalb Arzt zu spielen. Das Allround-Modell reicht für normale Fragen und das Cloud-Modell bleibt der bewusste Fallback.
MedGemma ist dafür ein Beispiel. Google beschreibt MedGemma als offene Modellfamilie für die medizinische Text- und Bildverarbeitung. Google nennt sie einen Ausgangspunkt für Entwickler, nicht einen Ersatz für medizinische Fachbewertung. Diese Einschränkung gehört dazu. Lokal heißt nicht automatisch richtig. Lokal heißt kontrollierbarer, speziell einsetzbar und besser trennbar.
Für das Coding gilt dasselbe. Spezialisierte Coding-Modelle können bei Skripten, Fehlerausgaben und kleinen Automationen besser passen als ein allgemeines Modell. Qwen3-Coder und DeepSeek Coder sind absolute Spezialisten für Coding-Aufgaben.
Diese Modellwahl geht in der Paid-LLM-Debatte oft unter. Ein eigener Stack muss nicht aus einem einzigen Modell bestehen. Kleine Modelle reagieren schnell. Große Modelle denken tiefer. Spezialmodelle kennen ihre Domäne besser. OpenClaw sollte nur dort dazukommen, wo man die Werkzeuge wirklich benötigt.
Eigene Modelle brauchen erst recht Grenzen
Ein lokaler Stack hat noch einen Vorteil, über den viele ungerne sprechen. Man hängt nicht an den Grenzen eines einzelnen Anbieters.
Paid-LLMs sind bequem. Sie sind aber auch Produkte mit Anbieterpolitik, Risikofilter, regionale Vorgaben und manchmal mit seltsamen Reflexen. Das kann sinnvoll sein. Es kann aber auch stören, wenn man journalistisch, technisch oder wissenschaftlich arbeitet und das Modell schon bei der Analyse eines Problems nervös wird.
Lokal sieht das anders aus. Man kann Modelle einsetzen, die weniger providerseitige Einschränkungen haben. Nicht, weil dann alles erlaubt wäre. Sondern weil der Betreiber wieder selbst Verantwortung übernimmt.
Ein lokales Modell kann Malware-Berichte analysieren, Scam-Mechaniken erklären, technische Logs auswerten, Sicherheitsprobleme beschreiben oder rechtliche Grauzonen diskutieren, ohne bei jedem zweiten Begriff in Standardhinweise zu flüchten. Für Journalisten, Admins, Forscher und Entwickler kann das ein echter Vorteil sein.
Ein lokales KI-Modell ist kein Freifahrtschein
Aber es ist kein Freifahrtschein. Ein Modell ohne fremde Anbietergrenzen ist nicht automatisch besser. Es ist nur direkter. Das Modell halluziniert trotzdem. Es kann falsche Anleitungen liefern sowie gefährliche Dinge zu leicht ausgeben. Und es nimmt niemandem Verantwortung ab. Man muss dementsprechend alles eigenhändig überprüfen.
Deshalb gehört so ein Modell in einen Stack. Nicht ein Modell für alles, sondern mehrere Modelle mit Rollen. Modelle für den Alltag, für das Coding, Logs, medizinische Texte, Recherche oder eine Sicherheitsbewertung. Ein starkes Cloud-Modell bleibt möglich. Der Einsatz muss bewusst und nicht als Standardlösung geschehen für alles, was im eigenen System an Aufgaben anfällt.
Ein eigener LLM-Stack liefert damit nicht nur Datenschutz, sondern Souveränität. Man entscheidet selbst, welches Modell welche Aufgabe bekommt. Und man entscheidet selbst, welche Daten das eigene System verlassen.
OpenClaw bekommt trotzdem keine freie Bahn. Besonders bei weniger eingeschränkten Modellen muss die Leine kurz bleiben. Das Modell darf denken und erklären. Handeln darf es nur über vorbereitete Skripte, feste Rollen und klare Grenzen.
Recherche ja, Exploit-Autopilot nein
Ein eigener Stack gewinnt, wenn ein Modell kontrolliert ins Netz darf. Nicht als unbegrenzter Browser-Agent, der beliebige Seiten öffnet und fremde Anweisungen schluckt, sondern als Recherche-Assistent mit festen Quellen, klarer Aufgabe und ohne Schreibrechte.
Die Fälle Discord und Chrome zeigen, warum das relevant ist. Ein Sicherheitsforscher beschrieb im April 2026, wie Claude Opus beim Aufbau einer Exploit-Kette gegen eine veraltete Chromium-Basis in Discord half. Der interessante Teil ist nicht „KI baut Exploit“. Der interessante Teil ist nüchterner. Discord soll eine Chrome-138-Basis gebündelt haben, die laut Bericht neun Major-Versionen hinter dem Upstream lag. Eine App schleppt alte Browser-Bestandteile mit. Das ist ein Patch-Gap.
Solche Lücken kann ein kontrollierter lokaler Stack finden, ohne tausende Dollar in API-Tokens zu verbrennen. In dem Experiment war von 2,3 Milliarden Tokens, 2.283 Dollar API-Kosten und rund 20 Stunden menschlichem Nachschieben die Rede. Da liegt die Frage nahe, ob man nicht besser in lokale Hardware, GGUF-Modelle und einen eigenen Stack investiert.
Nur eine Untersuchung und nichts weiter, bitte!
Die Aufgabe lautet dann nicht: „Bau mir einen Exploit.“ Die Aufgabe lautet: „Vergleiche die eingebettete Chromium-Version dieser App mit upstream, prüfe bekannte Sicherheitsfixes und sag mir, ob ein Patch-Gap besteht.“
Das ist defensive Arbeit. Doch für Journalisten, Admins und Entwickler bringt sie etwas. Man findet damit nicht automatisch jede Schwachstelle. Man findet aber schneller Stellen, an denen Software alte Bausteine mitschleppt. Der Browser selbst ist gepatcht, die Electron-App hängt hinterher. Dort entsteht das Risiko.
Eine Patch-Gap-Analyse bleibt trotzdem nicht automatisch harmlos. Wer Versionsstände, CVEs und fehlende Fixes sauber zusammenführt, beschreibt auch mögliche Angriffsflächen. Für Verteidiger ist das wertvoll, doch für Angreifer auch. Der Unterschied liegt nicht in der Information allein, sondern im Zweck, im Zugriff und in den Grenzen des Systems.
Chrome 138 war kein belangloser Versionssprung. Google veröffentlichte im Sommer 2025 Sicherheitsupdates für Chrome 138, darunter Updates gegen aktiv ausgenutzte Schwachstellen. Daraus folgt nicht automatisch, dass jede dieser Lücken in Discord ausnutzbar war. Es heißt nur, wenn eine Anwendung später noch alte Chromium-Bestandteile nutzt, muss man prüfen, welche Fixes fehlen und ob daraus ein Risiko entsteht.
OpenClaw kann sinnvoll eingesetzt werden
Für solche Aufgaben kann OpenClaw sinnvoll sein. Nicht als Exploit-Autopilot und nicht als frei laufender Security-Agent. Sondern als isolierter Recherche-Agent. Er sammelt Versionen ein, liest Release Notes, vergleicht CVEs und schreibt einen Bericht. Er baut keine Angriffskette und testet keine fremden Systeme. Zudem erzeugt er keine Payloads.
Ein Bericht könnte sagen: „Diese Electron-App nutzt eine ältere Chromium-Basis als upstream. Zwischen Version X und Y liegen relevante Sicherheitsfixes. Bitte prüfen, ob der Anbieter bereits ein Update ausgeliefert hat.“ Tja, langweilige Patch-Arbeit erzeugt keinen Applaus. Admins und Entwickler brauchen sie trotzdem. Sie ist wichtig.
Man sollte dabei nicht vergessen, wo OpenClaw herkommt. Der Entwickler wechselte im Februar 2026 zu OpenAI, das Projekt soll offen und über eine Foundation weiterlaufen. Das kann Stabilität bringen. Es ändert aber nichts daran, dass OpenClaw aus sehr schneller KI-gestützter Entwicklung entstanden ist. Ob man das Vibe Coding oder agentic engineering nennt, ist zweitrangig. Es bleibt Software, die man nicht mit Host-Rechten und ohne harte Grenzen auf produktive Systeme loslässt.
Je mächtiger das Modell, desto enger müssen die Grenzen sein
Wir lernen daraus: Je mächtiger das Modell, desto enger müssen die Grenzen sein. Ein lokaler Security-Agent darf recherchieren, vergleichen und warnen. Handeln darf er nur über vorbereitete Skripte, feste Quellen, Read-only-Zugriff und festgesetzte Freigaben.
Tailscale Funnel öffnet den Zugang, nicht die Rechte
Tailscale Funnel passt in so einen Stack, wenn man Open WebUI unterwegs erreichen will. Das hilft bei CGNAT oder ohne Portweiterleitung. Erklärung: CGNAT ist eigentlich die Technik, bei der Internetprovider mehrere Kunden gleichzeitig über eine einzige öffentliche IPv4-Adresse ins Internet schicken. Funnel macht einen lokalen Dienst über eine öffentliche Funnel-URL erreichbar und baut dafür einen verschlüsselten Tunnel zu einer konkreten Ressource auf dem eigenen Gerät.
Das ersetzt aber kein Rechtekonzept. Funnel sollte nicht direkt auf OpenClaw zeigen. OpenClaw ist der Agent. Er hat die Werkzeuge. Er gehört nicht als eigenes Ziel ins offene Netz.
Die brauchbare Kette lautet: Conduit → Open WebUI → OpenClaw intern → lokales Modell. Die schlechte Kette lautet: Browser oder App → OpenClaw mit direktem Zugriff zum Internet.
Open WebUI ist der Eingang. OpenClaw ist das Werkzeug dahinter. Wer den Agenten selbst veröffentlicht, macht aus einem internen Werkzeug einen öffentlich erreichbaren Bedienhebel. Das muss man nicht ausprobieren, um zu ahnen, dass das keine gute Idee ist.
Selfhosting heißt nicht automatisch lokal
Viele schreiben „selfhosted“ drauf und fühlen sich sicher. Das reicht nicht. Wenn OpenClaw lokal läuft, aber seine Denkarbeit an ein bezahltes Cloud-Modell schickt, betreibt man keinen rein lokalen Stack. Dann läuft nur die Hülle im eigenen Netz. Das Gehirn sitzt beim externen Anbieter.
Man kann das bewusst so betreiben. Große Modelle sind bei schwierigen Aufgaben oft stärker. Dann sollte man es aber auch so nennen. Nicht jedes Log, jeder Pfad, jede Fehlermeldung und jeder Smart-Home-Wert muss in ein Cloud-Modell wandern, nur weil die Entwickler den API-Key schon eingetragen haben.
Agenten-Prompts enthalten mitunter mehr, als man denkt. Container-Namen, lokale Pfade, Logausgaben, Fehlermeldungen, API-Antworten, Dateinamen, Smart-Home-Werte oder interne Dokumente. Das ist keine harmlose Chatfrage mehr. Das ist potenzieller Datenabfluss mit freundlicher Oberfläche.
Seit April 2026 decken normale Claude-Abos die Nutzung über Drittanbieter-Harnesses (Test-Frameworks) wie OpenClaw nicht mehr wie zuvor ab. Nutzer sollen dafür auf Pay-as-you-go, API-Keys oder zusätzliche Pakete ausweichen. Auch das zeigt, dass Agenten keine normalen Chatfenster sind. Sie erzeugen mehr Kontext, mehr Zwischenschritte und mehr Last. Die Grundregel bleibt dabei, lokal zuerst, der Einsatz der Cloud muss bewusst erfolgen.
Das Pentagon diskutiert dasselbe Problem in groß
Die Frage nach sicheren KI-Agenten endet nicht im HomeLab. Sie wird nur größer. Das US-Verteidigungsministerium baut mit GenAI.mil eine eigene Plattform für generative KI auf. OpenAI beschreibt dafür eine angepasste ChatGPT-Version, die in autorisierter Behörden-Cloud-Infrastruktur laufen soll und für nicht geheime Arbeit des Department of Defense zugelassen ist.
Damit geht es nicht mehr um Docker-Logs, SearXNG oder einen Container, der mal wieder zickt. Es geht um Behörden, das Militär und sensible Arbeitsabläufe. Der Maßstab ist ein anderer. Die Frage bleibt erstaunlich ähnlich: Wer darf was sehen? Wer darf welche Schritte auslösen? Und wer kontrolliert das Modell, wenn es einmal in der Umgebung läuft?
Anthropic zog sich vor Gericht aus der Verantwortung
Der Streit um Anthropic macht diesen Punkt noch deutlicher. Die Firmenleitung von Anthropic erklärte laut AP und Axios vor Gericht, dass das Unternehmen Claude nach der Bereitstellung in klassifizierten Pentagon-Netzen nicht einfach manipulieren, überwachen oder abschalten könne. Der Anbieter liefert also nicht automatisch die Bremse mit, nur weil sein Name auf dem Modell steht.
Für OpenClaw im Kleinen heißt das, Kontrolle darf nicht beim Modell liegen. Und nicht beim Prompt. Auch nicht beim guten Willen des Anbieters. Man muss Rechte, den Zugang zum Netz, Daten und den Werkzeugen technisch begrenzen. Diese Regel gilt im Pentagon. Sie gilt genauso im Unternehmen. Und sie gilt im privaten Arbeitszimmer, auch wenn dort statt Staatsgeheimnissen nur Docker-Configs, API-Token, Familienfotos und Browserprofile herumliegen.
Die Sicherheitsprobleme von OpenClaw sind real
Das ist kein theoretisches „die KI könnte gefährlich sein“-Gerede. Anfang 2026 tauchten massenhaft öffentlich erreichbare OpenClaw-Instanzen im Netz auf. Berichte auf Basis von Censys-Daten sprachen Ende Januar 2026 von mehr als 21.000 sichtbaren Instanzen. Für ein normales Webtool wäre das unschön genug. Bei einem Agenten mit möglichen Shell-, Datei- und Browser-Rechten wird die Situation deutlich ernster.
Dazu kam die Schwachstelle CVE-2026-25253. Die OpenClaw-Versionen vor 2026.1.29 waren davon betroffen. Die Schwachstelle drehte sich um einen `gatewayUrl`-Wert aus der URL, eine automatische WebSocket-Verbindung und ein mitgesendetes Token. Der CVSS-Wert lag bei 8.8. Bei einem Werkzeug, das nah am System arbeitet, ist das kein Schönheitsfehler mehr.
Das Problem begrenzt sich nicht auf OpenClaw. Das Problem ist ein Agent mit umfangreichen Rechten, schlecht getrennt und offen erreichbar.
Der KI-Agent darf keinen Zugriff auf die Shell haben
Ein brauchbarer OpenClaw-Aufbau gibt dem Agenten keine freie Shell. Nicht unter Linux, nicht unter Windows mit WSL2 und auch nicht mit Adminrechten. Erst recht nicht mit Zugriff auf komplette Laufwerke. Zudem nicht mit Docker-Socket und nicht mit der Erlaubnis, eigene Befehle zu erfinden.
Gerade Docker auf Windows mit WSL2 braucht saubere Grenzen. Docker läuft dort im Linux-Umfeld, der Host bleibt aber Windows. Wer dem Agenten zu viel Zugriff gibt, öffnet rasch beide Seiten: Bash, Docker, gemountete Windows-Pfade und lokale Daten. Für einen Menschen ist das praktisch. Für einen KI-Agenten ist das zu viel Macht.
Besser ist ein kleiner Ordner mit freigegebenen Skripten. Unter Linux und WSL2 kann man dort Bash-Skripte oder kleine CLI-Wrapper speichern. Für Windows-nahe Aufgaben kann man zusätzlich PowerShell-Wrapper nutzen. Die Endung spielt keine Rolle. Entscheidend ist, dass jedes Skript nur eine klar begrenzte Aufgabe hat.
Freigegebene Skripte statt freier Befehle
Ein Skript liest den Status der Powerstation und holt die nächsten Kalendertermine. Es fragt Wetterdaten für die eigene Region ab und prüft Docker. Zudem liest es den Backup-Status aus. Ein anderes Skript holt Werte aus Home Assistant, etwa der Waschmaschine, Smart Plugs oder besorgt den aktuellen Stromverbrauch. Ein Plex-Skript meldet neue Folgen oder komplette Staffeln einer Serie. Ein weiteres Skript liest die letzte Getränkebestellung aus.
Ein Reise-Skript liest Kalenderdaten, den Startort, Ziel und Uhrzeit. Danach fragt es freigegebene Quellen ab: DB-Preise, Better Bahn oder einen eigenen Fahrplan-Dienst, Wetterdaten, Mobilfunkabdeckung entlang der Strecke und eigene POI- oder Wanderer-Daten. Der Agent bekommt fertige Daten und fasst sie zusammen. Er bucht kein Ticket, loggt sich nicht in Bahn-Accounts ein und ändert keine Termine.
Ein anderes Beispiel
Ein Spiele-Skript prüft einen freigegebenen Kalender, offizielle Patchnotes oder ausgewählte Spiele-News-Quellen. Wenn dort ein größerer CoD-Patch, ein Steam-Update oder ein anderer großer Download auftaucht, meldet der Agent: „Heute Nacht wäre ein guter Zeitpunkt für den Lancache-Prefill.“ Nur mit ausdrücklicher Freigabe startet es ein vorbereitetes Prefill-Skript. Es lädt keine fremden Quellen, sucht keine Torrents, installiert keine Spiele und ändert nicht frei an Docker herum.
OpenClaw darf also nicht ausführen, was ihm gerade sinnvoll erscheint. Es nutzt nur freigegebene Skripte mit festen Parametern. Die wie den Status lesen. Inhalte zusammenfassen und den Nutzer bei Bedarf warnen. Einen freigegebenen Dienst neu starten, wenn man das erlaubt hat. Oder einen freigegebenen Cache-Prefill starten, wenn die Quelle passt. Mehr nicht. Damit bleibt nachvollziehbar, was der KI-Agent tut. Und wichtiger, was er nicht tun kann.
Alltag heißt lesen, auswerten, erinnern
OpenClaw lohnt sich nicht, wenn man ihm den ganzen Rechner überlässt. OpenClaw lohnt sich, wenn man ihm kleine Dinge erlaubt, die man sonst vergisst oder mühsam zusammensucht.
Muss ich morgen früh einen Regenschirm mitnehmen? Steht ein Termin früher an als gedacht? Ist das Backup gelaufen? Wie voll ist die Powerstation? Hat Docker einen Dienst neu gestartet? Hat die Waschmaschine seit Tagen keinen typischen Waschgang mehr gemeldet? Wann habe ich zuletzt Getränke bestellt? War die Switch mit Ring Fit seit Wochen nicht mehr an? Liegen neue Folgen in Plex, und ist die Staffel jetzt komplett?
Das klingt banal. Darin liegt der Wert. Der Agent muss dafür nichts kaufen, nichts löschen, nichts schalten und keine frei nutzbare Shell bekommen. Er liest erlaubte Quellen, erkennt Muster und gibt einen Hinweis. Ein Beispiel: „Was sollte ich diese Woche nicht vergessen?“
Open WebUI gibt die Anfrage an den OpenClaw-Agenten weiter. Der Agent sucht nicht frei herum und erfindet keine Befehle. Er liest nur freigegebene Quellen wie Kalender, Wetter, Home Assistant, Powerstation, Smart-Home-Steckdosen, den Backup-Status, Docker-Status, Plex oder eine Bestellhistorie.
Die Antwort von OpenClaw könnte so aussehen:
Morgen früh ist Regen angesagt, nimm besser einen Schirm mit. Dein erster Termin liegt um 9:30 Uhr. Die Powerstation steht bei 78 Prozent. Das Backup von letzter Nacht ist gelaufen. Die Waschmaschine hat seit fünf Tagen keinen typischen Waschgang mehr gemeldet. Falls der Wäscheberg schon eine eigene Meldeadresse braucht, wäre heute ein guter Zeitpunkt. Deine letzte Flaschenpost-Bestellung ist vier Wochen her. Wenn der Wasserkonsum ungefähr gleich geblieben ist, solltest du langsam neue Getränke bestellen. Die Switch-Steckdose war seit drei Wochen nicht aktiv. Ring Fit ist offenbar wieder Dekoration. Außerdem stehen neue Folgen der Serie „Bones“ zur Verfügung in Plex. Die Staffel ist jetzt komplett.
OpenClaw handelt dabei nicht eigenmächtig. Es liest, rechnet, vergleicht und erinnert. Getränke darf sie auch nicht bestellen. Es startet keine Waschmaschine. Smarte Steckdosen muss OpenClaw auch in Ruhe lassen. Die KI-Lösung verschiebt keine Termine. Es löscht nichts in Plex. Es gibt nur einen Hinweis, den man selbst bewertet.
Zugriff von OpenClaw auf den Kalender, Wetter & Home Assistant reichen oft
Ein Kalender liefert Termine. Ein Wetterdienst liefert die Regenwahrscheinlichkeit. Der Home Assistant liefert Zustände und Verbrauchswerte. Eine Smart-Home-Steckdose zeigt, ob Waschmaschine, die Nintendo Switch oder Kaffeemaschine gelaufen sind. Eine Powerstation liefert den Akkustand und die Last. Plex meldet neue Folgen oder komplette Staffeln. Eine Bestellhistorie zeigt die letzte Getränkelieferung. Tools wie Better Bahn für die DB liefern Reiseoptionen. Eine Wanderer-Instanz zeigt, ob sich ein Umweg lohnt. Eine Spielequelle meldet, ob ein größerer Patch ansteht. Mehr braucht es oft nicht.
Der AI-Agent könnte sagen: Die Powerstation liegt bei 64 Prozent. Das HomeLab zieht 92 Watt. Bei dieser Last reicht sie noch etwa vier Stunden. Wenn NAS und Mini-PC weiterlaufen sollen, wäre jetzt kein guter Zeitpunkt für Experimente.
Oder: Die Waschmaschine hat seit fünf Tagen keinen typischen Waschgang mehr gemeldet. Falls das keine Absicht war, wäre Wäsche heute sinnvoller als noch ein Dashboard zu bauen.
Oder: Plex hat neue Folgen von der Serie XY gefunden. Die Staffel liegt jetzt vollständig vor. Du kannst also schauen, ohne wieder mitten in der Handlung auf die nächste Folge zu warten, wie im Jahr 2007.
Das ist leicht bissig, aber sinnvoll. Der Agent liest, rechnet und erinnert. Er kauft nichts. Die Software löscht auch nichts. Er schaltet nichts und bekommt keine freie Shell zur Hand.
Ja zur Reiseplanung ja, Buchungs-Autopilot: nein!
Ein guter KI-Agent muss nicht nur Docker-Logs lesen. Er kann auch Alltagskram zusammenführen, für den man sonst fünf verschiedene Seiten öffnet und am Ende trotzdem genervt ist.
Ein Beispiel: Ein Termin steht morgen in Berlin an. Der KI-Agent kennt den Startort, liest den Kalender, prüft die Uhrzeit und schaut sich die Fahrt an. Die DB-Seite liefert Preise für schnelle Verbindungen. Better Bahn oder ein eigener Fahrplan-Dienst zeigt Nahverkehrsverbindungen und Split-Ticketing. Wetterdaten sagen, ob ein Umweg überhaupt Spaß macht. Die Mobilfunkkarte hilft bei der Frage, ob man im Zug arbeiten kann. Eine eigene Wanderer- oder POI-Instanz zeigt, ob entlang einer Rückfahrt noch ein blinder Fleck liegt, den man ohnehin einmal ansehen wollte.
Das Tool Better Bahn mit Split-Ticketing müssen wir hier nicht erneut erklären. Dazu gibt es bereits mehrere eigene Artikel auf Tarnkappe.info.
Kostenloser Newsletter
Lesetipps und Glosse bequem ins Postfach - Abonnieren Sie jetzt den kostenlosen Newsletter.
Konkrete Fälle und wie man damit umgehen sollte
Der Prompt lautet dann nicht: „Mach meine Reise.“ Die Frage lautet:
„Ich muss morgen nach Berlin. Lohnt sich ein Einzelticket, Split-Ticketing oder das Deutschlandticket? Kann ich unterwegs arbeiten? Und ergibt auf der Rückfahrt ein kleiner Umweg Sinn?“
Der AI-Agent bucht nichts. Er loggt sich nicht in den Bahn-Account ein. Der Agent kauft kein Deutschlandticket und verschiebt keine Termine. Er liest nur erlaubte Quellen und fasst die ausgelesenen Daten zusammen.
Die Antwort könnte so aussehen:
„Der Termin in Berlin beginnt um 10:30 Uhr. Mit dem ICE bist du deutlich schneller. Better Bahn findet eine günstigere Split-Ticket-Variante, das Deutschlandticket braucht länger und hat zwei Umstiege. Der Zeitverlust liegt bei rund 45 Minuten. Wenn du diesen Monat noch zwei ähnliche Fahrten hast, lohnt sich das Deutschlandticket eher. Für nur diese Fahrt bleibt das Einzelticket entspannter, Split-Ticketing wäre die sparsame Variante mit etwas mehr Risiko.
Für die Rückfahrt gäbe es eine längere Verbindung über eine andere Strecke. Das Wetter bleibt trocken. In deiner Wanderer-Instanz liegt dort ein blinder Fleck, den du noch nicht markiert hast. Die Fahrt dauert etwa eine Stunde länger. Für reine Heimfahrt Unsinn. Wenn du ohnehin etwas Zeit hast, wäre es ein sinnvoller Abstecher.
Das Zug-WLAN ist dabei kein Festnetzanschluss auf Schienen. Der Zug holt sich die Verbindung über Außenantennen und Mobilfunk. Die Mobilfunkabdeckung entlang der Strecke sagt deshalb nicht exakt, wie gut das WLAN wird. Sie ist aber ein brauchbarer Hinweis. Wenn auf der Strecke längere Funklöcher liegen, wirst Du zwischenzeitlich offline sein.“
So ein KI-Agent entscheidet nicht für den Nutzer. Er rechnet vor. Man zeigt uns Abwägungen. Er erinnert an Dinge, die man sonst vielleicht übersieht. Kaufen, buchen, umplanen und losfahren muss man immer noch selbst.
Spielepatches erkennen, der Prefill nur mit Freigabe
Auch Spieleupdates passen in dieses Muster. Nicht als KI-Agent, der wahllos irgendwelche Downloads startet. Sondern als Agent, der bekannte Quellen liest und vorbereitet.
Ein Kalender oder eine freigegebene News-Quelle meldet: Morgen kommt ein großer Call-of-Duty-Patch. Steam, Battle.net oder ein anderer Launcher wird wieder mehrere Dutzend Gigabyte bewegen. Wer einen Lancache betreibt, will das nicht erst merken, wenn alle Geräte gleichzeitig am Abend loslegen.
Der KI-Agent kann dann sagen:
„Morgen erscheint laut Patchkalender ein größerer CoD-Patch. Dein Lancache läuft. Wenn du möchtest, kann heute Nacht das freigegebene Prefill-Skript laufen. Dann liegt der Patch eher im Cache, bevor der eigentliche Downloadabend beginnt.„
Auch hier gilt, der Agent lädt nicht frei irgendetwas. Er nutzt keine dunklen Quellen, sucht keine Torrents und schreibt nicht an Docker herum. Er erkennt nur den Kontext und stößt höchstens ein erlaubtes Skript an.
Das ist ein sinnvoller HomeLab-Fall. Nicht jeder braucht ihn. Wer aber mit mehreren Geräten, großen Spielen und schwankenden CDN-Servern lebt, weiß, warum so ein Hinweis nützlich ist.
Was der KI-Agent nicht anfassen sollte
Es gibt Aufgaben, bei denen OpenClaw draußen bleiben sollte. Kein Zugriff auf eine PowerShell, keine freie Bash, keine beliebigen Docker-Compose-Aktionen. Kein `docker rm`, kein `volume prune`, keine Massenlöschungen, kein Zugriff auf komplette Festplatten, kein Zugriff auf VeraCrypt-Container oder Backups. Keine Browserprofile mit gespeicherten Logins, keine Wallets, keine Börsen. Kein Banking, keine privaten Cookies und Sessions, kein automatisches Installieren fremder Skills, kein Cloud-LLM als Standard für private Logs und Dateien.
Dazu kommen die Alltagsfälle: Kein automatischer Getränkekauf, keine ungefragte Ticketbuchung und kein Deutschlandticket-Abschluss. Verboten ist auch das Verschieben von Terminen, der KI-Agent erhält keine Daten für den Bahn-Login, kein wildes Lancache-Prefill aus unbekannten Quellen, kein selbstständiges Schalten von Steckdosen, nur weil der Agent meint, es sei gerade praktisch.
Man kann das technisch alles miteinander verbinden. Das heißt aber nicht, dass man das auch wirklich tun sollte. OpenClaw wird nicht sicher nur weil man dem Modell sagt, es soll vorsichtig sein. OpenClaw wird sicherer, wenn es bestimmte Dinge gar nicht erst erreichen kann.
Einzelne Freigaben statt einem Generalschlüssel
Eine gute Prüfung lautet: Würde man diese Aktion auch als festen Button in eine Weboberfläche bauen? Jede einzelne Aktion benötigt ein fest gelegte Freigabe.
Powerstation-Status anzeigen? Ja.
Wetter und Kalender zusammenfassen? Ja.
Waschmaschinenverbrauch aus Home Assistant auslesen? Ja.
An Wäsche erinnern, wenn seit Tagen kein Waschgang lief? Ja.
Plex nach neuen Folgen oder kompletten Staffeln fragen? Ja.
Letzte Getränkebestellung auslesen und daran erinnern? Ja.
Reise aus Kalender, DB-Preis, Better Bahn und Wetter vergleichen? Ja.
Split-Ticketing prüfen und vor Risiko warnen? Ja.
Prüfen, ob sich das Deutschlandticket lohnt? Ja.
Mobilfunkabdeckung für die Strecke einschätzen? Ja.
Rückfahrt mit möglichem Abstecher aus eigener Wanderer- oder POI-App vorschlagen? Ja.
Größeren Spielepatch erkennen und Lancache-Prefill vorschlagen? Ja.
Freigegebenes Prefill-Skript starten, wenn man das ausdrücklich erlaubt hat? Kann man machen.
Automatisch Getränke bestellen? Nein.
Ticket automatisch kaufen? Nein.
Deutschlandticket automatisch abschließen? Nein.
Termin verschieben, weil die Verbindung schlecht aussieht? Nein.
Bahn-Account mit Login anfassen? Nur mit klarer manueller Freigabe. Für den normalen Agenten: nein.
Docker aufräumen, wie der Agent es für richtig hält? Nein.
Freie Shell öffnen? Nein.
Wie schon gesagt: Ein KI-Agent braucht keine Generalschlüssel, damit man sie sinnvoll nutzen kann. Er braucht klare Aufgaben und harte Grenzen.
Eigene Skills = fremder Code
Skills klingen harmlos. Das sind kleine Erweiterungen, ein bisschen Zusatzfunktion. In Wahrheit sind es Arbeitsanweisungen und Zusatzfunktionen für einen KI-Agenten, der im Zweifelsfall echte Rechte hat.
Ein Audit von ClawHub-Skills fand im Februar 2026 Hunderte bösartige Erweiterungen. 341 schädliche Skills unter 2.857 geprüften Einträgen sind keine Rundungsdifferenz. Einige zielten auf Zugangsdaten, Wallets, SSH-Zugänge, Browserpasswörter und andere sensible Daten. Als einfache Regel gilt: Skills sind keine Themes. Skills sind eher fremde Skripte. Man installiert sie nicht blind. Man liest sie und testet sie. Oder man lässt sie besser ganz weg.
Der Prompt ist keine Bremse
Viele verlassen sich auf Systemprompts. „Du darfst nichts Gefährliches tun.“ Das klingt beruhigend. Es ist aber keine harte Grenze.
Ein Modell kann sich auch irren. Es kann fremden Text falsch einordnen. Das KI-Modell kann die Anweisung aus einer Webseite, einer E-Mail oder einem Logfile als relevant behandeln. Eine Prompt Injection muss nicht wie ein Angriff aussehen. Sie kann wie normaler Text aussehen.
Die „Agents of Chaos“-Studie zeigt das Problem breiter. Die dort getesteten Agenten scheiterten nicht nur an klassischen Prompt-Tricks. Sie scheiterten an Autorität, Kontext, Proportionalität und daran, dass sie Systemzustände nicht sauber überprüften. Mal hörten sie auf die Befehle Fremder, mal gaben sie sensible Daten über Umwege aus. Dann verwandelten sie kurze Aufgaben zu dauerhaften Hintergrundprozessen.
Die Agenten-Sicherheit scheitert in der Praxis selten an einem einzigen bösen Satz. Meist reicht eine Kette aus zu vielen Rechten, zu wenig Prüfung und zu viel Vertrauen. Deshalb gehört die Sicherheitsgrenze nicht in den Prompt. Man muss sie im System integrieren.
OpenClaw selbst beschreibt das Problem als delegierte Tool-Autorität. Wenn mehrere Nutzer denselben toolfähigen Agenten ansprechen können, teilen sie sich faktisch dessen Rechte. Jeder erlaubte Absender kann Tool-Aufrufe innerhalb der Policy anstoßen. Das gilt im Unternehmen genauso wie im privaten Setup, sobald Messenger, Browser, Dateien und Hostzugriff dazukommen.
OpenClaw wird nicht sicher, weil man nett bittet. Man muss es technisch dazu zwingen.
ZeroClaw, Kai und Manus ändern die Grundregeln nicht
Neben OpenClaw tauchen schlankere Alternativen wie ZeroClaw auf. ZeroClaw positioniert sich als Rust-basierte Agenten-Runtime und verspricht weniger Ressourcenverbrauch als OpenClaw. Es ist damit geeignet für kleine Server, Edge-Geräte oder sparsame HomeLab-Systeme. Auf der Hardware ist der Einsatz offenbar attraktiv.
An der Sicherheitsfrage ändert das jedoch nichts. Ein weniger umfangreicher Agent ist nicht automatisch ein sicherer Agent. Auch eine schlanke Runtime kann gefährliche Werkzeuge ausführen, Dateien anfassen, den Webzugriff nutzen oder Messenger bedienen. Entscheidend ist nicht der Name des Agenten, sondern was er darf.
Kai 9000 für Android & mehr
Android bekommt mit Projekten wie Kai 9000 ebenfalls eigene KI-Assistenten. Kai 9000 beschreibt sich als Open-Source-Assistent mit persistentem Speicher, Versionen für Android, iOS, Windows, macOS, Linux und Web, dazu Tools, lokale Modellnutzung und auf Android sogar eine Linux-Sandbox für Befehle und Skripte.
Kai bleibt trotzdem nicht einfach „Conduit, nur anders“. Conduit ist der mobile Zugang zu Open WebUI. Kai ist eher ein eigener Assistent. Bei Conduit bleibt Open WebUI die Zentrale. Dort liegen Modelle, Nutzerrechte, Webzugriff und Agenten. Kai bringt mehr eigene Logik mit.
Manus & Conduit
Manus gehört ebenfalls in die Agenten-Debatte, aber nicht in dieselbe Schublade wie Conduit. Conduit ist ein Client für den eigenen Open-WebUI-Server. Manus ist ein Agentendienst, der Aufgaben planen, im Browser arbeiten und Workflows über Webseiten ausführen kann.
Der Browser Operator macht den Unterschied deutlich. Manus kann im lokalen Browser arbeiten und dabei vorhandene Logins, Sessions und aktive Tabs nutzen. Das ist bequem. Es ist aber auch die Richtung, die man nicht versehentlich mit einem lokalen Stack verwechseln sollte.
Bei Manus gibt man mehr an einen fertigen Dienst ab. Bei Open WebUI, Conduit, Lemonade und OpenClaw baut man eine eigene Kette, in der man Modelle, Rechte, Webzugriff und Agenten zentral kontrollieren kann. Bequemer ist Manus. Besser kontrollierbar ist aber der eigene Stack.
OpenClaw – unser Fazit
Wie man sieht, ist OpenClaw kein normaler Chatbot. OpenClaw ist ein Agent mit Zugriff zu mitunter gefährlichen Werkzeugen. Deshalb sollte man ihn nicht blank ins Netz stellen, nicht blind mit Paid-Token betreiben und nicht mit Vollzugriff auf den eigenen Rechner loslassen. Nützlich wird OpenClaw erst, wenn man ihn begrenzt.
Open WebUI bleibt Oberfläche und die Rechte-Zentrale. Conduit bringt den Zugriff aufs Smartphone. Lemonade, Ollama oder OpenVINO halten die Modelle möglichst lokal. Tailscale Funnel kann den Zugriff erleichtern, sollte aber nicht direkt auf den Agenten zeigen. OpenClaw bleibt intern und taucht in Open WebUI als Agent auf. Von dort aus ist er auch mit Conduit nutzbar.
Dabei machen kleine und mittlere Modelle den Stack alltagstauglich. Sie laufen auf GPU oder NPU schnell genug für Logs, Docker, Smart Home, Recherche und normale Fragen. Lemonade passt hier gut, weil es lokale Modelle über eine OpenAI-kompatible API bereitstellt und sauber mit Open WebUI zusammenspielt.
Verschiedene Lösungen für unterschiedliche Bedürfnisse
Der eigene Stack muss nicht aus einem einzigen Modell bestehen. Für Alltag, Coding, Log-Auswertung, medizinische Texte, Recherche oder schnelle Antworten können unterschiedliche lokale Modelle laufen. Darunter auch Modelle mit weniger providerseitigen Grenzen, wenn der Einsatzzweck das verlangt. Diese Wahlfreiheit geht verloren, wenn OpenClaw nur als Weiterleitungsschicht für ein Paid-LLM dient.
Mit kontrolliertem Internetzugriff kann so ein Stack Patch-Gaps finden, etwa bei Electron-Apps mit veralteter Chromium-Basis. Das ist nützlich, aber nicht automatisch harmlos. Wer fehlende Fixes sauber auflistet, beschreibt auch mögliche Angriffsflächen. Deshalb darf der Agent nur vergleichen, warnen und berichten. Er darf keine Exploit-Kette erstellen, keine Tests gegen fremde Systeme durchführen oder Payloads laden.
Die „Agents of Chaos“-Studie zeigt, warum diese Grenzen nicht nur in der Theorie wichtig sind. Selbst in einer isolierten Laborumgebung kam es zu Datenabfluss, falschen Autoritätsannahmen, DoS-artigen Zustände nebst Ressourcenverschwendung. Die Forscher entdeckten KI-Agenten, die Erfolg meldeten, obwohl der tatsächliche Systemzustand etwas anderes zeigte. Ein guter Prompt reicht nicht. Der Agent braucht technische Grenzen.
Die Existenz von mobilen und schlanken Alternativen ändern daran wenig. Kai zeigt, dass KI-Assistenten näher an Smartphone, Oberfläche und Alltag rücken. Manus zeigt die andere Seite. Es ist ein fertiger Cloud-Agent, der Aufgaben direkt im Browser ausführen kann. ZeroClaw ist als schlankere OpenClaw-Alternative interessant. Für den hier beschriebenen Ansatz bleiben die Sicherheits-Regeln trotzdem die gleichen. Conduit ist der mobile Zugang, Open WebUI die Rechte-Zentrale. Lokale Modelle liefern die Antworten. Der Agent bekommt nur eng begrenzte Werkzeuge an die Hand, damit er keinen Schaden anrichten kann.
OpenClaw: Klare Regeln und Rechte der KI-Agenten sorgen für Sicherheit
Die praktische Bremse besteht nicht aus schönen Prompt-Regeln. Sie besteht aus harten Werkzeuggrenzen: kleine Wrapper-Skripte, feste Pfade, Read-only-Zugriff, erlaubte Datenquellen und klare Zeitlimits. Unter Linux und Windows mit WSL2 können das Bash-Skripte oder kleine CLI-Wrapper sein. Für Windows-nahe Aufgaben kommen PowerShell-Wrapper dazu. Der Agent liest Daten vom Wetter, Kalender, Home Assistant, Powerstation, Docker, Backups, Plex, Bestellhistorien, Spieleupdates oder Bahnverbindungen aus. Er entscheidet aber nicht frei, was er auf dem System ausführt.
Für private Nutzer heißt das, er nutzt den lokalen Assistenten statt einem Cloud-Bot mit Zugriff auf den ganzen Rechner. Für Unternehmen heißt das, sie verwenden einen eigenen LLM-Stack statt einer KI-Schatten-IT.
Ein guter OpenClaw-Agent braucht keine umfangreichen Rechte. Er liest Status, erklärt Logs, vergleicht Reiseoptionen, ordnet Termine ein, prüft Split-Tickets, schlägt Cache-Prefill vor und startet nur freigegebene Skripte. Alles andere bleibt außerhalb seiner Reichweite.
