Memory & Context Poisoning

Angriffsklasse, bei der persistenter Agent-Speicher (Memory, RAG-Vektorstores, geteilter Kontext) so manipuliert wird, dass zukünftige Sessions die kompromittierte Information als legitime Grundlage verwenden. Anders als Prompt Injection, die auf eine einzelne Session zielt, persistiert Memory Poisoning den Angriff – eine einmal eingeschleuste Manipulation kann Wochen oder Monate lang in jeder neuen Session wirken.

OWASP-Kategorie unter den agentenspezifischen Threats. Im Zero-Trust-Whitepaper von Anthropic (Mai 2026) als eine der drei zentralen Risikoflächen autonomer Systeme bezeichnet.

Was das für deinen Betrieb heißt

Für DACH-KMU sind drei Szenarien praktisch relevant:

1. RAG-Vault mit gemischten Quellen: Marketing-Vault, der Wettbewerber-Webseiten regelmäßig indexiert. Eine manipulierte Wettbewerber-Seite kann Inhalte einschleusen, die spätere Recherche-Ausgaben verfälschen. Mitigation: Quell-Whitelist, separater Index-Bereich für externe Quellen, kein automatisches Retrieval ohne Source-Tag.
2. Multi-Mandanten-Chatbot: Ein KMU bietet KI-Service für mehrere Kunden. Mandant A injiziert über normale Anfragen Inhalte, die Mandant Bs Antworten beeinflussen. Mitigation: harte Tenant-Trennung in der Vektordatenbank, keine globalen Memory-Stores.
3. Long-running Assistant mit Memory.md: Ein persönlicher Claude-Code-Setup, der Memory automatisch fortschreibt. Drift über Wochen durch routinemäßiges Auto-Summarize macht das System nach Monaten unzuverlässig. Mitigation: Memory-Review-Kadenz (z. B. wöchentlicher Read-only-Audit der MEMORY.md), TTLs auf nicht-Identity-Schichten, manuelle Promotion statt Auto-Decay (→ Agentisches Memory-Design).

Drei Sofort-Maßnahmen:

• Source-Tags auf jeden Memory- und RAG-Eintrag (woher, wann, wer hat autorisiert)
• TTLs für externe Inputs deutlich kürzer als für interne Knowledge
• Quarantäne-Verfahren für verdächtige Inhalte mit Forensik vor Löschung – nicht reflexartig purgen, wenn ein Audit-Trail nötig ist