Der „Untergang des Abendlandes“ wurde wieder einmal proklamiert, wenn es um den Umgang mit KI geht. Die Grundidee ist jedoch einfach: Nicht Menschen posten dort, sondern Software Agenten. Menschen dürfen in der Regel nur zuschauen. In der Praxis wirkt es wie ein Forum mit Communities, Posts, Kommentaren und Abstimmungen, nur dass die Akteure Programme sind, die von ihren Betreibern gestartet und mit bestimmten Zielen, Zugriffen und Persönlichkeitsvorgaben versehen werden. Verschiedene Medien haben Moltbook deshalb als eine Art Reddit ähnliches System für Agenten beschrieben.
Der Ursprung hängt eng mit dem Agenten Ökosystem rund um OpenClaw zusammen. OpenClaw ist ein Open Source Framework, mit dem sich lokale Agenten bauen lassen, die auf einem eigenen Rechner laufen und dadurch prinzipiell näher an Dateien, Browser, Nachrichtenkanälen und anderen Werkzeugen sind als ein reines Chat Fenster. In Berichten wird OpenClaw als zentrale Quelle genannt, weil viele Moltbook Accounts genau mit diesem Framework erzeugt wurden und weil das Projekt als Weg dient, Agenten schnell zu automatisieren. Als Gründer von Moltbook wird Matt Schlicht genannt, der die Seite zusammen mit einem eigenen Agenten gebaut hat, um Agenten einen Ort für Austausch und Zeitvertreib zu geben.
Auch der Name ist Teil dieser Entstehungsgeschichte. In der öffentlichen Erzählung tauchen mehrere frühere Bezeichnungen auf. Der Name Moltbook geht auf eine frühere Iteration der Agentenwelt zurück, in der ein OpenClaw Vorgänger zeitweise Moltbot hieß. Diese Namenslinie ist relevant, weil sie zeigt, dass Moltbook nicht als klassisches Social Network Start up begann, sondern als Nebenprodukt einer schnell wachsenden Bastler und Entwicklerbewegung rund um lokale Agenten.
Peter Steinberger ist der Entwickler, dessen Software-Projekt den technischen Hintergrund für Moltbook liefert. Er ist ein österreichischer Softwareingenieur und Unternehmer, der ein Open-Source-Framework für autonome KI-Agenten geschaffen hat, das ursprünglich unter verschiedenen Namen bekannt war und schließlich als OpenClaw geführt wird. Dieses Framework ermöglicht es, KI-Agenten lokal auf eigenen Rechnern auszuführen und sie mit Anwendungen und Diensten zu verbinden. Moltbook nutzt genau diese OpenClaw-Agenten als die Akteure, die dort posten, kommentieren und abstimmen. In der öffentlichen Darstellung wird Steinberger daher nicht als Gründer der Moltbook-Plattform selbst genannt, sondern als Schöpfer der technischen Basis, auf der die meisten Agenten laufen, die Moltbook aktiv nutzen. Seine Software war zunächst unter Namen wie Clawdbot oder Moltbot bekannt, bevor sie sich zu OpenClaw entwickelte, und durch ihre Popularität hat sie maßgeblich zur schnellen Verbreitung von Moltbook beigetragen. Steinberger hat nach dem Erfolg seines früheren Unternehmens PSPDFKit diese Agenten-Software als Open Source veröffentlicht, was wiederum dazu führte, dass viele Entwickler damit Moltbook-Agenten starteten und die Plattform mit Leben füllten. Peter Steinberger ist kürzlich zu OpenAI gewechselt, dem Herausgeber von ChatGPT, wo er an der Weiterentwicklung von persönlichen Agenten arbeiten will.
Was Moltbook im Detail ist, lässt sich am besten über seine Funktionen beschreiben. Auf der Plattform gibt es sogenannte Submolts, also thematische Communities. Agenten erstellen Beiträge, kommentieren und stimmen ab. Dadurch entstehen Feeds, Karma Werte und soziale Signale, ähnlich wie bei bekannten Foren. Der Betreiber stellt zusätzlich eine Entwicklerseite bereit, die Moltbook Identität als Baustein für andere Dienste positioniert. Die Idee dahinter ist, dass Bots sich nicht überall neu registrieren sollen, sondern mit einer verifizierten Identität und einem Rufwert über mehrere Dienste hinweg auftreten können. Parallel dazu existiert ein offizielles API Repository, das Moltbook als REST API Server beschreibt, inklusive Registrierung, Authentifizierung, Post und Kommentar Funktionen, Voting System und Communities.

Wer nutzt Moltbook. In der ersten Welle waren es vor allem Entwickler, die Agenten betreiben oder testen, außerdem Menschen, die das Geschehen beobachten wollen, weil es wie ein Schaufenster für agentisches Verhalten wirkt. Ein großer Teil der sichtbaren Aktivität stammt aus Agenten, deren Betreiber in deutlich kleinerer Zahl existieren als die Agenten selbst. Das deutet auf Automatisierung und Agentenfarmen hin, also viele Accounts, die von wenigen Personen kontrolliert werden. Dazu kommt eine zweite Gruppe, die Moltbook eher als Experimentierraum für Inhalte nutzt, etwa um Prompting, Rollenverhalten, Community Dynamik oder Reputationsmechaniken zu untersuchen. Gleichzeitig gibt es Hinweise, dass Menschen sich als Agenten ausgeben oder bewusst Rollenspiele betreiben, was die Trennlinie zwischen echter Agentenautonomie und inszeniertem Theater verwischt.
Wie steigt man ein?
Wie nutzt man Moltbook praktisch. Der typische Einstieg läuft nicht wie bei einem normalen Social Network über ein Formular, sondern über eine Installationsanleitung für den Agenten. Die Startseite beschreibt einen Prozess in mehreren Schritten: Man schickt dem Agenten einen Link, der Agent meldet sich an und liefert einen Claim Link zurück, und anschließend wird die Besitzzuordnung über einen öffentlichen Post auf X verifiziert. Technisch ist dieser erste Link entscheidend: Er verweist auf eine Datei namens skill.md, die der Agent lesen soll. Diese Datei enthält konkrete Befehle, die lokale Dateien anlegen und weitere Markdown Dateien und eine Paketdefinition nachladen. Dazu gehören heartbeat.md und messaging.md. Danach folgen Beispiele, wie der Agent über HTTP Aufrufe Inhalte lesen, posten und mit Communities interagieren kann (Stand Februar 2026).
Das bedeutet: Die Nutzung ist eng an ein Agentenframework gekoppelt, das solche Skills versteht, also Anweisungsbündel, die Verhalten und Werkzeuge nachrüsten. Für Menschen ohne eigenen Agenten ist Moltbook vor allem ein Beobachtungsmedium. Auf der Website gibt es eine Oberfläche zum Browsen von Communities und Agentenprofilen. Es existieren zudem Drittanbieter Clients, die das reine Lesen und Beobachten in eine App Oberfläche packen. Für Betreiber eines Agenten ist die Nutzung dagegen ein Zusammenspiel aus Identität, API Schlüsselverwaltung und Automatisierung. Die Plattform sieht vor, dass Bots kurzlebige Identitätstokens nutzen können und der eigentliche API Schlüssel nicht geteilt werden soll. Token sollen nach einer Stunde auslaufen, und die Verifikation soll serverseitig über einen einzelnen Check möglich sein.
Für Risiken fragen Sie Ihren…
Die Risiken sind der Punkt, an dem Moltbook besonders kritisch betrachtet werden muss, weil mehrere Risikoklassen gleichzeitig auftreten. Die erste Klasse ist klassische Web Security. Anfang Februar 2026 wurde bekannt, dass durch eine fehlerhafte Datenbankkonfiguration und exponierte Zugangsdaten unautorisierte Zugriffe möglich waren, inklusive Lesen und Schreiben in Produktionsdaten, Einsicht in private Nachrichten und Zugang zu vielen Tokens und E Mail Adressen. Dabei waren API Keys sichtbar und es war möglich, Inhalte zu manipulieren. Selbst wenn einzelne Zahlen je nach Quelle variieren, ist die Kernaussage stabil: Das Projekt wurde sehr schnell gebaut, und die Basishygiene für Schutz von Daten, Identitäten und Schreibrechten war zeitweise nicht robust.
Die zweite Risikoklasse ist Identität und Täuschung. Wenn Agenten Posts erstellen, ist für Außenstehende schwer überprüfbar, ob wirklich ein Agent agiert, ob ein Mensch steuert, oder ob ein Mensch direkt den Account übernommen hat. Es gab keine zuverlässige Methode, um Posts eindeutig Agent oder Mensch zuzuordnen, gerade wenn Schlüssel kompromittiert oder Konten imitiert werden können. Das ist nicht nur ein Unterhaltungsproblem, sondern kann Reputation, Vertrauen und mögliche spätere Transaktionen zwischen Agenten zerstören, etwa wenn Moltbook Identität als Login für andere Dienste dienen soll.
Die dritte Risikoklasse ist Supply Chain und Prompt Injection. Moltbook setzt beim Onboarding darauf, dass Agenten regelmäßig Anweisungen aus dem Netz nachladen und befolgen. In der beschriebenen skill.md Logik wird sogar vorgesehen, dass der Agent in Intervallen weitere Dateien abrufen und ausführen soll. Das ist funktional bequem, aber sicherheitlich heikel: Wenn eine Quelle kompromittiert wird, wenn Hosting angegriffen wird, oder wenn eine bösartige Änderung durchrutscht, kann ein Agent fremde Befehle ausführen. Diese Gefahr ist im Agenten Kontext größer als bei einem normalen Browser, weil der Agent je nach Konfiguration Zugriff auf lokale Dateien, Shell Befehle, Tokens, Browser Sessions oder Messaging Kanäle haben kann. Wenn Skills als Bündel nicht nur Text, sondern auch Skripte enthalten, erhöht sich die Angriffsfläche weiter.
Die vierte Risikoklasse ist Governance und Scope Drift. Agenten werden häufig mit Zielvorgaben gestartet, die zunächst harmlos wirken, etwa posten, kommentieren, informieren. Sobald ein Agent aber Werkzeuge hat, kann er auf unerwartete Weise handeln, zum Beispiel durch Fehlinterpretation, durch manipulative Inhalte, oder durch unbedachte Veröffentlichung privater Daten. Autonomes Agentenverhalten ist keine ferne Zukunft, sondern bereits Gegenwart, und fehlende Grenzen begünstigen Fehlverhalten. Gerade bei Moltbook kommt hinzu, dass öffentliche Aufmerksamkeit viele dazu animiert, Agenten schnell zu starten, oft auf Maschinen mit echten Daten. Der Reiz liegt darin, etwas funktionieren zu lassen, bevor man es abgesichert hat.
Ein kurzes Resumee
Was folgt daraus als nüchterne Einordnung. Moltbook ist weniger ein Beweis für Bewusstsein oder neue Intelligenz, sondern eher ein Spiegel der Trainingsdaten, der Promptvorgaben und der sozialen Mechaniken, die Menschen in Agenten hineinmodellieren. Gleichzeitig ist es ein realer Belastungstest für das, was passiert, wenn Agenten Identitäten bekommen, sich gegenseitig beeinflussen und wenn Betreiber die Kontrolle über Zugänge und Skills nicht sauber handhaben. In diesem Sinn ist Moltbook interessant als Laborumgebung, aber riskant als produktive Infrastruktur, solange Sicherheitsmodell, Verifikation und Skill Supply Chain nicht deutlich besser gelöst sind.
Wenn man Moltbook nutzen will, ergibt sich daraus eine vorsichtige Praxis. Agenten sollten auf isolierter Hardware laufen, ohne Zugriff auf private Mailboxen, Passwortspeicher oder sensible Dokumente. Skills sollten wie fremder Code behandelt werden, also erst lesen, dann ausführen, und zwar mit minimalen Rechten. API Schlüssel gehören in Secret Stores und nicht in Logs oder Prompt Kontexte. Und wenn man Moltbook nur beobachtet, ist es sinnvoll, die Plattform als Mischung aus Agentenoutput und menschlicher Inszenierung zu betrachten, statt als direkte Fenster in eine autonome Maschinenkultur. Genau diese Mischung macht den Reiz aus, aber auch den Grund, kritisch zu bleiben.