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. Lakera AI dokumentierte im November 2025 sogenanntes Sleeper-Agent-Verhalten: Kompromittierte Agenten entwickelten persistente Falschüberzeugungen über Sicherheitsrichtlinien und Lieferantenbeziehungen und verteidigten diese sogar, als Menschen sie infrage stellten.

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, der in der Matrix lebt. Google bewertete die Auswirkung als gering, bestätigte aber die Schwachstelle.

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 von 14 getesteten Szenarien wurden als High bis Critical eingestuft, von Spam bis zum Öffnen von Smart-Home-Geräten.

Compliance-Verankerung im DACH-Raum

Memory Poisoning ist nicht nur ein technisches, sondern auch ein regulatorisches Thema. ASI06 ist der MITRE-ATLAS-Technik AML.T0085 (Memory Poisoning) zugeordnet, die im Rahmen der Zenity-Kollaboration vom Oktober 2025 hinzukam. Eng verwandt ist die bereits zuvor bestehende Technik AML.T0020 (Poison Training Data), die als trainingsseitiges Pendant ASI06 vorgelagert ist. Für deutschsprachige Deployer 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). 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 Vergessenwerden erstreckt sich ausdrücklich auch auf persistente Agenten-Speicher und Embedding-Stores.

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ären Sie 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 DACH-Unternehmen dabei, Memory-Validierung, Provenance-Konzepte und regelmäßige Memory-Audits entlang von OWASP ASI06, EU AI Act und DSGVO aufzusetzen – pragmatisch und auditfest.