Das Vergiften des Speichers von AI-Agenten verwandelt eine einzige nicht vertrauenswürdige Eingabe in einen dauerhaften Zustand. Sobald ein Agent vom Angreifer kontrollierte Inhalte in persistenten Speicher schreibt, können diese Tage oder Sitzungen später als scheinbar vertrauenswürdiger Kontext zurückkehren. Schützen Sie den gesamten Lebenszyklus: Prüfen Sie jeden Schreibvorgang, fügen Sie Herkunft und Ablaufzeit hinzu, isolieren Sie Datensätze nach Benutzer und Agent, prüfen Sie den Abruf erneut, halten Sie die Autorisierung von Aktionen außerhalb des Modells und bewahren Sie ein Einflussprotokoll auf, das Rollbacks unterstützt.
Inhaltsverzeichnis
Was ist das Vergiften des Speichers von AI-Agenten?
Das Vergiften des Speichers von AI-Agenten ist das Einfügen oder Ändern persistenter Datensätze, sodass ein späterer Abruf die Antwort, Entscheidung oder Tool-Nutzung eines Agenten verändert. Die ursprüngliche Eingabe kann verschwunden sein, wenn der Effekt sichtbar wird. Diese zeitliche Lücke macht den Angriff schwerer zu erkennen und nachzuvollziehen als eine sichtbare Prompt Injection in der aktuellen Unterhaltung.
Speicher kann an mehreren Stellen liegen:
Die Speichertechnologie ist nicht das entscheidende Kriterium. Persistenz plus späterer Einfluss bilden die Sicherheitsgrenze.
Dies unterscheidet sich von drei verwandten Risiken. Prompt Injection manipuliert den aktuellen Modellkontext, kann jedoch zum Übertragungskanal für vergifteten Speicher werden. Eine Vergiftung von Trainingsdaten verändert das Modellverhalten über das Trainingskorpus. Retrieval Poisoning zielt auf Inhalte, die für eine Anfrage ausgewählt werden. Das Vergiften des Agentenspeichers speichert einen Datensatz, den das System später möglicherweise als Teil des Verlaufs, der Präferenzen oder des Betriebszustands des Benutzers behandelt.
Drei Angriffsmuster sind in der Praxis relevant:
| Muster | Gespeicherte Form | Aktivierung | Warum ein einfacher Filter Schwierigkeiten hat |
|---|---|---|---|
| --- | --- | --- | --- |
| Direkte Verfälschung | Ein Datensatz enthält die schädliche Anweisung oder eine falsche Tatsache | Der Datensatz wird später abgerufen | Der Inhalt kann als Präferenz, Zusammenfassung oder Aufgabennotiz getarnt sein |
| Kompositionelle Verfälschung | Mehrere Datensätze wirken isoliert betrachtet akzeptabel | Ein gemeinsamer Abruf setzt die schädliche Bedeutung zusammen | Jeder Schreibvorgang wird akzeptiert, weil das Risiko erst in der Kombination sichtbar wird |
| Ruhende Verfälschung | Ein Datensatz enthält eine von einem Auslöser abhängige Anweisung | Ein späteres Ereignis, eine Formulierung oder ein Tool-Zustand aktiviert sie | Der Auslöser fehlt beim Schreiben des Datensatzes |
Microsofts aktuelle Leitlinien beschreiben dieselbe strukturelle Sorge aus defensiver Sicht: Persistenter Speicher enthält sensible Daten und beeinflusst außerdem das Modellverhalten sowie die Tool-Auswahl. Er sollte daher sowohl als Datensystem als auch als Steuerungsebene verwaltet werden. Microsoft Learn
Was drei aktuelle Studien gemessen haben
Drei Preprints vom Juli 2026 untersuchten unterschiedliche Teile dieser Bedrohung. Zusammengenommen zeigen sie, warum ein einzelner Speicherfilter ein schwaches Freigabekriterium ist.
GhostWriter testete die Injektion jetzt und die Aktivierung später
When Agents Remember Too Much führte GhostWriter ein, einen zweistufigen Angriff gegen persönliche Agenten mit Tool-Nutzung. Ein Angreifer platziert zunächst versteckte Inhalte in einer nicht vertrauenswürdigen Quelle. Der Agent verarbeitet diese Quelle und schreibt vom Angreifer beeinflussten Speicher. Eine spätere Aufgabe ruft den Datensatz ab und aktiviert dessen Wirkung.
Über die in der Studie getesteten Agenten und Modelle hinweg erreichte GhostWriter eine durchschnittliche Injektionsrate von etwa 98 % und eine durchschnittliche Aktivierungsrate von etwa 60 %. Die Autoren testeten außerdem AM-Sentry, das eine strengere Richtlinie zum Speichern von Erinnerungen mit einer Abrufprüfung kombiniert. Die Studie bewertet sowohl den Angriffserfolg als auch den Aufgabennutzen in ihrer eigenen simulierten Arbeitswoche; die Ergebnisse der Abwehr variieren je nach Modell und Konfiguration.
Die Grenzen sind wichtig. Die Arbeit umfasst fünf Agenten, vier Modellfamilien sowie E-Mail- und Kalender-Workflows. Der Nutzentest ist individuell entwickelt, die Angreifer sind nicht adaptiv, und die Ergebnisse schätzen nicht, wie häufig bereitgestellte Agenten angegriffen werden.
MemPoison trennte direkte, kompositionelle und ruhende Fehler
MemPoison stellte 1.227 von Hand validierte Fälle über vier Angriffstypen, drei Injektionskanäle und drei Speichersubstrate zusammen. Die Bewertung umfasste sieben Open-Weight- und drei Closed-Weight-Modellfamilien.
Der nützliche Beitrag der Studie ist ihre Taxonomie mit drei Ebenen. L1 ist eine direkte Verfälschung eines einzelnen Datensatzes. L2 wird schädlich, wenn mehrere Datensätze gemeinsam abgerufen werden. L3 bleibt ruhend, bis ein späterer Kontext sie aktiviert. Die Autoren berichten, dass grundlegende Abwehrmaßnahmen zur Schreibzeit direkte Angriffe zuverlässiger unterdrücken als L2- oder L3-Fälle. Ihre mechanistische Einflussanalyse führt die Lücke auf Datensätze zurück, die beim Speichern harmlos wirken, aber durch Komposition oder einen Auslöser schädlich werden.
Das beweist nicht, dass jeder Produktionsfilter zur Schreibzeit versagen wird. Der Benchmark umfasst drei repräsentative Speichersubstrate und standardmäßige textbasierte Kanäle. Die Autoren fordern weitere Forschung zu Verfall, Zusammenfassungen, Zugriffskontrollen und anderen Speicherökosystemen.
MemGhost testete einen einmaligen E-Mail-Zustellungspfad
When Claws Remember but Do Not Tell führte WhisperBench ein, einen Benchmark mit 108 Fällen, der einen echten IMAP/SMTP-Workflow und eine E-Mail-Agenten-Fähigkeit verwendet. Das Angriffssystem MemGhost erzeugt eine einzelne E-Mail-Nutzlast ohne Feedback zur Laufzeit. Erfolg setzt voraus, dass der Agent vergifteten Speicher übernimmt, den Benutzer in seiner unmittelbaren Antwort nicht alarmiert und sein späteres Verhalten verändert.
Für 56 zurückgehaltene Fälle berichtet die Studie einen End-to-End-Erfolg von 87,5 % bei OpenClaw mit GPT-5.4 und 71,4 % beim Claude Code SDK mit Sonnet 4.6.
Diese Zahlen gehören zum Benchmark, zur Proxy-Umgebung, zum Belohnungsdesign und zu den Modellversionen der Autoren. Die Bewertung beginnt, nachdem eine Nachricht den Posteingang erreicht hat. Sie modelliert keine Kontrollen des Mail-Anbieters wie Spamfilter, SPF, DKIM oder DMARC. Die Studie ist ein Preprint der ersten Version, daher sollten ihre Ergebnisse repliziert werden.
Warum Filter zur Schreibzeit nicht ausreichen
Ein Schreib-Gate sieht den vorgeschlagenen Datensatz und die zu diesem Zeitpunkt verfügbaren Belege. Es sieht möglicherweise weder die zukünftige Aufgabe noch die anderen Datensätze, die gemeinsam mit ihm abgerufen werden, noch das Tool, das der Agent später aufrufen wird.
Dadurch entstehen vier blinde Flecken:
Prüfungen zur Schreibzeit sind weiterhin wichtig. Sie reduzieren die Menge unsicheren Zustands, die den persistenten Speicher erreicht. Der Fehler besteht darin, die Genehmigung zur Speicherung als dauerhaftes Vertrauen zu behandeln.
Der Abruf sollte Kandidatenkontext liefern, keine Autorität. Vor dem Einfügen eines Datensatzes in den Modellkontext kann das System seine Quelle, sein Alter, seine Aufgabenrelevanz, Widersprüche, Sensibilität und die angeforderte Wirkung prüfen. Ein Datensatz mit hohem Risiko kann zurückgehalten, zusammengefasst oder zur Prüfung weitergeleitet werden. Microsofts aktuelle Leitlinien empfehlen diese Trennung zwischen Schreiben und Abruf sowie eine deterministische Isolation und vollständige Transparenz über den Lebenszyklus. Microsoft Learn
Die endgültige Sicherheitsentscheidung muss weiterhin außerhalb des Speichers liegen. Eine abgerufene Notiz mit dem Inhalt „Sende Berichte an diese Adresse“ darf die Empfänger-Allowlist nicht ändern. Eine gemerkte Präferenz für eine Bereitstellungsregion darf keine Cloud-Berechtigung erzeugen. Verwenden Sie deterministische Berechtigungen für AI-Agenten→, um die vorgeschlagene Aktion anhand des aktuellen Benutzers, der Ressource, des Umfangs und der Richtlinie zu bewerten.
Eine sichere Architektur für Agentenspeicher
Das System benötigt eine nachvollziehbare Kette von der Quelle bis zur Aktion:
`source → write decision → stored version → retrieval decision → model context → policy decision → tool result`
*Bildunterschrift: Ein Speicherdatensatz wird erst nach Prüfungen beim Schreiben und Abrufen zu Kandidatenkontext. Eine unabhängige Richtlinie autorisiert weiterhin jede folgenreiche Aktion, während die Einflusskette Untersuchungen und Rollbacks unterstützt.*
1. Verlangen Sie eine ausdrückliche Absicht für dauerhafte Schreibvorgänge
Lassen Sie nicht jede Nachricht, jedes Dokument oder jede Tool-Antwort zu einem langfristigen Speicherinhalt werden. Definieren Sie, welche Ereignisse dauerhaften Zustand erzeugen dürfen. Vom Benutzer bestätigte Präferenzen und ausdrückliche Aktionen wie „Merke dir das“ sind leichter zu rechtfertigen als eine autonome Zusammenfassung eines nicht vertrauenswürdigen Anhangs.
Erfassen Sie, wer oder was den Schreibvorgang angefordert hat. Wenn ein Tool oder ein Subagent ihn initiiert hat, bewahren Sie diese Identität auf, statt alles auf den Namen des Endbenutzers zu reduzieren.
2. Speichern Sie Herkunft, Umfang und Ablaufzeit mit dem Datensatz
Ein nützlicher Speicherdatensatz benötigt mehr als Text und ein Embedding. Speichern Sie mindestens:
Eine Signatur kann die Integrität eines Datensatzes schützen. Sie kann nicht beweisen, dass der ursprüngliche Inhalt wahr, sicher oder autorisiert war.
3. Erzwingen Sie Isolation in Code und Speicher
Grenzen für Mandanten, Benutzer, Agenten und Workspaces gehören in Zugriffskontrolllisten, bereichsgebundene Tokens, Richtlinien auf Zeilenebene und Verschlüsselungsgrenzen. Prompt-Anweisungen sind keine Zugriffskontrolle. Gemeinsamer Speicher sollte eine ausdrückliche Produktfunktion mit benannten Schreibern und Lesern sein, kein praktischer Standard-Namespace.
Dasselbe Prinzip gilt für die Ausführungsumgebung. Wenn abgerufene Inhalte Codeausführung oder eine weitreichende Tool-Nutzung auslösen können, kapseln Sie den Prozess mit AI-Agent-Sandbox-Sicherheit→. Speicherisolation begrenzt, welcher Kontext eine Grenze überschreitet. Sandbox- und Identitätskontrollen begrenzen, was geschieht, wenn unsicherer Kontext den Agenten dennoch erreicht.
4. Stellen Sie Schreibvorgänge mit geringem Vertrauen unter Quarantäne
Schaffen Sie einen Zustand zwischen „verworfen“ und „vertrauenswürdiger Speicher“. Externe Dateien, E-Mails, Webseiten, indirekte Tool-Ausgaben und Datensätze mit unklarer Absicht können in die Quarantäne gelangen. Sie sollten nicht im normalen Abruf erscheinen, bis eine deterministische Regel oder ein autorisierter Prüfer sie freigibt.
Die Quarantäne bietet Incident-Response-Teams außerdem einen Ort, an dem sie Beweise bewahren können, ohne den Einfluss fortzusetzen.
5. Bewerten Sie Datensätze zur Abrufzeit erneut
Das Abrufrisiko hängt von der aktuellen Aufgabe ab. Bewerten Sie die ausgewählte Menge und nicht nur jeden einzelnen Datensatz:
Bewerten Sie den Abruf getrennt von der Generierung. Ein RAG-Bewertungsworkflow→ hilft dabei, zwischen „Der falsche Datensatz wurde ausgewählt“ und „Das Modell hat einen korrekten Datensatz missbraucht“ zu unterscheiden. Fügen Sie speicherspezifische Dimensionen wie Herkunft, Auslöserabhängigkeit, Komposition und sitzungsübergreifende Aktivierung hinzu.
6. Halten Sie die Tool-Autorisierung unabhängig
Der Speicher darf Parameter liefern. Er darf niemals Berechtigungen erweitern. Das Tool-Gateway muss die aktuelle Identität, die erlaubte Aktion, die Ressourcengrenze, das Ziel, das Budget und die Genehmigungsanforderungen durchsetzen. Behandeln Sie aus dem Speicher abgeleitete Argumente als nicht vertrauenswürdige Eingaben und validieren Sie sie anhand der aktuellen Richtlinie.
Auch die menschliche Genehmigung benötigt aktuellen Kontext. Zeigen Sie die vorgeschlagene Aktion, die betroffene Ressource, das Datenziel und die Speicherinhalte, die sie beeinflusst haben. Ein „Genehmigen?“ ohne diese Kette verbirgt die relevante Entscheidung.
7. Protokollieren Sie Einfluss und unterstützen Sie Rollbacks
Protokollieren Sie Erstellungs-, Lese-, Änderungs- und Löschvorgänge des Speichers mit Identität und Herkunft. Bewahren Sie für folgenreiche Aktionen die IDs und Versionen der Datensätze auf, die in den Kontext eingefügt wurden. Dadurch lassen sich drei Fragen zu einem Vorfall beantworten:
Das Löschen sollte den aktiven Einfluss entfernen und nicht nur eine Zeile in der Benutzeroberfläche verbergen. Testen Sie Indizes, Zusammenfassungen, Caches, Replikate und abgeleitete Datensätze. Die Agentenleitlinien von OWASP empfehlen validierten und isolierten Speicher sowie adversariale Tests und Nachweise für die Freigabe; die umfassendere Speicheranalyse ordnet persistente Prompt Injection der Bedrohungsfläche von Agentenspeichern zu. OWASP Agent Security Cheat Sheet OWASP GenAI Security Project
Wählen Sie für jede Speicherkategorie eine Richtlinie
Eine einzige Aufbewahrungsrichtlinie ist zu grob. Beginnen Sie mit Kategorien, die unterschiedliche Regeln für Schreiben und Abruf benötigen.
| Speicherkategorie | Standardrichtlinie für das Schreiben | Abrufrichtlinie | Aktionsautorität |
|---|---|---|---|
| --- | --- | --- | --- |
| Flüchtiger Aufgabenkontext | Automatisch, kurze TTL | Nur aktuelle Aufgabe | Keine |
| Vom Benutzer bestätigte Präferenz | Ausdrückliche Bestätigung | Derselbe Benutzer und der deklarierte Zweck | Darf vorschlagen, niemals autorisieren |
| Vom Agenten erstellte Zusammenfassung | Versioniert und mit Quellen verknüpft | Quellen und Aktualität erneut prüfen | Keine |
| Externe Inhalte | Standardmäßig Quarantäne | Erst nach Vertrauens- und Relevanzprüfungen | Keine |
| Betriebliche Anweisung | Autorisierter Schreiber und Richtlinienprüfung | Exakter Umfang, aktuelle Version | Erfordert weiterhin Tool-Richtlinie |
| Geheimnisse oder regulierte Daten | Blockieren oder dedizierte Geheimnis-/Datensysteme verwenden | Niemals in allgemeinen Speicher legen | Nur dedizierte Steuerungsebene |
Diese Tabelle ist eine Ausgangsrichtlinie und keine Compliance-Aussage. Ein medizinischer Agent, ein Coding-Assistent, ein Vertriebsagent und ein persönlicher Assistent haben unterschiedliche Schadensmodelle. Die unveränderliche Grundlage ist enger gefasst: Persistenz darf nicht stillschweigend nicht vertrauenswürdige Inhalte in Berechtigungen umwandeln.
Ein reproduzierbarer Testablauf für Speichervergiftung
Bauen Sie den Test-Harness um harmlose Marker und Wegwerfkonten herum. Sie benötigen keine echten Zugangsdaten oder Exfiltrationsnutzlasten, um Persistenz- und Richtlinienfehler zu erkennen.
Schritt 1: Erfassen Sie eine saubere Baseline
Führen Sie einen festen Aufgabensatz mit leerem Speicher aus. Erfassen Sie Antworten, Abrufergebnisse, Tool-Vorschläge, Richtlinienentscheidungen, Latenz und für Benutzer sichtbare Erklärungen. Wiederholen Sie den Ablauf oft genug, um Systemänderungen von der normalen Modellvarianz zu unterscheiden.
Schritt 2: Definieren Sie gepaarte saubere und vergiftete Fälle
Halten Sie für jeden Fall die Benutzeraufgabe konstant und ändern Sie nur den möglichen Speicherpfad. Decken Sie mindestens Folgendes ab:
Verwenden Sie eine Canary-Aktion wie das Schreiben von `TEST_BLOCKED` in ein Wegwerfprotokoll. Der Test schlägt fehl, wenn der Agent diese Aktion außerhalb des erwarteten Richtlinienpfads ausführt oder vorschlägt.
Schritt 3: Beobachten Sie jede Grenze
Erfassen Sie vier getrennte Ergebnisse:
Ein End-to-End-Erfolg kann eine schwache Schicht verbergen. Beispielsweise kann die Autorisierung die Canary-Aktion blockieren, obwohl ein vergifteter Datensatz gespeichert und wiederholt abgerufen wurde. Das ist eine nützliche Eindämmung, aber der Speicherfehler muss dennoch behoben werden.
Schritt 4: Messen Sie Nutzen und Fehlalarme
Führen Sie harmlose Speicherfälle durch dieselbe Pipeline. Verfolgen Sie Aufgabenerledigung, akzeptierte Benutzerpräferenzen, fälschlich unter Quarantäne gestellte Inhalte, Abrufpräzision, Latenz und Prüfaufwand. Ein Filter, der allen dauerhaften Speicher blockiert, hat eine geringe Angriffserfolgsrate, weil er die Funktion entfernt hat.
Schritt 5: Legen Sie risikobasierte Freigabegates fest
Nützliche Gates umfassen:
Das Open-Source-Agent Memory Guard-Projekt von OWASP ist ein Implementierungssignal für Speicher-Scanning und Testwerkzeuge. Sein Repository und die selbst gemeldete Bewertung können Teams dabei helfen, Muster zu untersuchen, ersetzen jedoch nicht das Testen des tatsächlichen Agenten, Modells, Speicher-Backends und Richtlinien-Stacks.
Führen Sie die Testsuite erneut aus, nachdem Sie Änderungen an Speicherextraktion, Zusammenfassung, Embeddings, Abruf, Prompts, Modellen, Tool-Schemas, Autorisierung oder Löschlogik vorgenommen haben. Diese Schichten wirken zusammen.
Was die Belege unterstützen und was nicht
Die Studien haben den Angriffserfolg innerhalb konstruierter Benchmarks gemessen. Sie haben nicht die bevölkerungsweite Rate des Vergiftens von AI-Agentenspeichern in der Produktion gemessen.
Sie stützen drei engere Schlussfolgerungen:
Die Studien leiten daraus ab, dass die Speicherverwaltung kontextabhängige Abwehrmaßnahmen benötigt. Microsoft und OWASP empfehlen unabhängig voneinander Defense in Depth über Schreibvorgänge, Isolation, Abruf, Benutzerkontrolle, Beobachtbarkeit und Tests hinweg.
Die praktische Interpretation besteht darin, jeden Übergang testbar zu machen. Ein Team sollte erklären können, warum ein Datensatz gespeichert wurde, warum er abgerufen wurde, wie er eine Aktion beeinflusst hat, welche Richtlinie diese Aktion autorisiert hat und wie sich die nachgelagerten Auswirkungen des Datensatzes entfernen lassen.
Fragen von Teams
Ist das Vergiften des Speichers von AI-Agenten dasselbe wie Prompt Injection?
Nein. Prompt Injection ist eine Möglichkeit, feindselige Anweisungen einzuführen. Speichervergiftung fügt Persistenz hinzu: Manipulierte Inhalte werden gespeichert, in einem späteren Kontext abgerufen und können zukünftiges Schlussfolgern oder die Tool-Nutzung beeinflussen, nachdem die ursprüngliche Eingabe verschwunden ist.
Können signierte Speicherdatensätze Vergiftung verhindern?
Nein. Signaturen können beweisen, dass ein Datensatz nach seiner Erstellung nicht verändert wurde. Sie beweisen nicht, dass der ursprüngliche Inhalt wahr, sicher oder autorisiert war. Ein sicheres Design benötigt außerdem Herkunft, ausdrückliche Schreibabsicht, Umfang, Ablaufzeit, Abrufprüfungen und unabhängige Aktionsautorisierung.
Sollten Schutzmaßnahmen gegen Speichervergiftung zur Schreibzeit oder zur Abrufzeit ausgeführt werden?
Beides. Schreib-Gates reduzieren unsichere Persistenz. Abrufprüfungen erkennen veraltete, widersprüchliche, kompositionelle oder auslöserabhängige Risiken, die beim Speichern einzelner Datensätze nicht sichtbar waren. Keine der beiden Schichten darf Tool-Autorität verleihen.
Prüfung von Aussagen
| Aussage | Prüfung | Status |
|---|---|---|
| --- | --- | --- |
| GhostWriter erreichte in seinen Experimenten eine durchschnittliche Injektion von etwa 98 % und eine durchschnittliche Aktivierung von etwa 60 % | Von der Studie über die getesteten Setups persönlicher Agenten berichtet; keine Schätzung der Produktionsprävalenz | Verifiziert, eingegrenzt |
| MemPoison enthält 1.227 von Hand validierte Fälle über vier Angriffstypen, drei Injektionskanäle und drei Speichersubstrate | In Abstract und Evaluationsbeschreibung der Studie angegeben | Verifiziert |
| Grundlegende Abwehrmaßnahmen zur Schreibzeit lassen strukturelle blinde Flecken für kompositionelle und ruhende Angriffe offen | Die MemPoison-Autoren berichten von verbleibendem Einfluss bei L2- und L3-Fällen | Verifiziert, eingegrenzt |
| MemGhost berichtete einen End-to-End-Erfolg von 87,5 % und 71,4 % bei zwei zurückgehaltenen Konfigurationen | Für 56 zurückgehaltene Fälle unter dem Testaufbau der Studie berichtet | Verifiziert, eingegrenzt |
| MemGhost hat Spam- und Authentifizierungskontrollen des Mail-Anbieters nicht gemessen | Die Bewertung beginnt nach der Zustellung in den Posteingang und modelliert diese Kontrollen nicht | Verifiziert |
| Microsoft empfiehlt, Speicher als Daten und als Steuerungsebene zu behandeln | In den aktuellen Microsoft-Learn-Leitlinien angegeben | Verifiziert |
| Eine gültige Signatur macht Speicher nicht vertrauenswürdig | Integrität nach der Erstellung belegt weder sichere Herkunft noch Wahrheit, Absicht oder Autorität | Verifiziert |
| Aktivität in einem Repository beweist nicht, dass ein Speicher-Framework sicher ist | Sterne, Commits und Releases messen Aufmerksamkeit und Wartung, nicht die Sicherheitseffektivität | Verifiziert |