Zum Inhalt springen
AI Agent Security
Kontakt
Menü

29.03.2026

Aktualisiert 27.07.2026

Threat

Memory and Context Poisoning

Fremde Inhalte können in Kontext und Memory eines KI-Agenten bestehen bleiben. Gefährlich wird das, wenn spätere Entscheidungen und Tool-Aufrufe diesem Zustand vertrauen.

Memory and Context Poisoning

Was Memory and Context Poisoning ist

Bei Memory and Context Poisoning gelangen falsche oder manipulative Inhalte in den Arbeitskontext, eine Sitzungszusammenfassung, Langzeit-Memory oder eine andere wiederverwendete Zustandsschicht. Spätere Agentenläufe behandeln diesen Zustand dann wie eine vertrauenswürdige Grundlage.

Anders als eine einmalige Fehlantwort bleibt die Manipulation erhalten und kann zukünftige Planung, Retrieval, Tool-Auswahl und Entscheidungen beeinflussen.

Wie der Angriff funktioniert

Der Angriff verbindet eine unvertrauenswürdige Quelle mit einem unzureichend kontrollierten Schreibvorgang im Memory. Seine Wirkung zeigt sich oft erst in einer späteren Sitzung.

Von der Quelle zum persistenten Fehlzustand
1

Fremder Inhalt

Webseite, E-Mail, Dokument oder Peer liefert Daten

2

Memory-Schreibvorgang

Zusammenfassung oder Speicher übernimmt den Inhalt

3

Späterer Abruf

Eine neue Aufgabe lädt den Eintrag erneut

4

Beeinflusste Aktion

Planung oder Tool-Nutzung folgt dem vergifteten Zustand

Mögliche Folgen

Fehler kehren über Sessions zurück

Geteilter Kontext verbreitet sie

Tools handeln auf falscher Grundlage

Der Ursprung kann beim späteren Abruf längst unsichtbar sein. Deshalb müssen Teams nicht nur Prompts, sondern den gesamten Lebenszyklus aus Schreiben, Aktualisieren, Abrufen, Nutzen und Löschen beobachten.

Kurzfristiger Kontext oder persistentes Memory?

Context Poisoning

Manipulation im Arbeitskontext

Falsche Information beeinflusst den aktuellen Lauf oder eine wiederverwendete Session-Zusammenfassung.

Input Session Agent

Wirkt vor allem im aktiven Kontext

Kann über Summaries in spätere Läufe reichen

Memory Poisoning

Manipulation im Langzeitspeicher

Ein vergifteter Eintrag bleibt über Sitzungen bestehen und wird später erneut abgerufen.

Input Memory Spätere Läufe

Persistiert als Zustand oder gespeicherter Fakt

Braucht Versionierung, TTL und Rollback

Prompt Injection ist häufig der Eintrittspfad. RAG Poisoning betrifft externe Wissensquellen. Memory and Context Poisoning beschreibt den kompromittierten agentischen Zustand, der daraus entstehen und wiederverwendet werden kann.

Drei typische Angriffsszenarien

Webseite schreibt Regeln ins Langzeit-Memory

Research
Seite lesen
Versteckte Regel
Memory-Write

Ein Research-Agent speichert nicht nur Fakten, sondern eine fremde Priorisierung oder Handlungsregel. Spätere Recherchen starten dadurch bereits mit manipulierten Annahmen.

E-Mail vergiftet eine Session-Zusammenfassung

Workspace
Mail verarbeiten
Zusammenfassung
Falscher Empfänger

Ein Produktivitätsagent übernimmt eine manipulierte Kontakt- oder Freigaberegel in die Zusammenfassung. In einem späteren Task sendet er Daten an ein falsches Ziel.

Falsche Annahme wandert zu weiteren Agenten

Shared Context
Vergifteter Zustand
Gemeinsame Notiz
Weitere Agenten

Ein Support-Agent speichert eine falsche Richtlinie in gemeinsamem Kontext. Reviewer und Executor übernehmen sie, obwohl sie für einen anderen Nutzer oder Mandanten erzeugt wurde.

Was wirklich schützt

Memory-Sicherheit beginnt beim Schreiben und endet erst nach Ablauf oder kontrollierter Löschung. Jeder Eintrag braucht einen klaren Vertrauensstatus und darf nur für passende Aufgaben wiederverwendet werden.

Drei priorisierte Schutzschichten
Schutzschicht 1
Memory-Writes kontrollieren

Quelle, Schema, Mandant, Sensitivität und Instruktionscharakter vor dem Speichern prüfen; unvertrauenswürdige Inhalte blockieren oder quarantänisieren.

Schutzschicht 2
Zustände trennen und rückverfolgbar machen

Sitzung, Zusammenfassung, Langzeit-Memory, RAG und Planungszustand isolieren sowie Provenienz, Vertrauensstufe, TTL und Revision an jedem Eintrag erhalten.

Schutzschicht 3
Abruf und Wirkung begrenzen

Retrieval nach Nutzer und Zweck filtern, Tool-Rechte minimal halten und kritische Aktionen nie allein durch gespeicherten Kontext autorisieren.

Ein vergifteter Eintrag kann erkannt, isoliert und zurückgerollt werden, bevor er spätere Sitzungen oder reale Aktionen beeinflusst.

Memory-Writes, Retrieval-Treffer und Folgeaktionen sollten gemeinsam protokolliert werden. Bei geteiltem Zustand müssen dieselben Grenzen auch zwischen Agenten über sichere Inter-Agent-Kommunikation gelten.

Wie Teams Angriffe erkennen und testen

  • Memory-Diffs überwachen: Neue Regeln, Prioritäten oder imperative Formulierungen nach fremden Inhalten hervorheben.
  • Provenienz bis zur Aktion verfolgen: Quelle, Schreibvorgang, Revision, Abruf und Tool-Aufruf in einer gemeinsamen Spur verbinden.
  • Ausbreitung erkennen: Gleiche falsche Annahmen über Sitzungen, Nutzer, Mandanten oder mehrere Agenten korrelieren.
  • Persistenz gezielt testen: Präparierte Webseiten, E-Mails, Dokumente und Peer-Nachrichten einspeisen und spätere Läufe auf Wiederauftreten prüfen.

Wiederherstellung gehört zum Test: Teams sollten vergiftete Einträge quarantänisieren, abhängige Zusammenfassungen finden und einen bekannten sicheren Zustand wiederherstellen können. Mehr dazu unter Agent Observability.

Quellen