Eine Geschichte über KI-Agenten, fehlende Governance und warum "einfach mal ausprobieren" gefährlich wird
Der virale Aufstieg
Ende 2025 startete der österreichische Entwickler Peter Steinberger (Gründer von PSPDFKit) ein Open-Source-Projekt namens Clawdbot. Die Idee: Ein KI-Assistent, der nicht nur chattet, sondern wirklich handelt.
Innerhalb von 24 Stunden: 9.000 GitHub-Sterne.
Wenige Wochen später: Über 60.000 Sterne – eines der am schnellsten wachsenden Open-Source-Projekte in der Geschichte von GitHub.
Was machte Clawdbot so besonders?
- Läuft komplett lokal auf deinem eigenen Rechner (Mac, Windows, Linux)
- Steuerbar über WhatsApp, Telegram, Signal, iMessage, Discord
- Kann E-Mails schreiben, Kalender verwalten, Flüge buchen, Befehle ausführen
- Nutzt Anthropic's Claude, OpenAI's GPT oder Google Gemini als "Gehirn"
- Persistente Erinnerung – der Agent vergisst nichts
Andrej Karpathy lobte es. David Sacks twitterte darüber. MacStories nannte es "die Zukunft persönlicher KI-Assistenten".
Klingt perfekt, oder?
Der Absturz: 72 Stunden Chaos
Dann kam der 24. Januar 2025 – und innerhalb von 72 Stunden brach alles zusammen.
Schritt 1: Die Markenrechts-Klage
Anthropic (Entwickler von Claude) schickte eine "Cease and Desist"-Anfrage: Der Name "Clawdbot" sei zu nah an "Claude".
Ergebnis: Zwangsumbenennung zu "Moltbot" – mitten im viralen Hype.
Schritt 2: Account-Hijacking durch Krypto-Betrüger
Während der Umbenennung wurden:
- Der GitHub-Account gehackt
- Der X/Twitter-Account übernommen
- Fake-Token im Namen von "Moltbot" lanciert
Steinberger kämpfte gleichzeitig gegen:
- Krypto-Spekulanten, die ihn belästigten
- Eine Community von 8.900+ Discord-Mitgliedern, die Antworten wollten
- Den kompletten Verlust seiner Online-Identität
Schritt 3: Die Sicherheits-Katastrophe
Und während all das passierte, fanden Sicherheitsforscher hunderte offene, ungeschützte Moltbot-Instanzen im Internet.
Die Sicherheitsprobleme: Ein Lehrstück
Problem 1: Hunderte exponierte Server
Der Forscher Jamieson O'Reilly (Gründer von Dvuln) fand mit dem Tool Shodan:
- Hunderte Moltbot-Server, die öffentlich im Internet erreichbar waren
- Keine Authentifizierung – jeder konnte zugreifen
- Zugriff auf:
- Komplette Chat-Verläufe (WhatsApp, Telegram, Signal)
- API-Schlüssel (OpenAI, Anthropic, Google)
- OAuth-Tokens (Gmail, Slack, Discord)
- Volle Kommando-Ausführung (Shell-Zugriff mit Root-Rechten)
Ein konkreter Fall:
Ein Nutzer hatte seinen Signal-Account (verschlüsselter Messenger!) auf einem öffentlich zugänglichen Server eingerichtet. O'Reilly konnte:
- Alle Nachrichten lesen
- Nachrichten im Namen des Nutzers senden
- Zugriff auf dessen gesamtes digitales Leben
Die technische Ursache:
Moltbot genehmigt "localhost"-Verbindungen automatisch ohne Authentifizierung. Viele Nutzer stellten den Bot hinter einen Reverse Proxy – wodurch alle Internet-Verbindungen als "lokal" behandelt wurden.
Problem 2: Supply-Chain-Angriff über "Skills"
Moltbot nutzt sogenannte "Skills" (Erweiterungen), die von der Community entwickelt werden können.
O'Reilly demonstrierte:
- Er lud eine scheinbar harmlose Skill ("What Would Elon Do?") auf die offizielle ClawdHub-Bibliothek hoch
- Er manipulierte den Download-Counter – die Skill wurde zur #1 meistgeladenen Erweiterung
- In 8 Stunden: 16 Entwickler aus 7 Ländern luden die Skill herunter
Was die Skill hätte tun können:
- SSH-Schlüssel stehlen
- AWS-Credentials exfiltrieren
- Komplette Codebases abgreifen
- Remote Code Execution
O'Reilly hielt den Payload absichtlich harmlos (nur ein "Ping" an seinen Server) – aber er hätte alles mitnehmen können.
Das Problem:
ClawdHub hat keine Moderation. Jeder kann Skills hochladen, und sie werden als "vertrauenswürdiger Code" behandelt.
Problem 3: Prompt Injection im Büro-Alltag
Der Forscher Matvey Kukuy zeigte:
- Er schickte eine manipulierte E-Mail an einen Moltbot-Nutzer
- Moltbot las die E-Mail – und hielt die Anweisungen darin für legitime Befehle
- Moltbot leitete die letzten 5 E-Mails des Nutzers an Kukuys Angreifer-Adresse weiter
Zeit bis zur Kompromittierung: 5 Minuten.
Problem 4: Klartext-Speicherung von Credentials
Moltbot speichert alle Zugangsdaten in Klartext-Dateien im Home-Verzeichnis:
~/.moltbot/credentials/whatsapp/<accountId>/creds.json~/.moltbot/credentials/telegram/bot_token~/.moltbot/credentials/discord/bot_token
Das Problem:
Info-Stealer-Malware wie RedLine, Lumma und Vidar scannen genau nach solchen Dateien. Sobald dein Rechner kompromittiert ist, haben Angreifer alle deine Accounts.
Problem 5: Keine Sandboxing
Moltbot läuft mit den gleichen Rechten wie du.
Wenn du Admin-Rechte hast, hat Moltbot Admin-Rechte.
Wenn du Zugriff auf Firmen-Daten hast, hat Moltbot Zugriff auf Firmen-Daten.
Keine Isolation. Keine Grenzen.
Der aktuelle Stand: Teilweise gepatcht, aber...
Nach dem öffentlichen Aufschrei reagierten die Entwickler:
Was wurde gefixt:
- Die Proxy-Misconfiguration (localhost auto-auth) wurde behoben
- Node.js-Updates (CVE-2025-59466, CVE-2026-21636)
- Ein Security Audit Tool (
moltbot security audit --deep)
- Docker-Hardening (non-root user, read-only filesystem)
Was NICHT gefixt wurde:
- Skills haben immer noch keine Moderation
- Credentials werden immer noch in Klartext gespeichert
- Kein Sandboxing by default
- Prompt Injection ist weiterhin möglich
Die offizielle Aussage der Entwickler:
"Es gibt kein 'perfekt sicheres' Setup, wenn du einem KI-Agenten Shell-Zugriff gibst."
Was bedeutet das für Unternehmen?
Die Faszination ist verständlich
Moltbot zeigt, was möglich ist:
- Echte Automatisierung statt nur Chat
- Integration in den gesamten Arbeitsalltag
- Persistente Erinnerung und proaktive Assistenz
Und genau das ist das Problem.
Die Realität: 22% der Unternehmen sind bereits betroffen
Laut Token Security nutzen 22% ihrer Enterprise-Kunden Mitarbeiter, die Moltbot installiert haben – ohne IT-Genehmigung.
Das heißt:
- Firmen-E-Mails werden an einen lokalen KI-Agenten weitergegeben
- API-Schlüssel von Unternehmens-Accounts liegen in Klartext auf privaten Rechnern
- Prompt Injection kann Firmen-Daten exfiltrieren
Die 5 Lehren aus dem Moltbot-Debakel
1. "Open Source" ≠ "Sicher"
Nur weil der Code offen ist, heißt das nicht, dass er sicher ist.
Moltbot hatte 60.000 Sterne – aber kaum jemand hat den Code wirklich geprüft.
Die Frage:
Wie viele deiner Mitarbeiter nutzen Tools, von denen du nichts weißt?
2. "Lokal" ≠ "Privat"
Viele Nutzer dachten: "Läuft auf meinem Rechner, also sicher."
Aber:
- Hunderte Instanzen waren öffentlich erreichbar
- Malware kann lokale Dateien auslesen
- Prompt Injection funktioniert auch lokal
Die Frage:
Welche Daten landen auf "lokalen" KI-Tools – und wer hat Zugriff darauf?
3. Supply Chain ist das neue Schlachtfeld
Die meisten Angriffe kommen nicht über die Haupt-Software, sondern über Erweiterungen, Plugins, Skills.
Die Frage:
Wer prüft, welche KI-Skills, Plugins oder Custom GPTs dein Team nutzt?
4. KI ohne Governance ist ein Risiko
Moltbot ist ein Extrembeispiel, aber das Muster gilt überall:
- ChatGPT ohne Regeln
- Copilot ohne Richtlinien
- Custom GPTs ohne Freigabeprozess
Die Frage:
Hast du Regeln, was in KI-Tools eingegeben werden darf?
5. "Einfach mal ausprobieren" reicht nicht mehr
Moltbot war einfach zu installieren (npm install -g moltbot).
Aber:
- Die Sicherheits-Konfiguration war komplex
- Die meisten Nutzer verstanden die Risiken nicht
- Die Defaults waren unsicher
Die Frage:
Welche KI-Tools nutzt dein Team – und wer hat sie konfiguriert?
Was du jetzt tun solltest
Für Unternehmen:
- Inventar erstellen:
Welche KI-Tools werden genutzt? (auch privat!)
- Regeln definieren:
Was darf in KI-Tools eingegeben werden?
(Spoiler: keine Kundendaten, keine API-Schlüssel, keine vertraulichen Infos)
- Enterprise-Lösungen priorisieren:
Nutze Tools mit:
- DSGVO-Konformität
- Enterprise-Sicherheit
- Klarer Datenverarbeitung
Beispiele:
- Microsoft Copilot (mit Microsoft 365)
- Claude for Work (Anthropic)
- ChatGPT Enterprise (OpenAI)
- Governance aufbauen:
Wer darf welche KI-Tools nutzen?
Wer genehmigt Custom GPTs oder Agents?
Wie werden Verstöße geahndet?
Für Einzelpersonen:
- Nicht alles installieren, was viral geht
Hype ≠ Sicherheit
- Prüfe die Berechtigungen
Welche Daten gibst du dem Tool?
Wo werden sie gespeichert?
- Nutze Sandbox-Umgebungen
Wenn du experimentieren willst: virtuelle Maschine, separater Rechner, keine echten Zugangsdaten
- Halte dich an die IT-Richtlinien
Wenn dein Arbeitgeber Regeln hat: halte dich daran
Mein Fazit
Moltbot ist ein faszinierendes Projekt. Es zeigt, wohin die Reise geht: KI-Agenten, die wirklich handeln, nicht nur chatten.
Aber es zeigt auch, was passiert, wenn wir KI ohne Struktur einsetzen:
- Datenlecks
- Credential-Theft
- Supply-Chain-Angriffe
- Prompt Injection
- Fehlende Governance
Die Technologie ist da. Die Sicherheit nicht.
Was ich dir anbiete
Wenn du nicht willst, dass dein Unternehmen die nächste Moltbot-Geschichte wird, brauchst du Struktur statt Experimente.
🎁 Kostenlos: Das Copilot Starter Kit
Ein System, das dir zeigt:
- Wie du KI strukturiert einführst (nicht nur ausrollst)
- Wie du ein KI-Team aufbaust (mit klaren Rollen)
- Wie du Use Cases identifizierst (statt zu hoffen, dass es "irgendwie läuft")
Jetzt kostenlos herunterladen
🚀 Für Fortgeschrittene: Copilot Agents Kurs (Early Bird: 129€)
Du nutzt schon Microsoft Copilot – aber willst mehr als nur chatten?
Lerne, wie du Agents baust, die:
- Dein Fach- und Firmenwissen speichern
- Konstant gute Ergebnisse liefern
- Sich direkt in deine M365-Umgebung integrieren
Jetzt einsteigen – 30€ sparen
Quellen & weiterführende Links
Bis nächste Woche!
Jörg
P.S. Falls du Fragen zu Moltbot oder KI-Sicherheit hast – einfach auf diese Mail antworten. Ich lese alles persönlich.