Eliza framework 2026: Wie sicher ist ein KI-Agent mit Wallet?

Am 4. August 2026 schrieb Shaw Walters, der Gründer 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 überwiesen hatte, wie CoinDesk berichtete. Zum Höchststand 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 bei rund 1,18 Millionen Euro, ein Minus von mehr als 99,9 Prozent.

Und doch lebt Eliza weiter. Nicht der Token, sondern der Code: das quelloffene TypeScript-Framework auf GitHub zählt weiter rund 19.100 Sterne, die Entwicklung läuft 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 übrig, die von Anfang an die einzige war, die zählte: Kann man einer Software, die ihr eigenes Wallet kontrolliert und ihre eigenen Transaktionen signiert, tatsächlich Geld anvertrauen? Das ist der zweite Akt von Eliza, und er handelt nicht von Preiszielen, sondern von Vertrauen.

Dieser Artikel ist eine Bestandsaufnahme der Sicherheit. Er erklärt, 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 über Trusted Execution Environments bis zu Betrugsbeweisen. Am Ende steht die regulatorische und steuerliche Realität für deutsche Entwickler und Nutzer.

Was Eliza 2026 wirklich ist: Framework statt Token

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ächtnis und einer Reihe von Werkzeugen, mit denen er Transaktionen auslösen kann. Er signiert seine eigenen Aktionen. Das unterscheidet ihn grundlegend von einem regelbasierten Trading-Bot, der nur ausführt, was ein Mensch vorab programmiert hat.

Die Geschichte des Projekts ist bekannt und wurde von HOGE Wire mehrfach erzählt: gestartet als ai16z im Oktober 2024 auf Solana, umbenannt in ElizaOS im Januar 2025, dann die Token-Migration, der Kurssturz und schließlich das Ende des Token am 4. August 2026. Der entscheidende Punkt für 2026 ist, dass Token und Framework nie dasselbe waren. Der Token war die spekulative Hülle. Das Framework ist Ingenieursarbeit. Walters brachte den Unterschied gegenüber Decrypt 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öre ihm, ein Token werde es nie wieder geben.

Dass das Framework lebt, lässt sich messen. Das GitHub-Repository trägt 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.

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.

Warum Sicherheit jetzt die einzige Frage ist

Ein Sprachmodell, das eine falsche Antwort gibt, ärgert 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ückbuchen, keinen Kundenservice, keine Stornierung. Was einmal signiert und bestätigt ist, ist weg.

Solange der Token gehandelt wurde, überlagerte die Kursfantasie dieses Risiko. Anleger diskutierten über Marktkapitalisierung und Migration, nicht über Angriffsflächen. Mit dem Ende des Token fällt diese Ebene weg. Übrig bleibt die nüchterne Frage eines jeden Entwicklers, der einen Eliza-Agenten mit einem Wallet ausstattet: Unter welchen Umständen wird dieser Agent dazu gebracht, das Falsche zu tun, und wie viel kann dabei verloren gehen?

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ächtnis. Jede dieser Quellen kann manipuliert sein. Und weil der Agent über Schlüssel verfügt, ist jede erfolgreiche Manipulation potenziell eine Überweisung. Sicherheit ist damit nicht ein Feature unter vielen, sondern die Bedingung dafür, dass die ganze Idee überhaupt tragfähig ist.

Die Anatomie eines KI-Agenten: wo das Vertrauen bricht

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. Über diese Plugins registrieren sich vier Grundbausteine: Actions, also Handlungen, die der Agent ausführen kann, darunter das Senden oder Tauschen von Token; Providers, die dem Modell Kontext liefern; Evaluators, die Ergebnisse bewerten; und Services, die Verbindungen nach außen halten.

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önlichkeitsbeschreibung 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ßer Sprachmodelle.

Wer sich mit Hardware-Wallets auskennt, kennt die Analogie: das blinde Signieren. Ein Nutzer, der eine Transaktion bestätigt, ohne genau zu prüfen, 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ässt sich von außen beeinflussen. Der Vertrauensbruch passiert nicht in der Kryptografie, die funktioniert einwandfrei, sondern eine Ebene darüber, dort, wo das Modell entscheidet, welche Transaktion es überhaupt bauen soll.

Prompt Injection: wenn Daten zu Befehlen werden

Die klassische Angriffsform heißt 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ührt sie aus. In der Sicherheitsliteratur trägt dieser Angriff die Kennung LLM01 in der OWASP-Liste der größten Risiken für Anwendungen mit Sprachmodellen, also Platz eins.

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ürdigen Quellen, um seine Aufgaben zu erfüllen. 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ößer wird seine Angriffsfläche. Das ist die unbequeme Kehrseite der Nützlichkeit.

Herkömmliche Schutzmaßnahmen setzen an dieser Stelle an: Filter, die verdächtige Muster erkennen sollen, klare Trennzeichen zwischen System- und Nutzeranweisungen, Positivlisten erlaubter Aktionen. Sie helfen, aber sie lösen 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.

Gefälschte Erinnerungen: der gefährlichere Angriff

Es gibt einen zweiten, weniger bekannten und laut Forschung gefährlicheren Angriff. Er heißt Memory Injection, das Vergiften des Langzeitgedächtnisses. Statt eine Anweisung nur in eine einzelne Eingabe zu schmuggeln, manipuliert der Angreifer, was der Agent dauerhaft speichert. Ein Agent mit Gedächtnis behandelt seine gespeicherten Einträge als verifizierte Historie. Ist dort erst einmal eine falsche „Erinnerung“ abgelegt, etwa dass eine bestimmte Adresse vertrauenswürdig sei oder dass ein Transfer bereits genehmigt wurde, so wirkt sie bei jeder späteren Entscheidung fort.

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 führt einen Benchmark namens CrAIBench ein, der mehr als 150 realistische Blockchain-Aufgaben und über 500 Angriffsfälle umfasst. Als repräsentatives Framework für dezentrale Web3-Agenten wählten sie ausgerechnet ElizaOS. Das zentrale Ergebnis ist unbequem: KI-Modelle sind gegenüber Memory Injection deutlich anfälliger als gegenüber Prompt Injection.

Der Grund ist strukturell. Ist der gespeicherte Kontext erst einmal verfälscht, greifen die üblichen Abwehrmechanismen gegen Prompt Injection kaum noch, wie das Team feststellte. Sie prüfen die eingehende Nachricht, nicht das interne Gedächtnis. ElizaOS führt, wie die Berichterstattung von Decrypt zusammenfasst, keine Integritätsprüfung für Speichereinträge 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ährend reine Filter nur begrenzt schützten. Zum Zeitpunkt der Untersuchung verwalteten auf ElizaOS gebaute Agenten zusammen Vermögen im zweistelligen Millionenbereich, was die praktische Tragweite unterstreicht.

Der Fall Grok/Bankr: ein realer Agenten-Drain

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ächst 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.

Das Resultat: Der Agent überwies Token im Wert von rund 175.000 US-Dollar (etwa 150.000 Euro), wie der Vorfall bei OECD.AI dokumentiert ist. Rund 80 Prozent der Mittel wurden später zurückgegeben. 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.

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üsselinfrastruktur, doch die weitreichenden und schlecht isolierten Rechte der beteiligten Agenten verstärkten den Schaden erheblich. Die Lehre aus beiden Fällen ist dieselbe: Nicht der Code des Frameworks ist zuerst gebrochen worden, sondern die Rechte- und Vertrauensgrenzen rundherum. Die folgende Übersicht ordnet die wichtigsten Angriffsvektoren.

Das Autonomie-Sicherheits-Dilemma

Hier stößt man auf den härtesten Zielkonflikt der ganzen Technologie. Jede wirksame Sicherheitsmaßnahme beschneidet genau das, was einen Agenten wertvoll macht: seine Autonomie. Setzt man ein Tageslimit, kann der Agent eine große Chance nicht mehr wahrnehmen. Verlangt man menschliche Freigabe oberhalb einer Schwelle, ist er nachts oder in schnellen Märkten blockiert. Beschränkt man ihn auf eine Positivliste von Verträgen, verliert er die Fähigkeit, auf Neues zu reagieren. Ein vollständig autonomer Agent ist ein vollständig angreifbarer Agent. Ein vollständig abgesicherter Agent ist am Ende nur eine langsame App mit Zusatzschritten.

Vitalik Buterin, Mitgründer von Ethereum, hat in einem vielbeachteten Blogbeitrag eine klare Linie vorgeschlagen. In seinem Text zu sicheren Sprachmodellen schreibt er: „All LLM inference local first. All files hosted locally. Sandbox everything.“ Übersetzt heißt das: Die Schlussfolgerung des Modells sollte, wo möglich, lokal laufen, Dateien lokal liegen, und alles gehört isoliert. Sein zweiter Vorschlag ist ökonomisch: ein niedriges tägliches Ausgabelimit für autonome Aktionen, oberhalb dessen ein Mensch bestätigen muss. Mensch und Modell wirken dann wie eine 2-von-2-Signatur. Man löst das Problem nicht, man begrenzt seinen Schaden.

Walters selbst war in dieser Frage schon früh nüchtern. Gegenüber Decrypt sagte er sinngemäß, 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ür jemanden, der ein Framework baut, dessen Kernversprechen genau das war. Sie deutet an, wo die realistische Zukunft der Agenten liegt: nicht als unbeaufsichtigte Vermögensverwalter, sondern als begrenzte, überwachte Werkzeuge für klar umrissene Aufgaben.

Die Antwort der Branche: verifizierbare Berechnung

Parallel zu den Angriffen ist ein ganzer Zweig der Kryptoindustrie damit beschäftigt, KI-Berechnungen überprüfbar zu machen. Der Sammelbegriff lautet verifizierbare Berechnung. Wichtig ist, die Reichweite dieser Ansätze richtig einzuordnen, denn sie lösen nur einen Teil des Vertrauensproblems. Verifizierbare Berechnung beweist, dass das richtige Modell auf den richtigen Eingaben unverändert 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äuscht wird. Das bleibt ein getrenntes, härteres Problem.

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

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 Überblick zu vertraulicher und verifizierbarer KI-Inferenz ordnet den Stand ein. Der dritte Ansatz sind Betrugsbeweise nach dem optimistischen Prinzip: Man nimmt eine Berechnung zunächst als korrekt an und lässt sie nur anfechten, wenn jemand einen Fehler behauptet. Wie das bei maschinellem Lernen funktioniert, zeigt unsere Erklärung zu opML und Betrugsbeweisen. Der vierte Ansatz setzt schon beim Training an: Netzwerke wie Gensyn versuchen zu beweisen, dass ein Modell tatsächlich so trainiert wurde wie behauptet, ein Schutz gegen Manipulation an der Quelle, den wir im Kontext von KI-Orakeln gegen Manipulation beschrieben haben.

Wer baut wirklich sicher auf Eliza?

Ein gutes Zeichen für die Ernsthaftigkeit eines quelloffenen Projekts ist, wer es kommerziell und infrastrukturell übernimmt. Bei Eliza sind das keine anonymen Spekulanten mehr, sondern etablierte Teams. Neben Automata Network pflegt auch Nethermind, eines der wichtigen Entwicklerteams für Ethereum-Clients, einen eigenen Fork der Plugin-Registry. Wenn Infrastruktur-Teams dieser Größenordnung sich die Mühe machen, eigene Registries zu unterhalten, behandeln sie das Framework als ernstzunehmende Basis, nicht als Meme.

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ür solche kommerziellen Anwender ist Sicherheit keine Kür, sondern Geschäftsgrundlage: Ein Unternehmen, das einen Agenten für Rechnungen oder Zahlungen einsetzt, kann sich einen Memory-Injection-Vorfall nicht leisten. Genau dieser Druck treibt die Härtung des Frameworks voran, während der Token längst tot ist. Die Ironie ist deutlich: Das Projekt wird sicherer, nachdem die Spekulation verschwunden ist, nicht davor.

Framework-Vergleich: Sicherheitsmodelle im Markt

Eliza ist nicht allein. Der Sektor der KI-Agenten-Token ist laut CoinGecko zusammen rund 2,68 Milliarden Euro (etwa 3,13 Milliarden US-Dollar) wert, angeführt 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öst. Der Unterschied liegt darin, wo der Code läuft und wie viel Kontrolle der Nutzer behält.

Bemerkenswert ist, dass die reinen Bibliotheken LangChain und CrewAI gar keinen Token haben und trotzdem, oder gerade deshalb, weit verbreitet sind. Das stützt Walters Grundthese, dass ein Token dem Framework nie geholfen hat. Für 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ür aber Vertrauen in die Plattform.

BaFin, MiCA und MiFID II: wer haftet, wenn der Agent versagt?

Sicherheit endet nicht bei der Technik, sie hat eine rechtliche Kehrseite. Zunächst 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. Der regulatorisch heikle Teil von Eliza war immer der Token, und der ist verschwunden. Wer sich für die deutschen Feinheiten der Aufsicht interessiert, findet sie in unserer Analyse zu MiCA in Deutschland und dem Sonderweg der BaFin.

Beim Betrieb eines Agenten wird es dann doch ernst. Ein KI-Agent hat keine Rechtspersönlichkeit und keine Steuernummer. Er kann nicht haften. Verluste, Schäden und Pflichten fallen deshalb auf den Menschen oder das Unternehmen zurück, 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äuft? Unsere Aufbereitung zu DeFi-Compliance und Haftung zeigt, wie die Aufsicht auf den Menschen hinter dem Code durchgreift.

Zwei Sonderfälle verschärfen die Lage. Berät ein Agent zu Anlagen oder verwaltet er ein Portfolio, verlässt man das Gebiet von MiCA und landet bei MiFID II, dem Regelwerk für Wertpapierdienstleistungen; die ESMA hat in ihrer Erklärung zum Einsatz von KI in Wertpapierdienstleistungen betont, dass Governance, Transparenz und menschliche Aufsicht auch dann gelten, wenn eine Maschine berät. Und leistet ein Agent Zahlungen, greifen Geldwäscheprävention und die FATF Travel Rule, samt Identitätsprüfung und Meldepflichten, die auf den Betreiber zurückfallen. Ein Agent, der eigenständig USDC verschiebt, wirft die Frage auf, wer die Person hinter der Transaktion ist, und diese Frage lässt sich mit einem Stück autonomer Software nicht sauber beantworten.

Steuern in Deutschland: jede Transaktion des Agenten zählt

Auch das Finanzamt sieht den Agenten als verlängerten Arm seines Betreibers. Gewinne werden dem Wallet-Inhaber zugerechnet. Jede Veräußerung, also jeder Tausch und jeder Verkauf, ist steuerlich ein Ereignis nach Paragraf 23 EStG (privates Veräußerungsgeschäft). Ein Agent, der rund um die Uhr handelt, erzeugt damit nicht ein steuerliches Ereignis, sondern hunderte oder tausende. Die einjährige Haltefrist, nach der Gewinne steuerfrei wären, ist für einen aktiv handelnden Agenten praktisch unerreichbar, weil er ständig umschichtet.

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ärz 2025. Besonders tückisch wird es bei Zahlungen: Zahlt ein Agent in einem Stablecoin wie USDC, ist jede einzelne Mikrozahlung eine Veräußerung des Stablecoins. Tausende automatischer Kleinzahlungen bedeuten damit tausende potenziell steuerpflichtiger Vorgänge, jeder mit einem kleinen Wechselkurseffekt gegenüber dem Euro. Die Buchführung wird so schnell zum eigentlichen Betriebsrisiko.

Was das für deutsche Entwickler und Nutzer bedeutet

Aus alldem folgt eine praktische Haltung, die weniger nach Weltuntergang klingt, als der Angriffsteil vermuten lässt, 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.

• Ausgaben deckeln, sowohl pro Transaktion als auch pro Tag, und oberhalb einer Schwelle menschliche Freigabe verlangen.
• Modelle wo möglich lokal betreiben (local first), Werkzeuge isolieren und Aktionen sowie Zieladressen per Positivliste beschränken.
• Für alles, was echtes Geld berührt, attestierte Umgebungen bevorzugen, etwa TEE-Deployments mit Nachweis wie beim Automata-Plugin.
• Das Gedächtnis bereinigen und prüfen: Der Agent sollte nicht ungefiltert unvertrauenswürdige Inhalte in sein Langzeitgedächtnis übernehmen.
• Von der Annahme ausgehen, dass Prompt- und Memory-Injection versucht werden. Das Ziel ist Schadensbegrenzung, nicht die Illusion vollständiger Prävention.
• Transaktionen vor der Signatur simulieren und, wenn verfügbar, Betrugserkennung einbinden.

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ßer Sprachmodelle, die fehlende Trennung von Daten und Befehlen und die Verwundbarkeit des Gedächtnisses, sind nicht verschwunden. Sie sind der Preis der Autonomie. Der zweite Akt von Eliza wird nicht an der Börse entschieden, sondern an der Frage, ob die Branche lernt, diesen Preis beherrschbar zu machen.

Frequently Asked Questions

Ist das Eliza-Framework nach dem Token-Tod noch nutzbar?

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

Wie sicher ist ein Eliza-KI-Agent mit eigenem Wallet?

Nur so sicher wie seine Grenzen. Wie jeder Agent auf Basis großer Sprachmodelle ist er anfällig für 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öglich und im Idealfall attestierte Umgebungen. Man sollte einem Agenten nie mehr anvertrauen, als man zu verlieren bereit ist.

Was ist Memory Injection und warum ist sie gefährlicher als Prompt Injection?

Memory Injection ist das Vergiften des Langzeitgedächtnisses eines Agenten. Anders als eine einmalige Prompt Injection bleibt eine falsche Erinnerung bestehen und wird bei jeder späteren Entscheidung als verifizierte Historie behandelt. Die Princeton-Studie hinter dem CrAIBench-Benchmark stellte fest, dass Modelle gegenüber Memory Injection deutlich anfälliger sind, weil übliche Filter das interne Gedächtnis nicht prüfen. ElizaOS diente dabei als repräsentatives Testobjekt.

Wer haftet, wenn ein autonomer Agent Geld verliert?

Der Mensch oder das Unternehmen hinter dem Agenten, der Prinzipal. Ein KI-Agent hat keine Rechtspersönlichkeit und kann nicht haften. BaFin und MiCA regulieren Krypto-Dienstleister und Token-Emittenten, nicht das Framework selbst. Berät der Agent zu Anlagen, greift MiFID II; leistet er Zahlungen, greifen Geldwäscheprävention und die FATF Travel Rule. Verluste und Pflichten fallen in jedem Fall auf den Betreiber zurück.

Kann verifizierbare Berechnung das Sicherheitsproblem lösen?

Nur teilweise. Ansätze wie TEE-Attestierung, verifizierbare Inferenz (Ritual), Betrugsbeweise (opML) und beweisbares Training (Gensyn) belegen, dass das richtige Modell auf den richtigen Eingaben unverändert lief, und können Daten vertraulich halten. Das ist notwendig, aber nicht hinreichend. Sie verhindern nicht, dass ein Modell durch eine eingeschleuste Anweisung getäuscht wird. Injection bleibt ein getrenntes, ungelöstes Problem.

Marcus Okafor schreibt für HOGE Wire über die Schnittstelle von künstlicher Intelligenz, Krypto und der Technik dahinter.