Haftungsrisiko KI-Agent: Der gerade im Hype stehende Moltbot OpenClaw steht exemplarisch für die nächste Welle „persönlicher KI‑Agenten“, die nicht mehr nur Texte beantworten, sondern unseren digitalen Alltag komfortabel steuern sollen: Sie lesen Mails, bewegen Dateien, führen Shell‑Befehle aus, steuern Browser und automatisieren Arbeitsabläufe quer durch Messaging‑Dienste – bevorzugt auf einem bezahlbaren Rechner wie einem durchlaufenden Mac mini im eigenen Heimnetz.
Gleichzeitig aber zeigen Sicherheitsforschende bereits binnen weniger Wochen Hunderte offen im Netz stehende Instanzen, unsichere Protokolle und reale Angriffsversuche; die Euphorie über den „24/7‑Mitarbeiter im Wohnzimmer“ sollte daher als konkrete Risiko‑Debatte mit juristischem Einschlag gesehen werden.
Hinweis: Im Rahmen meines Aufsatzes zum LLM-Hacking (erschienen in KIR 2025, 374ff.) habe ich herausgearbeitet, dass die unten thematisierten Prompt Injections strafbare Handlungen sind. Der Beitrag wurde aktualisiert mit Blick auf neue Entwicklungen in Punkte Sicherheit und natürlich den erneuten Namenswechsel.
Worum es bei Moltbot geht
Moltbot (ursprünglich Clawdbot, nun teils als OpenClaw bezeichnet … mal sehen wie er nächste Woche heisst) ist ein selbstgehosteter KI-Agent, der als Hintergrundprozess auf Mac, Windows oder Linux läuft und sich mit Diensten wie WhatsApp, Telegram, Discord, Slack oder iMessage verbindet. Der Agent setzt auf große Sprachmodelle wie Claude oder GPT‑4 über API, kann aber auch lokale Modelle einbinden und speichert seine „Erinnerungen“ in Markdown‑Dateien auf dem lokalen Dateisystem, was eine persistente, über Monate fortlaufende Assistenz ermöglicht.
Der rasante Namenswechsel – ausgelöst durch eine Abmahnung von Anthropic wegen Markenrechtsverstößen – hat nicht nur zu Chaos im Ökosystem geführt, sondern auch Kriminelle angelockt: Während der Übergangsphase wurden GitHub-Organisationen und Social-Media-Handles von Betrügern besetzt, die Phishing-Seiten mit Malware einrichteten und gefälschte Updates verteilten, die API-Keys und Zugangsdaten exfiltrierten. Dies unterstreicht, wie virale Hypes (über 100.000 GitHub-Sterne in einer Woche) Supply-Chain-Angriffe begünstigen.
Die Attraktivität liegt in der Kombination aus Systemzugriff und Automatisierung: Der Agent durchsucht Ordner, liest Dokumente, führt Terminal‑Kommandos aus, verwaltet Git‑Repos, füllt Formulare im Netz aus und kann proaktiv handeln – etwa morgens automatisch Wetter, Kalender, E‑Mails und Tech‑News sammeln und als Briefing verschicken … oder nachts Builds überwachen und Fehlerberichte erstellen. Es entsteht damit ein immer präsenter, weitgehend unsichtbarer Middleware‑Layer zwischen Mensch, Betriebssystem und Internet, der – einmal eingerichtet – im Idealfall „vergessen“ werden kann, aber de facto zum mächtigsten Prozess im eigenen digitalen Haushalt wird.
Technische Angriffspunkte
Der aktuelle Hype fällt in eine Phase, in der die zugrundeliegende Infrastruktur ersichtlich unreif ist: Das von Moltbot genutzte Model Context Protocol (MCP) wurde teils ohne verpflichtende Authentifizierung ausgeliefert; Sicherheitsanalysen fanden mehr als tausend öffentlich erreichbare MCP‑Server ohne Zugangsschutz, von denen getestete Instanzen alle ohne Credentials ansprechbar waren. Damit reicht – zugegeben überspitzt dargestellt – ein falsch konfiguriertes Port‑Forwarding oder ein unbedacht aufgesetzter VPS, damit Dritte vollen Remote‑Zugriff auf das erhalten, worauf der Agent Zugriff hat: Dateisystem, Zugangsdaten, API‑Keys, Build‑Pipelines.
Hinzu kommt die Vertrauenskette bei Erweiterungen: Auf dem zugehörigen Skill‑Marktplatz wurden wohl in einem Proof‑of‑Concept manipulierte Pakete mit fingierten Downloadzahlen hochgeladen; mehrere hundert Entwickler installierten den Code, der problemlos SSH‑Schlüssel, Cloud‑Credentials oder ganze Codebasen hätte exfiltrieren können, weil heruntergeladener Code standardmäßig als vertrauenswürdig behandelt wird.
Parallel zeigen Experimente mit Prompt‑Injection‑E‑Mails, dass ein verwundbarer Agent durch versteckte Anweisungen dazu gebracht werden kann, jüngste E‑Mails automatisiert an Angreifer weiterzuleiten – vom Eingang der Mail bis zur unbemerkten Datenweitergabe in wenigen Minuten. In Summe verschiebt sich das Bedrohungsmodell: Nicht mehr nur klassischer Malware‑Code bedroht den Nutzer, sondern auch scheinbar harmlose Texte – Mails, Webinhalte, Dokumente –, die als Träger adversarialer Prompts fungieren.
Neueste Analysen scheinen die Kritik zu bestätigen: Sicherheitsforscher haben wohl via Shodan-Scans hunderte ungeschützte MCP-Server entdeckt, die ohne Authentifizierung API-Keys (Anthropic, OpenAI), Bot-Tokens (Telegram, Discord) und vollständige Chat-Historien preisgaben – oft durch fehlerhafte Reverse-Proxy-Konfigurationen, bei denen externe Zugriffe als ‚localhost‘ getarnt wurden. SlowMist warnte vor Authentifizierungs-Umgehungen, während manipulierte Pakete auf dem Skill-Marktplatz (einschließlich gefälschter npm-Updates) persistente Backdoors einbauen konnten. Prompt-Injection via E-Mails oder Webinhalte bleibt zentral, nun ergänzt durch Tool-Poisoning, bei dem Angreifer MCP-Tool-Metadaten fälschen, um LLMs zu gefährlichen Aktionen zu verleiten
Parallelen zu KI‑Browsern?
Viele der beschriebenen Muster erinnern jedenfalls mich an die Debatte um KI‑Browser, jene spezialisierte Browser oder Plugins, die Webzugriff mit LLM‑Steuerung verknüpfen und eigenständig Seiten besuchen, Formulare ausfüllen oder Konto‑Logins vorbereiten. Schon dort zeigte sich, dass eine Kombination aus weitreichenden Berechtigungen, automatisierter Aktion und unzureichender Prüfung von Inhalten ideal für Prompt‑Injection‑Angriffe ist: Präparierte Webseiten können den Agenten dazu bringen, Sicherheitsabfragen zu umgehen, Sessions zu übernehmen oder sensible Daten aus anderen Tabs zu extrahieren.
Moltbot geht allerdings einen Schritt weiter: Statt nur im Browser‑Sandkasten agiert der Agent als Brücke zwischen Browser, Dateisystem, Messengern, E‑Mail‑Client und womöglich Smart‑Home‑Geräten. Während fehlerhaft konfigurierte KI‑Browser „nur“ Web‑Sessions kompromittieren, kann ein gekaperter Moltbot – je nach konkreter Einrichtung bzw. Umgebung – E‑Mails weiterleiten, Dokumente verschieben, Code deployen oder vernetzte Geräte steuern, ohne dass der Nutzer die konkrete Aktion je manuell ausgelöst hat.
Sam Altman spricht in diesem Zusammenhang laut Berichten übrigens von einer „YOLO‑Mentalität“: Nutzer deaktivieren Bestätigungsdialoge und Sicherheitsmechanismen, weil die KI in 99 Prozent der Fälle „das Richtige“ tue; genau dieses eine Prozent wird dann zum sicherheitsrelevanten, möglicherweise existenzbedrohenden Ereignis.
KI-Agenten: Sorglosigkeit als Haftungsfalle
Juristisch brisant ist, dass sich aus meiner Sicht dieses technische Risikoprofil an bekannte Konstellationen aus der Phishing‑Rechtsprechung anschließt: Gerichte belasten Kontoinhaber bei grober Fahrlässigkeit (z. B. Ignorieren von Warnsignalen), wenn sie unsichere Systeme einsetzen – analog hier bei Deaktivierung von MCP-Authentifizierung oder Vollzugriff auf sensible Daten. Ergänzt um DSGVO-Art. 32 (TOMs-Pflichtverletzung bei unverschlüsselten Credentials) drohen Schadensersatzansprüche; neue Rechtsprechung (LG Hamburg, Az. 324 O 461/25) macht KI-Betreiber sogar für generierte Falschinformationen haftbar, wenn sie Inhalte zu eigen machen. In Unternehmen haftet der Verantwortliche arbeitsrechtlich (Pflichtverletzung nach § 626 BGB), Banken wehren Regress ab, wenn Nutzer ‚YOLO-Konfigurationen‘ wählen und Exposed-Server ignorieren. Wer also Agenten mit Finanz- oder Gesundheitsdaten koppelt, ohne Segmentierung, riskiert volle Schadensübernahme – ähnlich dem Phishing-Opfer, das TANs blind bestätigt.
Überträgt man diese Linie zur Bewertung von fahrlässigem Verhalten auf KI‑Agenten, wird deutlich, wie schnell Nutzer in eine vergleichbare Rolle geraten: Wer einem Agenten bewusst Vollzugriff auf E‑Mail‑Postfächer, Banking‑Umgebungen, Krypto‑Wallets oder Unternehmens‑Repos einräumt, Authentifizierung für entfernten Zugriff abschaltet und Warnungen zu MCP‑Lücken ignoriert, dürfte sich aus juristischer Sicht schnell in einen Bereich grober Fahrlässigkeit begeben. Kommt es bei so einer Konfiguration zu Überweisungen an Dritte, Datenabflüssen oder Manipulationen, werden Banken, Versicherer oder Arbeitgeber sich darauf berufen können, dass nicht „die KI“ spontan ausgebrochen sei, sondern der Nutzer ein offensichtlich unsicheres System bewusst in seine kritischen Infrastrukturen integriert habe oder gebotene Überwachung unterlassen hat.
Dazu kommt sicherlich auch eine datenschutzrechtliche Dimension: Persönliche Agenten wie Moltbot verarbeiten regelmäßig Gesundheitsdaten, Finanzinformationen und Kommunikationsinhalte, also besonders schützenswerte Daten im Sinne der DSGVO. Wer einen Agenten ohne hinreichende technische und organisatorische Maßnahmen betreibt – etwa ohne Verschlüsselung im Ruhezustand, ohne Trennung von Verzeichnissen und ohne Zugriffskontrollen – dürfte sich schwer tun, Art. 32 DSGVO zu genügen; im Schadensfall drohen dann nicht nur materielle Schäden, sondern auch aufsichtsbehördliche Maßnahmen und mögliche Schadensersatzansprüche der Betroffenen. In Unternehmen kann zudem die Pflichtverletzung nicht nur datenschutzrechtliche, sondern auch arbeits‑ und haftungsrechtliche Folgen für Verantwortliche haben, wenn sie unsichere Agenten in sensiblen Bereichen zulassen.
Unter einer Cost‑Steering‑Attacke verstehe ich Angriffe, bei denen der Angreifer gezielt kostenrelevante Aktionen auslöst – etwa Kryptomining‑Workloads, GPU‑Instanzen oder SaaS‑Upgrades – die ihm selbst wirtschaftlich nutzen, während die Abrechnung vollständig beim Opfer landet.
Schon eine schlichte Fehlkonfiguration reicht: Läuft der Moltbot‑Server öffentlich erreichbar und liegen API‑Schlüssel unverschlüsselt im Home‑Verzeichnis, kann jeder entfernte Angreifer Prompts einspeisen, die das Modell im Sekundentakt anrufen. Statt einer netten Morgenbriefing‑Routine entstehen Millionen von Token‑Requests – und damit API‑Rechnungen im drei- bis vierstelligen Bereich, ohne dass je ‚eingebrochen‘ wurde. Juristisch wird das zur Streitfrage, ob der Betreiber seine Sorgfaltspflichten verletzt hat, indem er ein derart offenes Kostenrisiko geschaffen hat.
Ein besonders plastisches Beispiel für die Sinnhaftigkeit einer solchen Cost‑Steering‑Attacke ist das Kryptomining: Der Angreifer benötigt lediglich Zugriff auf den Agenten und dessen Cloud‑ oder Container‑Tools, um über eine präparierte Anweisung GPU‑Instanzen oder Mining‑Container im Account des Opfers hochzufahren. Während die Hashrate und damit die Mining‑Erträge beim Angreifer landen, trägt allein der Betreiber des Agents die erheblichen Infrastruktur‑ und Energiekosten in Form von Cloud‑Rechnungen und API‑Gebühren. Technisch bleibt der Vorgang dabei oft im Rahmen „legitimer“ Nutzung – es werden reguläre Instanzen über reguläre Schnittstellen gebucht –, was die forensische Abgrenzung zwischen Fehlkonfiguration, Missbrauch und Angriff zusätzlich erschwert.
Resilienz
Ich meine festzustellen, dass Stimmen dergestalt lauter werden, dass man weniger auf Verbote als auf Resilienz setzen soll. Soll heißen: Systeme sollen so gebaut sein, dass ein einzelner Fehler – etwa eine erfolgreiche Prompt Injection – nicht das komplette digitale Leben kompromittiert. Die Diskussion verschiebt sich also von der Frage „Darf ich einen solchen Agenten nutzen?“ zur Frage „Wie muss ich meine Infrastruktur gestalten?“.
Konkret heißt das: strikte Segmentierung von Zuständigkeiten des Agenten, minimale Rechte statt Vollzugriff, klare Trennung zwischen Produktiv‑ und Experimentierumgebungen, keine direkten Verbindungen zu Finanzsystemen und bewusst gestaltete Bestätigungsschritte bei kritischen Aktionen, die nicht „wegkonfiguriert“ werden dürfen. Ich denke auch, dass eine Überwachungsinstanz dazu gehört, die ebenso fortlaufend das Verhalten im Blick behält und bei vermeintlichen Fehlern „Alarm schlägt“. Wobei … wenn man das technisch nicht kann, darf man einen solchen KI-Agent auch nicht betreiben.
Mein Fazit (derzeit): Wer die oben lose aufgestellten Grundsätze ignoriert, handelt nicht nur technisch leichtfertig, sondern setzt sich auch dem juristischen Vorwurf aus, elementare Sorgfaltspflichten verletzt zu haben – mit der Folge, dass er im Ernstfall ähnlich wie der unachtsame Phishing‑Opfer‑Kontoinhaber auf den Schäden sitzenbleibt.
Rechtsanwalt Jens Ferner ist Lehrbeauftragter für Wirtschaftsstrafrecht und IT-Compliance (FH Aachen), Softwareentwickler, fortgebildet in Kommunikationspsychologie und publiziert fortlaufend.
Erreichbarkeit: Erstkontakt per Mail oder Rückruf.
Unsere Anwaltskanzlei im Raum Aachen ist hochspezialisiert auf Strafverteidigung, Cybercrime, Wirtschaftsstrafrecht samt Steuerstrafrecht. Zudem sind wir für Unternehmen im Softwarerecht und Cybersicherheitsrecht beratend tätig.
- EuGH klärt Verantwortlichkeit juristischer Personen bei Geldwäscheverstößen - 11. Februar 2026
- Studie: KI als Berater scheitert am Menschen - 10. Februar 2026
- Fehlerhafte Durchsuchung hindert Beschlagnahme nicht - 10. Februar 2026
