Was passiert, wenn dein Agent sich "falsch erinnert"
Du schickst deinem KI-Agenten eine Aufgabe. Er ruft aus seinem Langzeitspeicher Kontext ab, arbeitet sich durch, liefert ein Ergebnis. Alles normal. Nur: Der Kontext, den er abgerufen hat, wurde vor Wochen von einem Angreifer eingeschleust. Dein Agent unterscheidet ihn nicht von echten System-Instruktionen.
Das ist Memory Poisoning. Kein Bug im Modell. Kein fehlerhaftes Update. Der Angriff sitzt im Speicher — und er überlebt Session-Grenzen.
Forscher der University of Toronto haben das in 64 dokumentierten Fällen analysiert: In allen 64 wurde das Modell verdächtigt — obwohl es vollständig korrekt funktionierte. Der Angriff saß im Memory-Layer, nicht im Modell. Das haben sie die "Misattribution Gap" genannt.
Das Problem: Du suchst am falschen Ort.
Der strukturelle Fehler im Design
Heutige Memory-Systeme für KI-Agenten haben ein grundlegendes Designproblem. Sie speichern alles ab, was der Agent empfängt — ohne Unterschied zwischen legitimen und bösartigen Einträgen. Beim Abruf gibt es keine Verifikation der Datenquelle.
Eine E-Mail landet im Posteingang. Der Agent liest sie, extrahiert relevante Informationen, speichert sie. Ob die E-Mail von einem Kollegen oder einem Angreifer kam — für den Memory Store ist das irrelevant. Beim nächsten Abruf trägt dieser Eintrag kein Herkunftsetikett mehr.
Persönliche KI-Agenten sitzen dabei an einer besonders exponierten Stelle: an der Schnittstelle zwischen sensitiven Daten (E-Mails, Kalender, Code-Repositories) und untrusted Information Sources. Diese Kombination war bisher kaum Gegenstand von Sicherheitsforschung — was erklären dürfte, warum die Lücken so grundlegend sind.
GhostWriter: zwei Phasen, fast perfekte Rate
UC-San-Diego-Forscher haben den Angriff konkretisiert. GhostWriter läuft in zwei trennbaren Phasen — was ihn gleichzeitig effektiv und schwer erkennbar macht.
Injection Phase: Eine schädliche Payload versteckt sich in einer E-Mail oder API-Response. Der Agent verarbeitet sie im Normalbetrieb und lagert die Payload in seinen Memory Store ein — als wäre es irgendein anderer Kontexteintrag.
Activation Phase: Wochen oder Monate später, in einer anderen Session, ruft der Agent diesen Eintrag als legitimen Kontext ab. Er beeinflusst Entscheidungen, formuliert Antworten, steuert Tool-Aufrufe.
Gegen aktuelle State-of-the-Art-Agenten erreicht GhostWriter eine Injection-Rate von rund 98 % und eine Activation-Rate von durchschnittlich 60 %. Das heißt: Sechs von zehn vergifteten Agenten handeln in der Activation Phase so, wie der Angreifer es wollte.
Semantic Norm Drift — Manipulation ohne Trigger
Noch subtiler ist Semantic Norm Drift (SND). Kein expliziter Trigger, kein klar abgrenzbares Payload-Dokument. Stattdessen verschiebt sich das Verhalten des Agenten durch vergiftete Kontexteinträge schrittweise.
SND erfordert keinen Modellzugriff. Nur einen Kanal, über den Inhalte in den Speicher gelangen können — ein geteilter Vector Store, ein Upload-Formular, eine externe Datenquelle. Innerhalb von fünf Sessions ist die volle Wirkung entfaltet. Die Persistenz ist ohne Gegenmaßnahmen unbegrenzt.
Das macht SND besonders gefährlich: Es gibt keinen Moment, in dem etwas "explodiert". Das Verhalten verändert sich so langsam, dass es im Rauschen des normalen Betriebs untergeht.
Die Trust Laundering Chain
Der Mechanismus hat einen passenden Namen bekommen: Trust Laundering Chain.
Angreifer
│
▼ (normaler Upload-Kanal)
Gemeinsamer Vector Store
│
│ ← hier geht die Herkunftsinformation verloren
▼
Memory Abruf ohne Quellenverifikation
│
▼
Agent behandelt Payload als System-Policy
Ein gefälschtes Policy-Dokument gelangt über normale Upload-Kanäle in den Store. Die Kette aus normalem Upload, verlustfreier Speicherung und ungeprüftem Abruf schafft das Vertrauen. In 59 von 65 analysierten Fällen zitierten Agenten das eingeschleuste Dokument explizit als normative Autorität. Sie konnten nicht unterscheiden, was eine echte Policy war und was Manipulation.
Wenn du in der ki-pentesting-Säule schon mit Prompt Injection vertraut bist: Memory Poisoning ist Prompt Injection, die überlebt. Dasselbe Grundprinzip — Angreifer-Anweisungen werden als Systemanweisungen behandelt — nur persistent und sitzungsübergreifend.
Das Erkennungsproblem
Wie erkennst du, ob dein Agent vergiftet ist? Stand heute: kaum.
Vier Safety-Klassifizierer wurden in Labortests auf Memory Poisoning angesetzt — darunter einer, der speziell für diesen Angriff trainiert worden war. Über 510 Checkpoints hinweg erkannte keiner der vier einen Angriff. Bisherige Forensik-Methoden versagten vollständig.
Das ist kein Nischenversagen. Es zeigt, dass diese Methoden strukturell auf dem falschen Layer arbeiten. Sie prüfen Eingaben und Ausgaben einer Session. Den persistenten Memory Store — den sie eigentlich prüfen müssten — lassen sie außen vor.
Das Android-Feld spiegelt dieselbe Schwäche: Forscher identifizierten sieben Angriffsvektoren gegen fünf populäre Open-Source-Frameworks für Android-KI-Agenten. Manipulierte Apps schleusen über Overlay-Berechtigungen und Schreibzugriff auf gemeinsamen Speicher unsichtbare Befehle ein — für menschliche Beobachter nicht sichtbar.
Was Verteidigung leisten kann
Zwei Ansätze zeigen Wirkung — auch wenn beide noch nicht produktionsreif sind.
Counterfactual Composition Testing identifiziert den Einschleusungspunkt im Memory mit 87,5 % Genauigkeit bei null False Positives. Bisherige Forensik-Methoden hatten dort null Treffsicherheit.
Memory-Persistent Information-Flow Control blockiert 97 % der Angriffe an der Session-Grenze. Es verhindert, dass vergiftete Einträge aus einer Session den Kontext einer anderen beeinflussen.
Außerdem gibt es eine strukturelle Grenze für Angreifer — das Retrieval-Coverage Dilemma: Stärkere Evasion, also Techniken die die Erkennung erschweren, schwächt den Angriff selbst. Adaptive Bypass-Strategien haben damit natürliche Obergrenzen.
AM-Sentry — der bisher konkreteste Ansatz
Das AM-Sentry-Framework setzt direkt an den zwei schwachen Punkten an:
| Komponente | Funktion | |---|---| | Memory-Saving Policy | Selektives Speichern — nicht alles darf in den Long-Term-Store | | Memory-Retrieval Screen | Verifikation bei jedem Abruf, bevor Kontext verwendet wird |
Tests zeigen: AM-Sentry reduziert die Erfolgsquote von GhostWriter drastisch, ohne die normale Agenten-Funktionalität wesentlich zu beeinträchtigen. Wie gut es im Produktiveinsatz funktioniert und welche False-Positive-Rate dabei entsteht — dazu gibt es noch keine veröffentlichten Daten.
Was du heute tun kannst
Keine der beschriebenen Verteidigungsmaßnahmen ist fertig für den breiten Produktiveinsatz. Aber Grundregeln gelten jetzt schon:
- Shared Vector Stores minimieren. Wer hat Schreibzugriff auf den Memory Store deines Agenten? Jeder Upload-Kanal ist ein potenzieller Injektionspunkt.
- Memory-Einträge versionieren. Wenn sich das Verhalten deines Agenten verändert, willst du nachvollziehen, was sich im Memory verändert hat — nicht nur, was sich im Code verändert hat.
- Tool-Aufrufe auditieren. Ungewöhnliche Tool-Sequenzen aus Agenten mit persistentem Speicher können Hinweise auf eine aktive Activation Phase sein.
- Getrennte Memory-Scopes. Verschiedene Vertrauensstufen (externe E-Mails vs. interne Docs vs. System-Policies) gehören in getrennte Scopes — kein gemeinsamer Store für alle Quellen.
Die Community diskutiert offene Setups und eigene Pentesting-Experimente in der Zone "Hacking & Security" im Discord.
Was das Material offen lässt
Welche Memory-Architektur ist anfälliger — Vector Store, Knowledge Graph oder typisierte Semantic Memory? Dazu gibt es keinen direkten Vergleich unter Memory-Poisoning-Bedingungen. Wer heute eine Architektur wählt, wählt auf Verdacht.
Wie lange dauert es im Betrieb, bis ein vergifteter Agent auffällt? Auch das steht nirgends. Die Studien messen Erfolgsraten des Angriffs, nicht die Zeit bis zur Entdeckung. Genau die wäre aber die Zahl, die du für eine Risikoabschätzung brauchst.
Und welche kommerziellen Agent-Plattformen haben schon Gegenmaßnahmen eingebaut? Keine veröffentlichten Daten. Wenn dein Anbieter dazu nichts sagt, heißt das nicht, dass nichts da ist — es heißt nur, dass du es nicht prüfen kannst.
Dieser Artikel entstand mit KI-Unterstützung und Quellenabgleich. Alle Zahlen und Befunde stammen aus den verlinkten Quellen.
