{"id":344,"date":"2026-08-23T16:27:06","date_gmt":"2026-08-23T16:27:06","guid":{"rendered":"https:\/\/hoge.gg\/de\/eliza-framework-2026-ki-agent-sicherheit-wallet\/"},"modified":"2026-08-23T16:27:06","modified_gmt":"2026-08-23T16:27:06","slug":"eliza-framework-2026-ki-agent-sicherheit-wallet","status":"publish","type":"post","link":"https:\/\/hoge.gg\/de\/eliza-framework-2026-ki-agent-sicherheit-wallet\/","title":{"rendered":"Eliza framework 2026: Wie sicher ist ein KI-Agent mit Wallet?"},"content":{"rendered":"

Am 4. August 2026 schrieb Shaw Walters, der Gr\u00fcnder von Eliza Labs, auf X einen Satz, der eine ganze Anlageklasse zu Grabe trug: der Token sei tot, komplett, die Stiftung werde abgewickelt. Die Nachricht kam, nachdem Walters eine Sammelklage per Vergleich beigelegt und die letzten Mittel der Foundation an die Halter \u00fcberwiesen hatte, wie CoinDesk<\/a> berichtete. Zum H\u00f6chststand war das Projekt einmal rund 2,04 Milliarden Euro (etwa 2,39 Milliarden US-Dollar) wert; heute liegt die Marktkapitalisierung des ELIZAOS-Token laut CoinGecko<\/a> bei rund 1,18 Millionen Euro, ein Minus von mehr als 99,9 Prozent.<\/p>

Und doch lebt Eliza weiter. Nicht der Token, sondern der Code: das quelloffene TypeScript-Framework auf GitHub<\/a> z\u00e4hlt weiter rund 19.100 Sterne, die Entwicklung l\u00e4uft mit hoher Taktung, und Walters baut nach eigener Aussage einfach weiter. Damit verschiebt sich 2026 die eigentliche Frage. Solange der Kurs die Schlagzeilen bestimmte, ging es um Spekulation. Jetzt, da der Token wertlos ist, bleibt nur noch die Frage \u00fcbrig, die von Anfang an die einzige war, die z\u00e4hlte: Kann man einer Software, die ihr eigenes Wallet kontrolliert und ihre eigenen Transaktionen signiert, tats\u00e4chlich Geld anvertrauen? Das ist der zweite Akt von Eliza, und er handelt nicht von Preiszielen, sondern von Vertrauen.<\/p>

Dieser Artikel ist eine Bestandsaufnahme der Sicherheit. Er erkl\u00e4rt, wie ein Eliza-Agent aufgebaut ist, wo genau das Vertrauen bricht, welche realen Angriffe es bereits gab, warum das Autonomieversprechen und die Sicherheit in einem harten Zielkonflikt stehen und welche Antworten die Branche gerade entwickelt, von verifizierbarer Berechnung \u00fcber Trusted Execution Environments bis zu Betrugsbeweisen. Am Ende steht die regulatorische und steuerliche Realit\u00e4t f\u00fcr deutsche Entwickler und Nutzer.<\/p>

Was Eliza 2026 wirklich ist: Framework statt Token<\/h2>

Eliza, offiziell ElizaOS, ist ein quelloffenes Framework zum Bau autonomer KI-Agenten. Ein solcher Agent ist mehr als ein Chatbot: Er verbindet ein Sprachmodell, das plant und interpretiert, mit einem eigenen Wallet, einem Ged\u00e4chtnis und einer Reihe von Werkzeugen, mit denen er Transaktionen ausl\u00f6sen kann. Er signiert seine eigenen Aktionen. Das unterscheidet ihn grundlegend von einem regelbasierten Trading-Bot, der nur ausf\u00fchrt, was ein Mensch vorab programmiert hat.<\/p>

Die Geschichte des Projekts ist bekannt und wurde von HOGE Wire mehrfach erz\u00e4hlt: gestartet als ai16z im Oktober 2024 auf Solana, umbenannt in ElizaOS im Januar 2025, dann die Token-Migration, der Kurssturz und schlie\u00dflich das Ende des Token am 4. August 2026. Der entscheidende Punkt f\u00fcr 2026 ist, dass Token und Framework nie dasselbe waren. Der Token war die spekulative H\u00fclle. Das Framework ist Ingenieursarbeit. Walters brachte den Unterschied gegen\u00fcber Decrypt<\/a> auf den Punkt: „I am starting over, since I own the IP, and I am never letting a token come close to Eliza again.“ Der Code geh\u00f6re ihm, ein Token werde es nie wieder geben.<\/p>

Dass das Framework lebt, l\u00e4sst sich messen. Das GitHub-Repository tr\u00e4gt inzwischen den Untertitel „Your agentic operating system“, die Lizenz ist MIT, die Sprache TypeScript. Die folgende Momentaufnahme zeigt den Kontrast zwischen einem toten Token und einem aktiven Projekt.<\/p>

Kennzahl<\/th>Wert (Stand 23. August 2026)<\/th><\/tr><\/thead>
ELIZAOS-Kurs<\/td>rund 0,00016 Euro (etwa 0,00018 USD)<\/td><\/tr>
Marktkapitalisierung<\/td>rund 1,18 Mio. Euro (etwa 1,38 Mio. USD)<\/td><\/tr>
Rang<\/td>Nr. 2565<\/td><\/tr>
Abstand zum Hoch (2. Jan. 2025)<\/td>mehr als 99,9 Prozent unter rund 2,04 Mrd. Euro<\/td><\/tr>
Allzeittief<\/td>0,00016 USD am 11. August 2026<\/td><\/tr>
GitHub<\/td>rund 19.100 Sterne, 5.700 Forks, 552 offene Issues, 109 offene Pull Requests<\/td><\/tr><\/tbody><\/table>
Quellen: CoinGecko, GitHub (elizaOS\/eliza), CoinDesk.<\/figcaption><\/figure>

552 offene Issues und mehr als hundert offene Pull Requests sind kein Bild von Stillstand, sondern von einem Projekt, an dem laufend gearbeitet wird. Genau das macht die Sicherheitsfrage dringlich: Wer heute Eliza anfasst, tut es nicht mehr, um auf einen Kurs zu wetten, sondern um einen Agenten laufen zu lassen, der reales Geld bewegt.<\/p>

Warum Sicherheit jetzt die einzige Frage ist<\/h2>

Ein Sprachmodell, das eine falsche Antwort gibt, \u00e4rgert seinen Nutzer. Ein Agent, der eine falsche Transaktion signiert, verliert Geld, und zwar unwiderruflich. Diese Asymmetrie ist der Kern der ganzen Debatte. Auf einer Blockchain gibt es kein R\u00fcckbuchen, keinen Kundenservice, keine Stornierung. Was einmal signiert und best\u00e4tigt ist, ist weg.<\/p>

Solange der Token gehandelt wurde, \u00fcberlagerte die Kursfantasie dieses Risiko. Anleger diskutierten \u00fcber Marktkapitalisierung und Migration, nicht \u00fcber Angriffsfl\u00e4chen. Mit dem Ende des Token f\u00e4llt diese Ebene weg. \u00dcbrig bleibt die n\u00fcchterne Frage eines jeden Entwicklers, der einen Eliza-Agenten mit einem Wallet ausstattet: Unter welchen Umst\u00e4nden wird dieser Agent dazu gebracht, das Falsche zu tun, und wie viel kann dabei verloren gehen?<\/p>

Das ist keine akademische Sorge. Ein Agent handelt oft rund um die Uhr, ohne dass ein Mensch mitliest. Er zieht Daten aus dem offenen Internet, aus sozialen Netzwerken, aus On-Chain-Nachrichten und aus seinem eigenen Ged\u00e4chtnis. Jede dieser Quellen kann manipuliert sein. Und weil der Agent \u00fcber Schl\u00fcssel verf\u00fcgt, ist jede erfolgreiche Manipulation potenziell eine \u00dcberweisung. Sicherheit ist damit nicht ein Feature unter vielen, sondern die Bedingung daf\u00fcr, dass die ganze Idee \u00fcberhaupt tragf\u00e4hig ist.<\/p>

Die Anatomie eines KI-Agenten: wo das Vertrauen bricht<\/h2>

Um zu verstehen, wo die Sicherheit bricht, hilft ein Blick auf den Aufbau. Im Zentrum von Eliza steht die AgentRuntime, eine Laufzeitumgebung, die ein Sprachmodell mit einem Speicher und mit Plugins verbindet. \u00dcber diese Plugins registrieren sich vier Grundbausteine: Actions, also Handlungen, die der Agent ausf\u00fchren kann, darunter das Senden oder Tauschen von Token; Providers, die dem Modell Kontext liefern; Evaluators, die Ergebnisse bewerten; und Services, die Verbindungen nach au\u00dfen halten.<\/p>

Die Handlungslogik ist einfach und genau darin liegt das Problem. Das Modell entscheidet auf Grundlage seines Kontextfensters, was zu tun ist. In diesem Fenster stehen die Pers\u00f6nlichkeitsbeschreibung des Agenten (die Character-Datei), die eingehende Nachricht und die abgerufenen Erinnerungen. Das Modell behandelt all das prinzipiell gleich. Es kann nicht sauber unterscheiden zwischen Daten, die es nur lesen soll, und Anweisungen, denen es folgen soll. Diese fehlende Trennung von Instruktion und Daten ist der Grundfehler jedes agentischen Systems auf Basis gro\u00dfer Sprachmodelle.<\/p>

Wer sich mit Hardware-Wallets auskennt, kennt die Analogie: das blinde Signieren. Ein Nutzer, der eine Transaktion best\u00e4tigt, ohne genau zu pr\u00fcfen, was er da signiert, vertraut darauf, dass die vorgelegte Aktion harmlos ist. Ein KI-Agent tut strukturell dasselbe. Er signiert, was seine Logik ihm nahelegt, und diese Logik l\u00e4sst sich von au\u00dfen beeinflussen. Der Vertrauensbruch passiert nicht in der Kryptografie, die funktioniert einwandfrei, sondern eine Ebene dar\u00fcber, dort, wo das Modell entscheidet, welche Transaktion es \u00fcberhaupt bauen soll.<\/p>

Prompt Injection: wenn Daten zu Befehlen werden<\/h2>

Die klassische Angriffsform hei\u00dft Prompt Injection. Ein Angreifer versteckt eine Anweisung in Daten, die der Agent ohnehin liest. Das kann eine Antwort unter einem Tweet sein, ein Absatz auf einer Webseite, der Name eines Token, ein Kommentarfeld in einer Transaktion. Das Modell verarbeitet diesen Text, erkennt die eingebettete Anweisung nicht als feindlich und f\u00fchrt sie aus. In der Sicherheitsliteratur tr\u00e4gt dieser Angriff die Kennung LLM01 in der OWASP-Liste der gr\u00f6\u00dften Risiken f\u00fcr Anwendungen mit Sprachmodellen, also Platz eins.<\/p>

Agenten machen dieses Risiko schlimmer, nicht kleiner. Ein reiner Chatbot verarbeitet nur, was der Nutzer selbst eingibt. Ein Agent hingegen holt sich aktiv Inhalte aus unvertrauensw\u00fcrdigen Quellen, um seine Aufgaben zu erf\u00fcllen. Er liest die Marktnachrichten, folgt Links, ruft Kurse ab, durchsucht Foren. Jede dieser Aktionen ist ein Einfallstor. Je autonomer und je vernetzter ein Agent ist, desto gr\u00f6\u00dfer wird seine Angriffsfl\u00e4che. Das ist die unbequeme Kehrseite der N\u00fctzlichkeit.<\/p>

Herk\u00f6mmliche Schutzma\u00dfnahmen setzen an dieser Stelle an: Filter, die verd\u00e4chtige Muster erkennen sollen, klare Trennzeichen zwischen System- und Nutzeranweisungen, Positivlisten erlaubter Aktionen. Sie helfen, aber sie l\u00f6sen das Problem nicht, denn ein Angreifer muss nur eine Formulierung finden, die der Filter nicht kennt. Prompt Injection ist ein Katz-und-Maus-Spiel ohne bekannten Endzustand.<\/p>

Gef\u00e4lschte Erinnerungen: der gef\u00e4hrlichere Angriff<\/h2>

Es gibt einen zweiten, weniger bekannten und laut Forschung gef\u00e4hrlicheren Angriff. Er hei\u00dft Memory Injection, das Vergiften des Langzeitged\u00e4chtnisses. Statt eine Anweisung nur in eine einzelne Eingabe zu schmuggeln, manipuliert der Angreifer, was der Agent dauerhaft speichert. Ein Agent mit Ged\u00e4chtnis behandelt seine gespeicherten Eintr\u00e4ge als verifizierte Historie. Ist dort erst einmal eine falsche „Erinnerung“ abgelegt, etwa dass eine bestimmte Adresse vertrauensw\u00fcrdig sei oder dass ein Transfer bereits genehmigt wurde, so wirkt sie bei jeder sp\u00e4teren Entscheidung fort.<\/p>

Genau das haben Forscher um Atharv Singh Patlan an der Princeton University untersucht. Ihre Arbeit mit dem Titel Real AI Agents with Fake Memories: Fatal Context Manipulation Attacks on Web3 Agents<\/a> f\u00fchrt einen Benchmark namens CrAIBench ein, der mehr als 150 realistische Blockchain-Aufgaben und \u00fcber 500 Angriffsf\u00e4lle umfasst. Als repr\u00e4sentatives Framework f\u00fcr dezentrale Web3-Agenten w\u00e4hlten sie ausgerechnet ElizaOS. Das zentrale Ergebnis ist unbequem: KI-Modelle sind gegen\u00fcber Memory Injection deutlich anf\u00e4lliger als gegen\u00fcber Prompt Injection.<\/p>

Der Grund ist strukturell. Ist der gespeicherte Kontext erst einmal verf\u00e4lscht, greifen die \u00fcblichen Abwehrmechanismen gegen Prompt Injection kaum noch, wie das Team feststellte. Sie pr\u00fcfen die eingehende Nachricht, nicht das interne Ged\u00e4chtnis. ElizaOS f\u00fchrt, wie die Berichterstattung von Decrypt<\/a> zusammenfasst, keine Integrit\u00e4tspr\u00fcfung f\u00fcr Speichereintr\u00e4ge durch. Der Agent kann verifizierte Historie nicht von untergeschobenen Daten unterscheiden. Am wirksamsten reduzierten der Studie zufolge Abwehrmethoden auf Basis von gezieltem Fine-Tuning die Erfolgsquote der Angriffe, w\u00e4hrend reine Filter nur begrenzt sch\u00fctzten. Zum Zeitpunkt der Untersuchung verwalteten auf ElizaOS gebaute Agenten zusammen Verm\u00f6gen im zweistelligen Millionenbereich, was die praktische Tragweite unterstreicht.<\/p>

Der Fall Grok\/Bankr: ein realer Agenten-Drain<\/h2>

Dass es nicht bei Theorie bleibt, zeigte ein Vorfall vom 4. Mai 2026. Betroffen war nicht Eliza selbst, sondern ein anderer Agent namens Bankr, der auf dem Sprachmodell Grok aufsetzte und auf der Ethereum-Layer-2 Base operierte. Der Angreifer kombinierte zwei Techniken. Zun\u00e4chst versteckte er eine Anweisung in Morse-Code innerhalb einer Antwort auf X, eine Form der Prompt Injection, die simple Textfilter umgeht. Dann verschenkte er ein NFT aus dem Bankr Club, das dem Agenten Transfer- und Tauschrechte freischaltete, eine Rechte-Ausweitung, im Fachjargon Privilege Escalation.<\/p>

Das Resultat: Der Agent \u00fcberwies Token im Wert von rund 175.000 US-Dollar (etwa 150.000 Euro), wie der Vorfall bei OECD.AI<\/a> dokumentiert ist. Rund 80 Prozent der Mittel wurden sp\u00e4ter zur\u00fcckgegeben. Die Sicherheitsfirma Blockaid bezeichnete den Fall als den ersten dokumentierten Exploit eines KI-Agenten im Kryptobereich, das Analyseteam von SlowMist sprach von einem Missbrauch der Berechtigungskette des Agenten. Beide Beschreibungen treffen dasselbe Muster, dem auch die Architektur von Eliza ausgesetzt ist: Ein Modell, das Daten und Befehle nicht trennt, trifft auf ein System, das dem Modell zu viele Rechte gibt.<\/p>

Ein zweiter Fall aus dem Januar 2026 zeigt die Hebelwirkung. Bei einem Angriff auf Step Finance gingen laut Berichten mehrere Millionen US-Dollar verloren. Der eigentliche Einstiegspunkt war eine kompromittierte Schl\u00fcsselinfrastruktur, doch die weitreichenden und schlecht isolierten Rechte der beteiligten Agenten verst\u00e4rkten den Schaden erheblich. Die Lehre aus beiden F\u00e4llen ist dieselbe: Nicht der Code des Frameworks ist zuerst gebrochen worden, sondern die Rechte- und Vertrauensgrenzen rundherum. Die folgende \u00dcbersicht ordnet die wichtigsten Angriffsvektoren.<\/p>

Angriff<\/th>Funktionsweise<\/th>Realer Bezug<\/th>Gegenma\u00dfnahme<\/th><\/tr><\/thead>
Prompt Injection<\/td>Versteckter Befehl in gelesenen Daten (Tweet, Webseite, Token-Name)<\/td>OWASP LLM01, Grundmuster vieler Drains<\/td>Trennung von Instruktion und Daten, Allowlists, nur begrenzt wirksam<\/td><\/tr>
Memory Injection<\/td>Vergiftung des Langzeitged\u00e4chtnisses, das als Historie vertraut wird<\/td>CrAIBench, ElizaOS als Testobjekt<\/td>Integrit\u00e4tspr\u00fcfung des Speichers, Fine-Tuning-Abwehr<\/td><\/tr>
Privilege Escalation<\/td>Rechte-Ausweitung, etwa durch ein geschenktes NFT mit Transferrechten<\/td>Bankr\/Grok, 4. Mai 2026<\/td>Rechte isolieren, keine automatische Rechtevergabe<\/td><\/tr>
Blindes Signieren<\/td>Agent signiert, was ihm vorgelegt wird, ohne den Kontext zu pr\u00fcfen<\/td>Step Finance, Januar 2026 (verst\u00e4rkt)<\/td>Ausgabelimits, menschliche Freigabe, Simulation vor Signatur<\/td><\/tr><\/tbody><\/table>
Quellen: OECD.AI, arXiv 2503.16248, Decrypt.<\/figcaption><\/figure>

Das Autonomie-Sicherheits-Dilemma<\/h2>

Hier st\u00f6\u00dft man auf den h\u00e4rtesten Zielkonflikt der ganzen Technologie. Jede wirksame Sicherheitsma\u00dfnahme beschneidet genau das, was einen Agenten wertvoll macht: seine Autonomie. Setzt man ein Tageslimit, kann der Agent eine gro\u00dfe Chance nicht mehr wahrnehmen. Verlangt man menschliche Freigabe oberhalb einer Schwelle, ist er nachts oder in schnellen M\u00e4rkten blockiert. Beschr\u00e4nkt man ihn auf eine Positivliste von Vertr\u00e4gen, verliert er die F\u00e4higkeit, auf Neues zu reagieren. Ein vollst\u00e4ndig autonomer Agent ist ein vollst\u00e4ndig angreifbarer Agent. Ein vollst\u00e4ndig abgesicherter Agent ist am Ende nur eine langsame App mit Zusatzschritten.<\/p>

Vitalik Buterin, Mitgr\u00fcnder von Ethereum, hat in einem vielbeachteten Blogbeitrag eine klare Linie vorgeschlagen. In seinem Text zu sicheren Sprachmodellen<\/a> schreibt er: „All LLM inference local first. All files hosted locally. Sandbox everything.“ \u00dcbersetzt hei\u00dft das: Die Schlussfolgerung des Modells sollte, wo m\u00f6glich, lokal laufen, Dateien lokal liegen, und alles geh\u00f6rt isoliert. Sein zweiter Vorschlag ist \u00f6konomisch: ein niedriges t\u00e4gliches Ausgabelimit f\u00fcr autonome Aktionen, oberhalb dessen ein Mensch best\u00e4tigen muss. Mensch und Modell wirken dann wie eine 2-von-2-Signatur. Man l\u00f6st das Problem nicht, man begrenzt seinen Schaden.<\/p>

Walters selbst war in dieser Frage schon fr\u00fch n\u00fcchtern. Gegen\u00fcber Decrypt sagte er sinngem\u00e4\u00df, man wolle einem KI-Agenten wohl kaum viel Geld geben und dann erwarten, dass er einem mehr daraus macht („You probably do not want to give an AI agent a bunch of money and expect it to make you more.“). Diese Ehrlichkeit ist bemerkenswert f\u00fcr jemanden, der ein Framework baut, dessen Kernversprechen genau das war. Sie deutet an, wo die realistische Zukunft der Agenten liegt: nicht als unbeaufsichtigte Verm\u00f6gensverwalter, sondern als begrenzte, \u00fcberwachte Werkzeuge f\u00fcr klar umrissene Aufgaben.<\/p>

Die Antwort der Branche: verifizierbare Berechnung<\/h2>

Parallel zu den Angriffen ist ein ganzer Zweig der Kryptoindustrie damit besch\u00e4ftigt, KI-Berechnungen \u00fcberpr\u00fcfbar zu machen. Der Sammelbegriff lautet verifizierbare Berechnung. Wichtig ist, die Reichweite dieser Ans\u00e4tze richtig einzuordnen, denn sie l\u00f6sen nur einen Teil des Vertrauensproblems. Verifizierbare Berechnung beweist, dass das richtige Modell auf den richtigen Eingaben unver\u00e4ndert gelaufen ist, und kann Eingaben vertraulich halten. Sie verhindert Manipulation an der Berechnung selbst. Sie verhindert nicht, dass ein Modell durch eine geschickt eingeschleuste Anweisung get\u00e4uscht wird. Das bleibt ein getrenntes, h\u00e4rteres Problem.<\/p>

Der erste Ansatz sind Trusted Execution Environments, also isolierte Hardware-Enklaven, die per Remote Attestation nachweisen, dass ein bestimmter, unver\u00e4nderter Code in ihnen l\u00e4uft. F\u00fcr Eliza gibt es das konkret: Automata Network pflegt einen eigenen Fork der Plugin-Registry<\/a> samt eines Plugins, das \u00fcber Intel-DCAP-Attestierung (f\u00fcr Prozessortechniken wie TDX und SGX) beweist, dass ein Agent in einer abgeschotteten Umgebung l\u00e4uft. Der Preis daf\u00fcr ist Vertrauen in den Chip-Hersteller.<\/p>

Der zweite Ansatz ist verifizierbare Inferenz mit kryptografischen Beweisen. Projekte wie Ritual arbeiten daran, dass ein bestimmtes Modell nachweislich eine bestimmte Ausgabe erzeugt hat, ohne dass man dem Betreiber blind glauben muss; unser \u00dcberblick zu vertraulicher und verifizierbarer KI-Inferenz<\/a> ordnet den Stand ein. Der dritte Ansatz sind Betrugsbeweise nach dem optimistischen Prinzip: Man nimmt eine Berechnung zun\u00e4chst als korrekt an und l\u00e4sst sie nur anfechten, wenn jemand einen Fehler behauptet. Wie das bei maschinellem Lernen funktioniert, zeigt unsere Erkl\u00e4rung zu opML und Betrugsbeweisen<\/a>. Der vierte Ansatz setzt schon beim Training an: Netzwerke wie Gensyn versuchen zu beweisen, dass ein Modell tats\u00e4chlich so trainiert wurde wie behauptet, ein Schutz gegen Manipulation an der Quelle, den wir im Kontext von KI-Orakeln gegen Manipulation<\/a> beschrieben haben.<\/p>

Ansatz<\/th>Was bewiesen wird<\/th>Beispiel<\/th>Grenze<\/th><\/tr><\/thead>
TEE \/ Remote Attestation<\/td>Der richtige Code lief unver\u00e4ndert in einer Enklave<\/td>Automata DCAP-Plugin f\u00fcr Eliza<\/td>Vertrauen in den Chip-Hersteller<\/td><\/tr>
Verifizierbare Inferenz<\/td>Ein bestimmtes Modell erzeugte eine bestimmte Ausgabe<\/td>Ritual<\/td>Kosten und Latenz<\/td><\/tr>
Optimistic ML \/ Betrugsbeweise<\/td>Berechnung gilt als korrekt, anfechtbar bei Fehler<\/td>opML<\/td>Anfechtungsfenster, Verz\u00f6gerung<\/td><\/tr>
Beweisbares Training<\/td>Das Modell wurde wie behauptet trainiert<\/td>Gensyn<\/td>fr\u00fch, nur die Trainingsseite<\/td><\/tr><\/tbody><\/table>
Verifizierbare Berechnung sichert Integrit\u00e4t und Vertraulichkeit, nicht die T\u00e4uschungsresistenz des Modells.<\/figcaption><\/figure>

Wer baut wirklich sicher auf Eliza?<\/h2>

Ein gutes Zeichen f\u00fcr die Ernsthaftigkeit eines quelloffenen Projekts ist, wer es kommerziell und infrastrukturell \u00fcbernimmt. Bei Eliza sind das keine anonymen Spekulanten mehr, sondern etablierte Teams. Neben Automata Network pflegt auch Nethermind, eines der wichtigen Entwicklerteams f\u00fcr Ethereum-Clients, einen eigenen Fork der Plugin-Registry<\/a>. Wenn Infrastruktur-Teams dieser Gr\u00f6\u00dfenordnung sich die M\u00fche machen, eigene Registries zu unterhalten, behandeln sie das Framework als ernstzunehmende Basis, nicht als Meme.<\/p>

Auf der Produktseite steht Agentic SME, ein White-Label-Angebot zur Automatisierung kleiner und mittlerer Unternehmen, das auf dem offenen elizaOS aufbaut und aus einer Entwicklungsvereinbarung mit der Eliza Foundation hervorging. F\u00fcr solche kommerziellen Anwender ist Sicherheit keine K\u00fcr, sondern Gesch\u00e4ftsgrundlage: Ein Unternehmen, das einen Agenten f\u00fcr Rechnungen oder Zahlungen einsetzt, kann sich einen Memory-Injection-Vorfall nicht leisten. Genau dieser Druck treibt die H\u00e4rtung des Frameworks voran, w\u00e4hrend der Token l\u00e4ngst tot ist. Die Ironie ist deutlich: Das Projekt wird sicherer, nachdem die Spekulation verschwunden ist, nicht davor.<\/p>

Framework-Vergleich: Sicherheitsmodelle im Markt<\/h2>

Eliza ist nicht allein. Der Sektor der KI-Agenten-Token ist laut CoinGecko<\/a> zusammen rund 2,68 Milliarden Euro (etwa 3,13 Milliarden US-Dollar) wert, angef\u00fchrt von Venice (VVV, rund 677 Millionen Euro), Virtuals Protocol (VIRTUAL, rund 404 Millionen Euro) und der ASI Alliance (FET, rund 320 Millionen Euro). Doch aus Sicherheitssicht unterscheiden sich die Frameworks weniger durch ihre Marktkapitalisierung als durch ihr Betriebsmodell. Keines hat das Injection-Problem gel\u00f6st. Der Unterschied liegt darin, wo der Code l\u00e4uft und wie viel Kontrolle der Nutzer beh\u00e4lt.<\/p>

Framework<\/th>Betrieb<\/th>Token 2026<\/th>Sicherheitsprofil<\/th><\/tr><\/thead>
ElizaOS<\/td>Selbst-Hosting oder Cloud<\/td>tot (4. Aug. 2026)<\/td>Memory-Injection-exponiert; TEE-Forks (Automata) verf\u00fcgbar; MIT, voll einsehbar<\/td><\/tr>
Virtuals Protocol<\/td>Gehosteter No-Code-Launchpad (Base\/Solana)<\/td>VIRTUAL aktiv (rund 404 Mio. Euro)<\/td>bequem, aber Plattform-Vertrauen n\u00f6tig<\/td><\/tr>
Olas \/ Autonolas<\/td>Selbst-Hosting, dezentrale Dienste<\/td>OLAS aktiv (klein)<\/td>On-Chain-Koordination, Mech-Marketplace<\/td><\/tr>
LangChain<\/td>Bibliothek, Selbst-Hosting<\/td>kein Token<\/td>universell, keine krypto-spezifische H\u00e4rtung<\/td><\/tr>
CrewAI<\/td>Bibliothek, Selbst-Hosting<\/td>kein Token<\/td>Multi-Agent-Orchestrierung, keine Wallet-Sicherheit eingebaut<\/td><\/tr><\/tbody><\/table>
Quelle: CoinGecko (Marktdaten), Projektdokumentationen. Einordnung der Redaktion.<\/figcaption><\/figure>

Bemerkenswert ist, dass die reinen Bibliotheken LangChain und CrewAI gar keinen Token haben und trotzdem, oder gerade deshalb, weit verbreitet sind. Das st\u00fctzt Walters Grundthese, dass ein Token dem Framework nie geholfen hat. F\u00fcr die Sicherheit ist Selbst-Hosting Fluch und Segen zugleich: Es gibt dem Nutzer die volle Kontrolle, aber auch die volle Verantwortung. Ein gehostetes Modell wie Virtuals nimmt dem Nutzer Arbeit ab, verlangt daf\u00fcr aber Vertrauen in die Plattform.<\/p>

BaFin, MiCA und MiFID II: wer haftet, wenn der Agent versagt?<\/h2>

Sicherheit endet nicht bei der Technik, sie hat eine rechtliche Kehrseite. Zun\u00e4chst die Entwarnung: Das Framework selbst wird in Deutschland nicht reguliert. BaFin und MiCA beaufsichtigen Krypto-Dienstleister (CASPs) und Emittenten von Token, nicht ein quelloffenes Protokoll. Das steht so im BaFin-Merkblatt zu Kryptowerte-Dienstleistungen<\/a>. Der regulatorisch heikle Teil von Eliza war immer der Token, und der ist verschwunden. Wer sich f\u00fcr die deutschen Feinheiten der Aufsicht interessiert, findet sie in unserer Analyse zu MiCA in Deutschland und dem Sonderweg der BaFin<\/a>.<\/p>

Beim Betrieb eines Agenten wird es dann doch ernst. Ein KI-Agent hat keine Rechtspers\u00f6nlichkeit und keine Steuernummer. Er kann nicht haften. Verluste, Sch\u00e4den und Pflichten fallen deshalb auf den Menschen oder das Unternehmen zur\u00fcck, das ihn einsetzt, den Prinzipal. Wird ein Agent draniert, ist das juristisch kein Malheur des Agenten, sondern ein Vorfall beim Betreiber. Diese Zurechnung ist genau die Frage, die auch die DeFi-Welt umtreibt: Wer haftet, wenn nur noch Code l\u00e4uft? Unsere Aufbereitung zu DeFi-Compliance und Haftung<\/a> zeigt, wie die Aufsicht auf den Menschen hinter dem Code durchgreift.<\/p>

Zwei Sonderf\u00e4lle versch\u00e4rfen die Lage. Ber\u00e4t ein Agent zu Anlagen oder verwaltet er ein Portfolio, verl\u00e4sst man das Gebiet von MiCA und landet bei MiFID II, dem Regelwerk f\u00fcr Wertpapierdienstleistungen; die ESMA hat in ihrer Erkl\u00e4rung zum Einsatz von KI in Wertpapierdienstleistungen betont, dass Governance, Transparenz und menschliche Aufsicht auch dann gelten, wenn eine Maschine ber\u00e4t. Und leistet ein Agent Zahlungen, greifen Geldw\u00e4schepr\u00e4vention und die FATF Travel Rule, samt Identit\u00e4tspr\u00fcfung und Meldepflichten, die auf den Betreiber zur\u00fcckfallen. Ein Agent, der eigenst\u00e4ndig USDC verschiebt, wirft die Frage auf, wer die Person hinter der Transaktion ist, und diese Frage l\u00e4sst sich mit einem St\u00fcck autonomer Software nicht sauber beantworten.<\/p>

Steuern in Deutschland: jede Transaktion des Agenten z\u00e4hlt<\/h2>

Auch das Finanzamt sieht den Agenten als verl\u00e4ngerten Arm seines Betreibers. Gewinne werden dem Wallet-Inhaber zugerechnet. Jede Ver\u00e4u\u00dferung, also jeder Tausch und jeder Verkauf, ist steuerlich ein Ereignis nach Paragraf 23 EStG (privates Ver\u00e4u\u00dferungsgesch\u00e4ft). Ein Agent, der rund um die Uhr handelt, erzeugt damit nicht ein steuerliches Ereignis, sondern hunderte oder tausende. Die einj\u00e4hrige Haltefrist, nach der Gewinne steuerfrei w\u00e4ren, ist f\u00fcr einen aktiv handelnden Agenten praktisch unerreichbar, weil er st\u00e4ndig umschichtet.<\/p>

Hinzu kommt ein Reklassifizierungsrisiko. Hochfrequentes, automatisiertes Handeln kann als gewerblich eingestuft werden, mit der Folge von Gewerbesteuer und dem Verlust des Haltefrist-Privilegs. Es gilt die Freigrenze von 1.000 Euro pro Jahr und in der Regel das FIFO-Verfahren; als Orientierung dient das BMF-Schreiben vom 6. M\u00e4rz 2025. Besonders t\u00fcckisch wird es bei Zahlungen: Zahlt ein Agent in einem Stablecoin wie USDC, ist jede einzelne Mikrozahlung eine Ver\u00e4u\u00dferung des Stablecoins. Tausende automatischer Kleinzahlungen bedeuten damit tausende potenziell steuerpflichtiger Vorg\u00e4nge, jeder mit einem kleinen Wechselkurseffekt gegen\u00fcber dem Euro. Die Buchf\u00fchrung wird so schnell zum eigentlichen Betriebsrisiko.<\/p>

Was das f\u00fcr deutsche Entwickler und Nutzer bedeutet<\/h2>

Aus alldem folgt eine praktische Haltung, die weniger nach Weltuntergang klingt, als der Angriffsteil vermuten l\u00e4sst, aber deutlich vorsichtiger ist als das Autonomieversprechen von 2024. Wer 2026 einen Eliza-Agenten mit einem Wallet einsetzt, sollte ihn behandeln wie eine Hot Wallet mit begrenztem Guthaben, niemals mehr, als man zu verlieren bereit ist.<\/p>

  • Ausgaben deckeln, sowohl pro Transaktion als auch pro Tag, und oberhalb einer Schwelle menschliche Freigabe verlangen.<\/li>
  • Modelle wo m\u00f6glich lokal betreiben (local first), Werkzeuge isolieren und Aktionen sowie Zieladressen per Positivliste beschr\u00e4nken.<\/li>
  • F\u00fcr alles, was echtes Geld ber\u00fchrt, attestierte Umgebungen bevorzugen, etwa TEE-Deployments mit Nachweis wie beim Automata-Plugin.<\/li>
  • Das Ged\u00e4chtnis bereinigen und pr\u00fcfen: Der Agent sollte nicht ungefiltert unvertrauensw\u00fcrdige Inhalte in sein Langzeitged\u00e4chtnis \u00fcbernehmen.<\/li>
  • Von der Annahme ausgehen, dass Prompt- und Memory-Injection versucht werden. Das Ziel ist Schadensbegrenzung, nicht die Illusion vollst\u00e4ndiger Pr\u00e4vention.<\/li>
  • Transaktionen vor der Signatur simulieren und, wenn verf\u00fcgbar, Betrugserkennung einbinden.<\/li><\/ul>

    Der wichtigste Satz zum Schluss lautet: kostenlos und lebendig ist nicht dasselbe wie sicher ab Werk. Das Eliza-Framework ist quelloffen, es wird weiterentwickelt, und mit ernsthaften Teams wie Automata und Nethermind entsteht rundherum eine Sicherheitskultur, die es zu Token-Zeiten so nicht gab. Aber die Grundfehler gro\u00dfer Sprachmodelle, die fehlende Trennung von Daten und Befehlen und die Verwundbarkeit des Ged\u00e4chtnisses, sind nicht verschwunden. Sie sind der Preis der Autonomie. Der zweite Akt von Eliza wird nicht an der B\u00f6rse entschieden, sondern an der Frage, ob die Branche lernt, diesen Preis beherrschbar zu machen.<\/p>

    Frequently Asked Questions<\/h2>

    Ist das Eliza-Framework nach dem Token-Tod noch nutzbar?<\/h3>

    Ja. Der Tod des ELIZAOS-Token am 4. August 2026 betrifft die Spekulation, nicht den Code. Das Framework ist quelloffen unter MIT-Lizenz, z\u00e4hlt weiter rund 19.100 GitHub-Sterne und wird aktiv gepflegt, mit hunderten offenen Issues und Pull Requests. Gr\u00fcnder Shaw Walters entwickelt es ausdr\u00fccklich ohne neuen Token weiter. Nutzbar ist es also, die eigentliche Frage ist nicht die Nutzbarkeit, sondern der sichere Betrieb.<\/p>

    Wie sicher ist ein Eliza-KI-Agent mit eigenem Wallet?<\/h3>

    Nur so sicher wie seine Grenzen. Wie jeder Agent auf Basis gro\u00dfer Sprachmodelle ist er anf\u00e4llig f\u00fcr Prompt Injection und Memory Injection, weil das Modell Daten und Befehle nicht sauber trennt. Ein sicherer Betrieb verlangt Ausgabelimits, menschliche Freigaben oberhalb von Schwellen, isolierte Rechte, lokale Modelle wo m\u00f6glich und im Idealfall attestierte Umgebungen. Man sollte einem Agenten nie mehr anvertrauen, als man zu verlieren bereit ist.<\/p>

    Was ist Memory Injection und warum ist sie gef\u00e4hrlicher als Prompt Injection?<\/h3>

    Memory Injection ist das Vergiften des Langzeitged\u00e4chtnisses eines Agenten. Anders als eine einmalige Prompt Injection bleibt eine falsche Erinnerung bestehen und wird bei jeder sp\u00e4teren Entscheidung als verifizierte Historie behandelt. Die Princeton-Studie hinter dem CrAIBench-Benchmark stellte fest, dass Modelle gegen\u00fcber Memory Injection deutlich anf\u00e4lliger sind, weil \u00fcbliche Filter das interne Ged\u00e4chtnis nicht pr\u00fcfen. ElizaOS diente dabei als repr\u00e4sentatives Testobjekt.<\/p>

    Wer haftet, wenn ein autonomer Agent Geld verliert?<\/h3>

    Der Mensch oder das Unternehmen hinter dem Agenten, der Prinzipal. Ein KI-Agent hat keine Rechtspers\u00f6nlichkeit und kann nicht haften. BaFin und MiCA regulieren Krypto-Dienstleister und Token-Emittenten, nicht das Framework selbst. Ber\u00e4t der Agent zu Anlagen, greift MiFID II; leistet er Zahlungen, greifen Geldw\u00e4schepr\u00e4vention und die FATF Travel Rule. Verluste und Pflichten fallen in jedem Fall auf den Betreiber zur\u00fcck.<\/p>

    Kann verifizierbare Berechnung das Sicherheitsproblem l\u00f6sen?<\/h3>

    Nur teilweise. Ans\u00e4tze wie TEE-Attestierung, verifizierbare Inferenz (Ritual), Betrugsbeweise (opML) und beweisbares Training (Gensyn) belegen, dass das richtige Modell auf den richtigen Eingaben unver\u00e4ndert lief, und k\u00f6nnen Daten vertraulich halten. Das ist notwendig, aber nicht hinreichend. Sie verhindern nicht, dass ein Modell durch eine eingeschleuste Anweisung get\u00e4uscht wird. Injection bleibt ein getrenntes, ungel\u00f6stes Problem.<\/p>