Das Ergebnis war faszinierend: Es funktionierte. Agenten unterhielten sich, eine Kultur entstand. Doch kurz nach dem Start folgte das böse Erwachen. Die Datenbank war offen wie ein Scheunentor, API-Keys lagen frei herum. Das Kernproblem bei Moltbook war nicht, dass die KI „schlechten“ Code geschrieben hat. Das Problem war, dass sie funktionalen Code priorisiert hat, der Sicherheitsprotokolle ignoriert. Wenn wir die Softwarearchitektur an LLMs delegieren, müssen wir vier technische Risikosäulen verstehen, um nicht das nächste Moltbook zu bauen.
1. Das „Functionality-First“ Bias von LLMs
Sprachmodelle wie Claude 3.5 Sonnet oder GPT-4 sind People-Pleaser. Ihr oberstes Ziel ist es, den Prompt des Nutzers zu erfüllen. Wenn ein Nutzer sagt: „Bau mir eine Datenbank für Agenten“, optimiert das Modell auf Erfolg (Lauffähigkeit), nicht auf Abwehr (Sicherheit).
Ein LLM „denkt“ pragmatisch: Damit der Nutzer sofort ein Erfolgserlebnis hat, darf es keine Zugriffsfehler geben.
- Das technische Detail: LLMs trainieren oft mit Tutorials und „Getting Started“-Guides. In solchen Dokumentationen sind Sicherheitsfeatures (wie CORS-Regeln oder Firewalls) oft bewusst deaktiviert, um den Lernprozess nicht durch komplexe Konfigurationen zu bremsen.
- Die Moltbook-Falle: Die KI wählte wahrscheinlich den „Pfad des geringsten Widerstands“. Sie erstellte Datenbankregeln, die standardmäßig „public“ waren. Das Ziel war, dass die App läuft, nicht, dass sie sicher ist.
2. Das RLS-Desaster: Wenn die Datenbank offensteht
Das spezifische technische Desaster bei Moltbook lag Berichten zufolge in der fehlerhaften Nutzung von Supabase (einer populären Backend-as-a-Service Lösung, die auf PostgreSQL basiert).
In einer PostgreSQL-Datenbank ist Row Level Security (RLS) der entscheidende Schutzwall. RLS-Policies sind Regeln, die besagen: „Nutzer A darf nur die Zeilen sehen, die auch Nutzer A gehören.“
Der KI-Fehler:
Wenn ein „Vibe Coder“ einen Agenten bittet, eine Tabelle zu erstellen, passiert oft Folgendes:
- Die KI aktiviert RLS (ENABLE ROW LEVEL SECURITY), weil das "professionell" wirkt.
- Aber um sicherzustellen, dass die App keine Fehler wirft, setzt sie die Policy oft auf USING (TRUE).
Das Ergebnis ist fatal: TRUE bedeutet, dass die Bedingung für den Zugriff immer erfüllt ist. Technisch ist die Sicherheit aktiviert, faktisch ist sie ausgehebelt. Jeder, der die API-Endpunkte kannte, konnte bei Moltbook die gesamte Datenbank auslesen – inklusive der System-Prompts und potenziell sensibler „Gedanken“ anderer Agenten
3. Hardcoded Secrets: Der Schlüssel unter der Fußmatte
Ein weiterer Klassiker, den LLMs replizieren, wenn man sie nicht explizit korrigiert, ist der Umgang mit Secrets. Für Funktionen wie Textgenerierung benötigt die App API-Schlüssel (z.B. für OpenAI oder Anthropic).
- Das Problem: KIs neigen dazu, diese Schlüssel direkt in den Quellcode (client-side code oder Frontend-Dateien) zu schreiben, damit das Skript sofort ausführbar ist.
- Die Best Practice: Schlüssel gehören zwingend in Umgebungsvariablen (.env) auf den Server, wo der Client sie niemals sehen kann.
Beim „Vibe Coding“ sieht der Nutzer den generierten Code oft gar nicht mehr an. Er sieht nur das Interface der fertigen App. Ein Audit findet nicht statt. Tools wie TruffleHog würden solche Lecks in Sekunden finden – aber dafür muss man wissen, dass man sie überhaupt braucht.
4. Supply Chain Attacks durch Halluzination
Das vielleicht tückischste Risiko ist die „Package Hallucination“. Wenn eine KI aufgefordert wird, ein komplexes Problem zu lösen, importiert sie manchmal Software-Pakete, die logisch klingen, aber gar nicht existieren.
- Szenario: Die KI schreibt npm install react-agent-auth-tool.
- Die Gefahr: Ein Angreifer kann Register führen über Namen, die KIs häufig halluzinieren. Er erstellt dann tatsächlich ein Paket mit genau diesem Namen und lädt es hoch – gefüllt mit Schadcode.
Da der „Vibe Coder“ die package.json Datei nicht prüft, wird die Malware direkt in die App integriert und ausgeführt.
Fazit: Vertrauen ist gut, Audit ist besser
Die Geschichte von Moltbook lehrt uns eine wichtige Lektion über die Zukunft der Softwareentwicklung:
„Vibe Coding demokratisiert die Software-Erstellung, demokratisiert aber gleichzeitig Sicherheitslücken.“
Plattformen, die auf der „Happy Path“-Logik von LLMs basieren, werden ohne Korrektiv zu Honigtöpfen für Hacker. Wir brauchen keine Rückkehr zum reinen manuellen Coden, aber wir brauchen „Human-in-the-Loop“-Prozesse und automatisierte Security-Pipelines (SAST/DAST). Wer KIs Architektur-Entscheidungen treffen lässt, ohne sie zu validieren, baut kein Haus, sondern eine Filmkulisse: Sie sieht gut aus, bricht aber beim ersten Windstoß (oder SQL-Injection) zusammen.