OpenClaw im Stresstest: Warum KI-Agenten harte Grenzen brauchen

Eine Studie zeigt, wie OpenClaw-Agenten mit Mail, Dateien und Shell-Zugriff scheitern können. Das Setzen harter Recht ist überlebenswichtig.

Die Studie zeigt, was KI-Agenten falsch machen

Wenn der KI-Agent behauptet erfolgreich zu sein, reicht das nicht

KI-Agenten von OpenClaw plauderten diskrete Details aus

OpenClaw ist kein Chatbot mit Extras

Riskant ist die Vergabe der Rechte

Der sichere Weg führt über Open WebUI

Conduit ist der Zugang, nicht die Kontrolle

Open WebUI entscheidet über Modelle, Nutzer und Tools

Webzugriff nur mit klarer Freigabe

Kleine Modelle machen den Stack brauchbar

OpenClaw & Co.: Verschiedene Werkzeuge für unterschiedliche Aufgaben

Mehrere Modelle statt ein Cloud-Modell für alles

Eigene Modelle brauchen erst recht Grenzen

Ein lokales KI-Modell ist kein Freifahrtschein

Recherche ja, Exploit-Autopilot nein

Nur eine Untersuchung und nichts weiter, bitte!

OpenClaw kann sinnvoll eingesetzt werden

Je mächtiger das Modell, desto enger müssen die Grenzen sein

Tailscale Funnel öffnet den Zugang, nicht die Rechte

Selfhosting heißt nicht automatisch lokal

Das Pentagon diskutiert dasselbe Problem in groß

Anthropic zog sich vor Gericht aus der Verantwortung

Die Sicherheitsprobleme von OpenClaw sind real

Der KI-Agent darf keinen Zugriff auf die Shell haben

Freigegebene Skripte statt freier Befehle

Alltag heißt lesen, auswerten, erinnern

Zugriff von OpenClaw auf den Kalender, Wetter & Home Assistant reichen oft

Ja zur Reiseplanung ja, Buchungs-Autopilot: nein!

Konkrete Fälle und wie man damit umgehen sollte

Spielepatches erkennen, der Prefill nur mit Freigabe

Was der KI-Agent nicht anfassen sollte

Einzelne Freigaben statt einem Generalschlüssel

Eigene Skills = fremder Code

Der Prompt ist keine Bremse

ZeroClaw, Kai und Manus ändern die Grundregeln nicht

Kai 9000 für Android & mehr

OpenClaw - unser Fazit

Verschiedene Lösungen für unterschiedliche Bedürfnisse

OpenClaw: Klare Regeln und Rechte der KI-Agenten sorgen für Sicherheit

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........

© Tarnkappe