Das Gedächtnis der Agenten: Memory-Architekturen, Memory Poisoning und die Löschpflicht

Zwei Jahre lang lautete die Standardantwort auf jede Schwäche eines KI-Agenten: besseres Modell. 2026 stimmt das nicht mehr. Wer heute einen Agenten über Wochen im Betrieb hat – im Servicedesk, in der Angebotsprüfung, in der Instandhaltung –, stellt fest, dass die Fehler selten aus mangelnder Sprachfähigkeit stammen. Sie stammen daraus, was der Agent aus früheren Vorgängen behalten hat, was er davon wiederfindet und was er beim Wiederfinden für gesichert hält.

Damit rückt eine Komponente ins Zentrum, die in den meisten Architekturdiagrammen als kleiner Kasten am Rand steht: der Speicher. Er ist zugleich das größte ungelöste Datenschutzproblem agentischer Systeme, weil er personenbezogene Daten dauerhaft festhält – und zwar in abgeleiteter, umformulierter, über mehrere Ablagen verstreuter Form.

Warum Gedächtnis der neue Engpass ist

Am 9. Dezember 2025 hat das OWASP GenAI Security Project die Top 10 for Agentic Applications 2026 veröffentlicht. Bemerkenswert ist nicht nur, dass Gedächtnis darin vorkommt, sondern dass es eine eigenständige Kategorie bekommen hat: ASI06 – Memory & Context Poisoning. Die Liste umfasst ASI01 Agent Goal Hijack, ASI02 Tool Misuse & Exploitation, ASI03 Identity & Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution (RCE), ASI06 Memory & Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation und ASI10 Rogue Agents.

OWASP grenzt ASI06 ausdrücklich von ASI01 ab, und diese Abgrenzung ist der Kern des Themas: Beim Goal Hijack werden Ziele und Instruktionen direkt manipuliert – der Angriff ist laut und findet im Moment statt. Bei ASI06 wird gespeicherter Kontext korrumpiert. Charakteristisch ist die verzögerte Auslösung: Das kompromittierte Verhalten zeigt sich erst in späteren, thematisch völlig unabhängigen Sitzungen, ohne erkennbaren Auslöser. Wer nur den aktuellen Vorgang untersucht, findet nichts.

Praktisch bedeutet das eine Umkehr der Prioritäten. Ein Agent, der einen mehrstufigen Vorgang bearbeitet, erzeugt Hunderte Speicherereignisse – Zwischenergebnisse, Tool-Ausgaben, Nutzerkorrekturen, verdichtete Zusammenfassungen. Die Qualität eines Langläufers entscheidet sich an vier Operationen: Enkodierung (was wird überhaupt geschrieben), Retention (wie lange bleibt es), Retrieval (was wird wiedergefunden) und Konsolidierung (was wird zu einem dauerhaften „Fakt" verdichtet). An keiner dieser vier Stellen hilft ein Modellwechsel. Sie sind Architektur, nicht Intelligenz.

Wie wenig kontrolliert diese Schicht im Feld ist, zeigt eine Erhebung der Cloud Security Alliance, veröffentlicht am 21. April 2026 (Befragung Januar 2026, 418 IT- und Security-Fachleute, beauftragt von Token Security): 82 Prozent der Unternehmen haben unbekannte KI-Agenten in ihrer Umgebung, 65 Prozent hatten in den zurückliegenden zwölf Monaten agentenbezogene Vorfälle – davon 61 Prozent Datenabfluss, 43 Prozent Betriebsstörungen und 35 Prozent finanzielle Verluste.

Die Speicherarten und was tatsächlich persistiert

OWASP unterscheidet für ASI06 drei Angriffsflächen: den Session-Kontext, die Retrieval-Indizes und die persistenten Memory-Stores. Diese Dreiteilung ist die belastbare Struktur – sie beschreibt, wo Inhalte liegen. In der Implementierungspraxis hat sich darüber hinaus eine kognitiv motivierte Vierteilung eingebürgert, die beschreibt, welche Art von Inhalt liegt: Working, Episodic, Semantic und Procedural Memory.

Working Memory ist nur das Kontextfenster

Working Memory ist das aktive Kontextfenster des Modells – alles, was im aktuellen Aufruf mitgegeben wird. Es ist flüchtig und endet mit dem Request. Genau deshalb ist es der am wenigsten interessante Teil des Problems, obwohl die meisten Sicherheitsdiskussionen dort stehenbleiben.

Episodic Memory: das Protokoll der Vorgänge

Episodic Memory hält, was passiert ist: Session-Logs, Entscheidungsprotokolle, Tool-Aufrufe mit Parametern, Nutzerkorrekturen. Hier landen im Klartext Namen, Vorgangs- und Fallnummern, Vertragsdetails, Krankmeldungen, Bewerberdaten – alles, was im Dialog vorkam. Datenschutzrechtlich ist das die heikelste Schicht, weil sie am wenigsten abstrahiert.

Semantic Memory: verfestigte Aussagen

Semantic Memory speichert nicht Ereignisse, sondern daraus destillierte Behauptungen: „Kunde X akzeptiert keine Vorkasse", „Lieferant Y liefert regelmäßig verspätet", „Mitarbeiterin Z ist für Freigaben über 10.000 Euro zuständig". Diese Einträge liegen typischerweise als Embeddings in einer Vektordatenbank oder als Knoten in einem Graphen. Sie sind der eigentliche Hebel eines Angreifers – und der eigentliche Stolperstein bei einem Löschersuchen, weil ein Embedding nicht wie ein Datenbankfeld aussieht, aber personenbezogen ist.

Procedural Memory: gelernte Abläufe

Procedural Memory hält Routinen: welches Werkzeug in welcher Situation, in welcher Reihenfolge, mit welchen Vorbedingungen. Personenbezug ist hier meist gering, das Sicherheitsrisiko dafür hoch – eine manipulierte Routine verändert dauerhaft das Handeln des Agenten.

Speicherart	Typische Ablage	Lebensdauer	DSGVO-Relevanz
Working Memory	Kontextfenster des Modells	1 Request	gering – nichts bleibt liegen
Session-Kontext	Cache, Session-Store	TTL 24 h (OWASP-Referenz)	mittel – kurze, aber echte Speicherung
Episodic Memory	Rohprotokoll, Objektspeicher	Monate bis unbegrenzt	hoch – Klartext mit Personenbezug
Semantic Memory	Vektorindex, Wissensgraph	unbegrenzt, bis überschrieben	sehr hoch – abgeleitet, schwer auffindbar
Procedural Memory	Policy-/Skill-Store	unbegrenzt	gering – dafür hohes Wirkungsrisiko

Der praktische Kern dieser Tabelle: Eine Löschung, die nur die erste Zeile eines Chatverlaufs entfernt, hat drei Ablagen übersehen. Und die schwierigste davon – der Vektorindex – enthält keine Klartextsuche, über die man den Betroffenen einfach finden könnte.

Memory Poisoning: warum eine Injection dauerhaft bleibt

Eine klassische Prompt Injection hat einen begrenzten Wirkungsradius: Sie wirkt in der laufenden Sitzung und ist mit deren Ende erledigt. Memory Poisoning verschiebt genau diese Grenze. Der manipulierte Inhalt wird geschrieben – und wirkt danach in jedem Retrieval, jeder Sitzung, potenziell für jeden Nutzer desselben Agenten.

MINJA: der Angriff braucht keinen Schreibzugriff

Die deutlichste akademische Demonstration ist MINJA (Memory INJection Attack, arXiv 2503.03704, eingereicht am 5. März 2025, als Poster auf der NeurIPS 2025). In den Laborexperimenten erreicht der Angriff eine Injection Success Rate von über 95 Prozent, im Mittel 98,2 Prozent, bei einer durchschnittlichen Attack Success Rate von 76,8 Prozent. Wichtig für die Einordnung: getestet wurde nicht gegen produktive Unternehmenssysteme, sondern gegen Forschungsprototypen – EHRAgent auf den klinischen Datensätzen MIMIC-III und eICU, RAP auf WebShop sowie ein QA-Agent auf MMLU, jeweils mit GPT-4 beziehungsweise GPT-4o. Die Spannweite der Attack Success Rate ist entsprechend groß: 90,0 Prozent auf eICU, aber nur 57,0 Prozent auf MIMIC-III.

Der eigentlich beunruhigende Befund steckt nicht in den Prozentzahlen, sondern im Angreifermodell: MINJA benötigt keinerlei Schreibzugriff auf die Memory-Datenbank. Die Vergiftung läuft ausschließlich über normale Nutzeranfragen und die beobachteten Ausgaben – „query-only". Der Angreifer arbeitet mit Bridging-Steps, die eine gedankliche Brücke zwischen harmlosem Ausgangsbegriff und Zielverhalten aufbauen, einem Indication-Prompt, der den Agenten zum Abspeichern bewegt, und einer Progressive-Shortening-Strategie, die den verräterischen Prompt-Anteil schrittweise wieder entfernt. Übrig bleibt ein unauffälliger Eintrag.

AI Recommendation Poisoning: der Fall aus dem Feld

Am 10. Februar 2026 hat Microsoft Security ein reales Muster dokumentiert und „AI Recommendation Poisoning" genannt. Der Mechanismus: Webseiten betten versteckte Anweisungen in „Ask AI"- beziehungsweise „Summarize with AI"-Buttons ein. Ein Klick öffnet den eingeloggten Assistenten des Nutzers – ChatGPT, Claude, Gemini oder Grok – und führt dort einen vorbefüllten Prompt aus, der die Anbieterdomain als vertrauenswürdige Quelle in den Langzeitspeicher schreibt. Microsoft zählte 31 Unternehmen aus 14 Branchen und über 50 unterschiedliche Prompt-Varianten in einer einzigen Datenquelle innerhalb von 60 Tagen. Betroffene Branchen: Finanzen, Gesundheit, Recht, SaaS, Marketing, Rezepte/Food und Business Services.

Zur Redlichkeit gehört die Abgrenzung: Belegt ist damit Marketing- und Anbieter-Manipulation gegenüber Endnutzer-Assistenten – verzerrte künftige Empfehlungen zu Gesundheit, Finanzen und Sicherheit über alle Folgesitzungen hinweg, bis der Eintrag manuell gelöscht wird. Nicht belegt ist die Verfälschung operativer Unternehmensentscheidungen im großen Maßstab; dass derselbe Mechanismus auf einen Firmenagenten mit Einkaufs- oder Lieferantenbewertung übertragbar wäre, ist eine plausible Ableitung, keine dokumentierte Beobachtung. Der belegte Kernpunkt reicht aber völlig: Die klassische Injection endet mit der Sitzung, dieser Eintrag überlebt sie.

MITRE führt die Technik als AML.T0080 (Memory Poisoning) in ATLAS, verwandt mit AML.T0051 (LLM Prompt Injection). Microsofts Gegenmaßnahmen sind entsprechend nüchtern: Prompt-Filterung, Content-Separation, Memory-Sichtbarkeit für Nutzer und laufendes Monitoring auf Injection-Muster – nutzerseitig ergänzt um die schlichte Empfehlung, gespeicherte Memories in den Assistenteneinstellungen regelmäßig zu prüfen und verdächtige Einträge zu löschen.

Provenienz-Verlust als eigene Fehlerklasse

Beide Fälle haben denselben strukturellen Defekt zur Voraussetzung: Ein Inhalt wird gespeichert, ohne dass festgehalten wird, woher er stammt. Beim Wiederfinden ist eine vom Angreifer eingeschleuste Behauptung dann nicht mehr von einer verifizierten Fachaussage zu unterscheiden. Das ist keine Modellschwäche und lässt sich auch nicht durch Guardrails auf der Ausgabeseite reparieren – es ist eine fehlende Metadatenspalte. Verwandt, aber nicht identisch ist das Problem der Memorization im Modell selbst: Dort steckt das Datum in den Gewichten, hier in einer Datenbank, die Sie kontrollieren können. Das ist die gute Nachricht.

Fünf Kontrollen für die Memory-Schicht

Das OWASP AI Agent Security Cheat Sheet nennt genau fünf Kontrollen für die Speicherschicht. Sie sind kurz, unspektakulär und in der Praxis fast nie vollständig umgesetzt:

1. Daten vor dem Speichern validieren und sanitisieren. Die Prüfung gehört auf den Schreibpfad, nicht auf den Lesepfad. Wer erst beim Retrieval filtert, hat den vergifteten Eintrag bereits in der Datenbank – und filtert bei jedem Zugriff erneut gegen dieselbe Signatur.
2. Memory-Isolation zwischen Nutzern und Sitzungen. Kein Eintrag darf ohne ausdrückliche Freigabe die Grenze zwischen zwei Nutzern überschreiten. Genau diese Grenze ist es, die MINJA in geteilten Agenten überwindet.
3. Ablauf- und Größenlimits setzen. Die Beispielimplementierung des Cheat Sheets arbeitet mit MEMORY_TTL_HOURS = 24; ältere Einträge werden beim Retrieval schlicht verworfen. Ein vergifteter Eintrag mit Ablaufdatum ist ein zeitlich begrenzter Vorfall statt eines Dauerzustands.
4. Speicherinhalte vor der Persistierung auf sensible Daten prüfen. Erkennung von Personendaten, Zugangsdaten und Gesundheitsangaben, bevor geschrieben wird – das ist zugleich die wirksamste Datenminimierung, die in dieser Architektur überhaupt möglich ist.
5. Kryptografische Integritätsprüfungen für Langzeitspeicher. Das Cheat Sheet zeigt _compute_checksum() und _verify_checksum() auf SHA-256-Basis, die jeden Memory-Eintrag an eine user_id binden. Jeder Eintrag trägt damit mindestens user_id und Zeitstempel – das Provenance-Minimum.

Der wirtschaftlich attraktivste Punkt dieser Liste ist Nummer 3. Ein aggressives TTL kostet nichts, senkt die Indexgröße, verkürzt die Wirkdauer jedes erfolgreichen Angriffs und reduziert nebenbei den Umfang dessen, worüber Sie im Ernstfall Auskunft geben müssen.

Verteidigungsarchitektur: Partitionierung, Provenance, TTL

Aus den ASI06-Mitigationen und den fünf Kontrollen lässt sich eine Architektur mit fünf Ebenen ableiten, die zusammen verhindern, dass ein einzelner vergifteter Eintrag dauerhaft wirkt:

Ebene 1 – Partitionierung und Kontext-Isolation

Memory-Scoping pro Nutzer und pro Aufgabe. Ein Agent, der Bewerbungen sichtet, und derselbe Agent, der Lieferantenanfragen beantwortet, teilen sich keinen Speicherraum. OWASP empfiehlt darüber hinaus ephemeren Kontext als Standardeinstellung: Persistenz ist die begründungspflichtige Ausnahme, nicht die Voreinstellung.

Ebene 2 – Provenance-Tracking je Eintrag

Jeder gespeicherte Fakt bekommt Metadaten mit Herkunft und Zeitstempel: Welcher Nutzer, welche Sitzung, welches Tool, welche Quelle, welche Vertrauensstufe. Ohne diese Spalten ist weder Forensik noch Löschnachweis möglich – und zwar in genau dieser Reihenfolge, denn wer nicht weiß, welche Einträge betroffen sind, kann auch nicht gezielt zurückrollen.

Ebene 3 – Getrennte Vertrauensstufen

Kurzzeit-Session-Memory und Langzeitspeicher werden strikt getrennt und mit unterschiedlichen Vertrauensstufen behandelt. Der Übergang vom einen in den andere – die Konsolidierung – ist der einzige Punkt, an dem etwas dauerhaft wird. Also ist er der Punkt, an dem geprüft wird.

Ebene 4 – Temporaler Verfall

TTL je Speicherart, nicht global. Session-Kontext in Stunden, episodische Protokolle in Wochen, semantische Fakten mit Ablauf- und Revalidierungsdatum. Ein „Fakt" über eine Person, der zwei Jahre lang niemand bestätigt hat, gehört nicht mehr in den Retrieval-Pfad.

Ebene 5 – Monitoring auf Schreibmuster

Auffällig ist bei MINJA nicht der einzelne Eintrag, sondern die Sequenz: ungewöhnlich viele Schreibvorgänge desselben Nutzers auf denselben semantischen Bereich, mit sukzessiv verkürzten Formulierungen. Solche Muster sind detektierbar – aber nur, wenn Schreibvorgänge überhaupt protokolliert werden. Laut der CSA-Erhebung vom 21. April 2026 erzwingen nur 24 Prozent der Organisationen überhaupt eine Protokollierung, wenn ein Agent seinen Handlungsrahmen überschreitet; nur 11 Prozent blockieren solche Aktionen automatisch, 38 Prozent verlangen dann eine menschliche Freigabe.

Auskunft und Löschung: Art. 15 und Art. 17 im Agentenspeicher

Der Europäische Datenschutzausschuss hat in Opinion 28/2024 (Dezember 2024) festgehalten, dass KI-Modelle, die mit personenbezogenen Daten trainiert wurden, nicht automatisch als anonym gelten. Für Agenten-Langzeitspeicher gilt das erst recht: Dort liegen Rohtexte, Namen, Fallnummern und Zusammenfassungen im Klartext beziehungsweise als Embeddings vor. Ein Vektorindex ist damit ein personenbezogenes Datenverarbeitungssystem, das Art. 15 (Auskunft) und Art. 17 (Löschung) DSGVO vollständig unterliegt – ohne Sonderstatus, ohne technische Ausrede.

Eine Löschung, vier Ablagen

Ein Löschersuchen ist im Agentenspeicher nur dann vollständig erfüllt, wenn es alle vier Ablagen erfasst:

• Rohprotokolle – Chatverläufe, Tool-Ein- und -Ausgaben, Fehlerlogs.
• Vektorindex – die Embeddings der betroffenen Passagen, auffindbar nur über Metadaten, nicht über Volltextsuche.
• Graph- beziehungsweise Fakten-Store – Knoten und Kanten, die die Person betreffen.
• Abgeleitete Zusammenfassungen – verdichtete Aussagen, in denen der Name längst nicht mehr vorkommt, der Personenbezug aber über den Kontext erhalten bleibt.

Die vierte Kategorie ist die, an der die meisten Konzepte scheitern. Ohne Provenance-Tracking je Eintrag lässt sich schlicht nicht feststellen, welche Zusammenfassung aus welchem gelöschten Rohdatum entstanden ist. Damit ist kein Löschnachweis führbar – und der Nachweis, nicht die Löschung selbst, ist die Pflicht des Verantwortlichen.

Das Zurechenbarkeitsproblem

Eine zweite CSA-Erhebung, veröffentlicht am 24. März 2026 (Befragung Januar 2026, 228 IT- und Security-Fachleute, finanziert von Aembit), benennt die technische Ursache: 68 Prozent der Organisationen können Agenten-Aktionen in ihren Audit- und Zugriffslogs nicht klar von menschlichen Aktionen unterscheiden. Dazu passen die Identitätsbefunde derselben Studie: 43 Prozent lassen Agenten unter geteilten Service-Accounts laufen, 31 Prozent unter menschlichen Identitäten, 74 Prozent geben an, dass Agenten mehr Zugriff erhalten als nötig, und 79 Prozent sehen schwer überwachbare Zugriffspfade.

Das ist der harte technische Grund, warum ein Auskunftsersuchen nach Art. 15 im Agentenspeicher praktisch scheitert: Ohne getrennte Agenten-Identität lässt sich kein Speichereintrag einer betroffenen Person – und keine Verarbeitung einem konkreten Vorgang – zuordnen. Passend dazu: Nur 21 Prozent der Unternehmen haben laut der Token-Security-Erhebung überhaupt einen formalen Decommissioning-Prozess für Agenten. Was passiert mit dem Speicher eines abgeschalteten Agenten? In vier von fünf Häusern ist das ungeklärt.

Die Frist, die diese Woche greift

Der zeitliche Druck kommt nicht nur aus der DSGVO. Für Hochrisiko-Systeme greifen die Protokollierungspflichten des EU AI Act – Art. 12 (Aufzeichnung) und die Aufbewahrungspflicht der Betreiber nach Art. 26 – ab dem 2. August 2026. Wer einen Agenten in einem Hochrisiko-Anwendungsfall betreibt, braucht ab diesem Datum belastbare Protokolle. Ein Speicher ohne Provenance liefert sie nicht.

Genau hier liegt der praktische Vorteil eines selbst betriebenen Systems. Die von OWASP unter ASI06 empfohlene Inspect-and-Clear-Fähigkeit – Werkzeuge, mit denen Betreiber gespeicherte Inhalte einsehen und gezielt löschen können – ist zugleich die technische Voraussetzung für Art. 15 und Art. 17. Bei einem Cloud-Agenten mit undokumentierter Speicherstruktur haben Sie diese Werkzeuge nicht. Wer die Speicherschicht selbst betreibt, kann sie bauen. Wie sich das in ein Gesamtkonzept einfügt, behandeln wir in unserer Agent-Governance und in der Beratung zu Datenschutz und KI.

Hardware- und Betriebsfolgen

Ein eigener Memory-Layer ist kein reines Softwarethema. Er hat Konsequenzen für Kapazitätsplanung und Betrieb, die sich qualitativ klar beschreiben lassen – und die man vor dem Projektstart kennen sollte.

Dauerhafte GPU-Last für Embeddings. Anders als bei einem klassischen RAG-System, bei dem der Index periodisch aufgebaut wird, erzeugt ein Agent laufend neue Speichereinträge. Jeder davon muss eingebettet werden. Die Embedding-Last ist damit kein einmaliger Batch, sondern eine kontinuierliche Grundlast neben der Inferenz – bei der Auslegung eines GPU-Servers ist das eine eigene Position, keine Rundungsdifferenz.

Der Index wächst mit der Retention, nicht mit der Nutzerzahl. Die entscheidende Stellschraube für die Indexgröße ist das TTL, nicht die Menge der Anwender. Ein aggressives Ablaufdatum je Speicherart ist die wirksamste – und billigste – Kapazitätsmaßnahme, die zugleich das Datenschutzrisiko senkt. Beide Ziele zeigen ausnahmsweise in dieselbe Richtung.

Mandantenpartitionierung kostet Overhead. Die von OWASP geforderte Isolation zwischen Nutzern und Aufgaben bedeutet in der Praxis mehrere getrennte Index-Partitionen statt einer großen. Das vervielfacht den Verwaltungsaufwand pro Index – ein Preis, der bewusst eingeplant werden muss, weil er sich später nur mit einem Umbau korrigieren lässt.

Löschung heißt Reindexierung. Selektives Entfernen aus einem Vektorindex ist je nach eingesetzter Datenbank ein teurer Vorgang. Wer Löschersuchen in vertretbarer Zeit bedienen will, muss die Partitionierung von Anfang an daran ausrichten – idealerweise so, dass die Einträge einer betroffenen Person in möglichst wenigen Partitionen liegen.

Snapshots als forensisches Werkzeug. Weil ASI06 mit verzögerter Auslösung arbeitet, wird ein vergifteter Eintrag oft erst Wochen später auffällig. Ohne versionierte Snapshots des Speichers lässt sich dann weder rekonstruieren, wann er entstand, noch auf einen sauberen Stand zurückrollen. Ein Backup-Konzept, das nur den letzten Stand hält, ist für diese Fehlerklasse wertlos.

Unterm Strich: Die Memory-Schicht verlangt dieselbe Ernsthaftigkeit wie eine produktive Datenbank – mit Retention-Policy, Zugriffsprotokoll, Backup-Strategie und Löschkonzept. Wenn Sie planen, Agenten produktiv zu betreiben, gehört diese Schicht in die Architektur, bevor der erste Agent live geht. Wir unterstützen dabei im Rahmen von KI-Agenten sicher betreiben.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. OWASP GenAI Security Project Top 10 for Agentic Applications 2026, veröffentlicht 09.12.2025
2. Cycode vollständige ASI01–ASI10-Liste inkl. ASI06 Memory & Context Poisoning
3. Palo Alto Networks Einordnung ASI06, 10.12.2025
4. OWASP AI Agent Security Cheat Sheet fünf Memory-Kontrollen, MEMORY_TTL_HOURS = 24, SHA-256-Checksumme
5. arXiv 2503.03704 (MINJA) ISR > 95 % / 98,2 %, ASR 76,8 %, EHRAgent, RAP, QA-Agent auf GPT-4 und GPT-4o
6. NeurIPS 2025 MINJA als Poster
7. Microsoft Security Blog AI Recommendation Poisoning, 10.02.2026: 31 Unternehmen, 14 Branchen, 50+ Prompts in 60 Tagen
8. The Hacker News Nachberichterstattung, MITRE ATLAS AML.T0080
9. Cloud Security Alliance / Token Security 21.04.2026, 418 Befragte: 82 % unbekannte Agenten, 65 % Vorfälle
10. Cloud Security Alliance / Aembit 24.03.2026, 228 Befragte: 68 % ohne Zurechenbarkeit
11. Kiteworks Audit-Trail-Lücke, EU-AI-Act-Logging ab 02.08.2026
12. Europäischer Datenschutzausschuss Opinion 28/2024, Dezember 2024

Häufig gestellte Fragen zum Agenten-Gedächtnis

Was unterscheidet Memory Poisoning von Prompt Injection?

Prompt Injection wirkt innerhalb einer Sitzung. Memory Poisoning schreibt manipulierte Inhalte in den persistenten Speicher und wirkt damit über Sessions und Nutzer hinweg fort.

Wie lösche ich personenbezogene Daten aus einem Agentenspeicher?

Nur wenn Sie alle Ablagen kennen: Rohprotokolle, Vektorindex, Graph und abgeleitete Zusammenfassungen. Ohne Provenance-Tracking je Eintrag ist ein Löschnachweis nicht führbar.

Reicht ein kürzeres Kontextfenster als Schutz?

Nein. Das Kontextfenster ist nur das Working Memory. Die Risiken entstehen in den persistenten Schichten darunter.

Warum ist das bei Cloud-Agenten kritischer?

Weil Sie weder Einblick in die Speicherstruktur noch Zugriff auf einen belastbaren Lösch- und Integritätsnachweis haben – beides verlangt die DSGVO aber vom Verantwortlichen.