Memory Poisoning verhindern: Langzeit- und Vektor-Memory von KI-Agenten absichern

Memory Poisoning bezeichnet das gezielte Einschleusen manipulierter Inhalte in das Langzeit- oder Vektor-Memory eines KI-Agenten. Anders als bei einer einmaligen Prompt-Injection, die nur innerhalb einer Antwort wirkt, bleibt der Schadinhalt persistent gespeichert. Bei jedem späteren Abruf kompromittiert er das Verhalten des Agenten. In der OWASP Top 10 for Agentic Applications 2026 ist diese Bedrohung als ASI06 (Memory & Context Poisoning) gelistet.

Der entscheidende Unterschied zu reinen Chatbots: Während diese zwischen Sessions vergessen, unterhalten agentische Systeme ein persistentes Gedächtnis: Konversationshistorie, Nutzerpräferenzen, gelernten Kontext und RAG-Stores. Genau das schafft eine dauerhafte Angriffsfläche. Der Angreifer injiziert einmal, der Payload läuft unbegrenzt weiter, und jede künftige Session erbt die Kompromittierung.

• Persistenz ist das Kernrisiko: Ein einziger erfolgreicher Schreibvorgang kann das Memory dauerhaft vergiften, die Manipulation überdauert Wochen normalen Betriebs.
• Abruf statt Eingabe ist der kritische Moment: Der Schaden entsteht nicht beim Schreiben, sondern wenn der vergiftete Eintrag später abgerufen und als vertrauenswürdiger Kontext behandelt wird.
• Validierung beim Schreiben plus Provenance plus Memory-Audits sind die drei tragenden Säulen der Abwehr, keine einzelne Maßnahme genügt.

Angriffsvektoren: Wie Inhalte ins Memory gelangen

Memory Poisoning nutzt mehrere, teils kombinierbare Einfallstore. Der Agent kann nicht zuverlässig zwischen Instruktion und Daten unterscheiden, jeder Text, den er liest und speichert, ist Teil der Angriffsfläche.

• Direkte Memory-Injection: Der Agent speichert feindlichen Inhalt mit hoher Konfidenz als gelerntes Faktum ab.
• RAG-Store-Poisoning: Manipulierter Inhalt wird in die referenzierte Wissensdatenbank eingebracht.
• Embedding-Manipulation: Adversariale Eingaben im Embedding-Raum verschieben die semantische Repräsentation.
• Delayed Tool Invocation: Triggerphrasen aktivieren den Payload erst Wochen später, ein Schläfer im Gedächtnis.
• Vector-Store-Insertion: Angriffe gegen mandantenübergreifend geteilte Embeddings tragen die Vergiftung über Tenant-Grenzen hinweg.

Persistenz-Risiko: warum das Gedächtnis gefährlicher ist als die Eingabe

Das Tückische am Memory Poisoning ist die zeitliche Entkopplung von Angriff und Wirkung. Ein vergiftetes Memory führt zu Behavioral Drift, der ohne Code- oder Modelländerung auftritt, und damit klassischen Change-Management-Kontrollen entgeht. Wie zuverlässig vergiftete Einträge wirken, die erst später greifen, zeigt der Preprint Hidden in Memory: Sleeper Memory Poisoning in LLM Agents vom Mai 2026: Präparierte Dokumente, Webseiten oder Repositories brachten LLM-Assistenten dazu, erfundene Erinnerungen über den Nutzer zu speichern. Wurden diese Einträge später abgerufen, lösten sie je nach Modell in 60 bis 89 Prozent der Auswertungen die vom Angreifer beabsichtigte Agenten-Aktion aus.

Für DACH-B2B-Szenarien sind drei Muster besonders relevant:

• Versicherer mit Schadens-Triage-Agent: Der Agent lernt aus einem einzigen vergifteten Beispiel, dass „Versicherungsnehmer aus Postleitzahl X bevorzugt freigegeben werden". Diese Sleeper-Verzerrung überlebt wochenlangen Normalbetrieb.
• KRITIS-Betreiber mit Predictive-Maintenance-Agent: Aus vergifteter Telemetrie lernt der Agent, dass ein Schwingungs-Schwellwert „normal" sei, ein Schläfer, der zu einem Ausfall beitragen kann.
• Bank-Compliance-Agent: Das Verständnis von „verdächtiger Aktivität" verschiebt sich graduell durch langlaufendes Poisoning des Session-Memory.

Gegenmaßnahmen: vier Verteidigungsebenen

Wirksame Abwehr von Memory Poisoning folgt dem Defense-in-Depth-Prinzip über Design, Build, Runtime und Betrieb. Keine einzelne Schicht genügt, die Kombination zählt.

Validierung und Provenance als Kern

Der wirksamste Hebel liegt im Schreibvorgang selbst. Jeder Memory-Eintrag sollte Provenance-Metadaten tragen: Quelle, Zeitstempel, Ingestion-Pfad und Konfidenzwert. Beim Abruf gewichtet ein Source-Confidence-Score Einträge nach Vertrauenswürdigkeit. Einträge, die sich keiner verifizierbaren Quelle zuordnen lassen, dürfen nicht als gesichertes Wissen behandelt werden. Inhalte sollten vor dem Embedding validiert und nach Trust-Tier getaggt werden, etwa „intern verifiziert", „extern unbestätigt", „nutzergeneriert".

Trennung vertrauenswürdiger Quellen und Mandanten-Isolation

Vektor-Stores brauchen Access-Controls auf Row- oder Namespace-Ebene. Embedding-Stores dürfen niemals über Mandantengrenzen hinweg geteilt werden, jeder Tenant erhält einen separaten Vektor-Index. Memory wird at rest verschlüsselt, idealerweise mit kundenverwalteten Schlüsseln. Gegen Embedding-Inversion helfen Frequenzlimitierung von Queries, Differential Privacy auf Embeddings und Anomalieerkennung im Embedding-Raum.

Memory-Audits und Detection-Signale

Memory-Audits prüfen Inhalte stichprobenartig und verifizieren deren Provenance. Folgende Signale deuten auf Poisoning hin:

• Drift im Baseline-Verhalten des Agenten ohne Code- oder Modelländerung.
• Nicht verifizierbare Memory-Einträge ohne Provenance-Record.
• Semantische Ausreißer im Vector-Store.
• Der Agent behauptet, sich an Instruktionen zu „erinnern", für die kein Provenance-Record existiert.

Vollständiges Audit-Logging je Agenten-Aktion (Stand 2026) sollte mindestens Memory-Write- und Read-Events, Retrieval-Queries mit zurückgegebenen Dokument-IDs sowie die Entscheidungsbegründung umfassen, idealerweise als WORM-Logs (write-once-read-many) mit kryptografischer Signierung zur Manipulationserkennung.

Konkretes Beispiel: Delayed Tool Invocation

Die Google Gemini Memory Attack (Februar 2025, dokumentiert von Johann Rehberger) zeigt den Mechanismus exemplarisch. Ein hochgeladenes Dokument enthielt versteckte Prompts, die Gemini anwiesen, Falschinformationen erst dann zu speichern, wenn in einer künftigen Konversation Triggerwörter wie „yes", „no" oder „sure" auftauchten. Das Ergebnis: Gemini „erinnerte" sich an den Forscher als 102-jährigen Flacherdler. Google stufte das Risiko als missbrauchsbezogen mit geringer Wahrscheinlichkeit und geringer Auswirkung ein.

In Pseudocode lässt sich der Angriff so skizzieren:

```

Phase 1. Injection (einmalig, über manipuliertes Dokument)

WENN nutzer_eingabe ENTHAELT trigger_wort ("yes" | "no" | "sure"):
memory.schreibe(eintrag="Nutzer ist 102 Jahre alt", konfidenz=hoch)
# kein Provenance-Record, keine Validierung beim Schreiben

Phase 2. Aktivierung (Wochen später, beliebige Session)

beim abruf: memory.lies("Nutzer-Profil")
-> liefert vergifteten Eintrag als gesichertes Faktum zurück
```

Eine Abwehr mit Validierung beim Schreiben hätte den Eintrag in Phase 1 abgelehnt: kein nachvollziehbarer Provenance-Record, externe und nicht verifizierte Quelle, niedriges Trust-Tier. Beim Abruf in Phase 2 hätte das Source-Confidence-Weighting den Eintrag herabgestuft. Beim Calendar Invite Poisoning (Targeted Promptware Attacks, 2025) implantierten manipulierte Kalendereinladungen persistente Instruktionen in Geminis „Saved Info". 73 Prozent der analysierten Bedrohungen stuften die Autoren als High bis Critical ein (Nassi et al. 2025). Die 14 Szenarien reichen von Spam bis zur Steuerung von Smart-Home-Geräten.

Compliance-Verankerung in Deutschland und Österreich

Memory Poisoning ist ein technisches und ein regulatorisches Thema. Inhaltlich entspricht ASI06 der MITRE-ATLAS-Technik AML.T0080 (AI Agent Context Poisoning), Memory Poisoning im Besonderen der Untertechnik AML.T0080.000 (Memory). Beide kamen mit der Zenity-Kollaboration vom Oktober 2025 hinzu. Eng verwandt ist die bereits zuvor bestehende Technik AML.T0020 (Poison Training Data), die als trainingsseitiges Pendant ASI06 vorgelagert ist. Das OWASP-Dokument zur Top 10 for Agentic Applications selbst ordnet ASI06 der Bedrohung T1 Memory Poisoning aus dem OWASP-Leitfaden Agentic AI Threats and Mitigations zu. Für Deployer in Deutschland und Österreich sind folgende Anker relevant (Stand 2026):

• DSGVO: Art. 5(1)(d) (Richtigkeit), Art. 17 (Recht auf Löschung), Art. 32 (technisch-organisatorische Maßnahmen).
• EU AI Act: Art. 10 (Daten-Governance) und Art. 15 (Cybersicherheit), beide nur für Hochrisiko-KI-Systeme. Embedding-Inversion-Angriffe sind in den Standards noch nicht eigens kodifiziert, die Lücke schließt der Deployer.
• ISO/IEC 42001: A.7 (Daten für KI-Systeme), A.7.4 (Datenqualität), A.6.2.8 (Logging).

Memory-Löschverfahren müssen mit DSGVO Art. 17 abgestimmt sein. Das Recht auf Löschung gilt für personenbezogene Daten unabhängig vom Speicherort und damit auch für persistente Agenten-Speicher und Embedding-Stores, soweit sie personenbezogene Daten enthalten.

Für Agenturen und B2B-Entscheider

Wer agentische KI für Kunden oder im eigenen Betrieb einsetzt, sollte Memory-Sicherheit nicht als nachgelagertes Detail behandeln. Kläre vor jedem Rollout drei Fragen: Welche Quellen dürfen überhaupt in das persistente Memory schreiben? Trägt jeder Eintrag Provenance-Metadaten? Sind Mandanten-Indizes sauber getrennt? Für Marketing- und Digitalagenturen, die agentische Systeme für mehrere Kunden betreiben, ist die mandantenübergreifende Vektor-Store-Isolation der wichtigste Einzelhebel, eine Cross-Tenant-Kontamination des Memory ist ein Vertrauens- und Haftungsrisiko zugleich. Blck Alpaca unterstützt Unternehmen in Deutschland und Österreich dabei, Memory-Validierung, Provenance-Konzepte und regelmäßige Memory-Audits entlang von OWASP ASI06, EU AI Act und DSGVO aufzusetzen, pragmatisch und auditfest.