Memory and Context Poisoning

Was ist Memory and Context Poisoning bei KI-Agenten?

Memory and Context Poisoning beschreibt einen Laufzeit- und State-Integrity-Fehler in agentischen Systemen. Ein Agent übernimmt Inhalte aus untrusted Quellen in seinen Arbeitskontext oder in persistenten Speicher und behandelt sie später wie vertrauenswürdige Information. Genau diese Persistenz unterscheidet den Threat von rein transienten Fehlsteuerungen.

Für agentische Systeme ist das besonders kritisch, weil sie nicht nur antworten, sondern mehrstufig handeln: Sie lesen externe Inhalte, verdichten Historien, schreiben Memory, priorisieren nächste Schritte und nutzen Tools. Sobald der Zustand kippt, wird aus einer einmaligen Manipulation ein wiederkehrender Fehler in späteren Runs.

In der Praxis kann der vergiftete Zustand an mehreren Stellen entstehen:

• im aktuellen Session-Kontext
• in automatischen Session-Summaries
• in Langzeit-Memory oder “saved info”
• in RAG-Indizes oder Retrieval-Caches
• in Planner-Artefakten, Notizen oder Shared Context

Besonders kritisch ist das in Unternehmen, weil Agenten heute nicht nur antworten, sondern mit Tools arbeiten, Entscheidungen vorbereiten und Aktionen auslösen. Sobald der gespeicherte Zustand korrupt ist, startet jeder spätere Workflow mit einer manipulierten Ausgangslage. Deshalb führt OWASP Memory & Context Poisoning inzwischen als eigene agentische Risikokategorie.

Wie funktioniert Memory and Context Poisoning?

Der typische Ablauf ist kein einzelner Exploit, sondern eine Kette aus Ingestion, Fehlklassifikation, Speicherung und späterer Wiederverwendung. Besonders anfällig sind Systeme, die externe Inhalte lesen, automatisch zusammenfassen und Ergebnisse ohne harte Kontrollpunkte wieder in Prompts oder Planner-State einspeisen.

			flowchart TB
    source[Untrusted Quelle wie Upload, API, Webseite oder Chat]
    ingest[Agent liest den Inhalt im laufenden Workflow]
    write[Memory, Summary, Embedding oder RAG-Store wird beschrieben]
    gate{Write-Validation, Provenance und Isolation aktiv?}
    block[Eintrag wird blockiert, quarantainiert oder markiert]
    stored[Vergifteter Kontext bleibt als scheinbar legitimer Zustand erhalten]
    retrieve[Spaeteres Retrieval oder Wiederverwendung im naechsten Run]
    plan[Planner, Prioritaeten oder Tool-Auswahl werden beeinflusst]
    action[Agent fuehrt Entscheidungen oder Tool-Calls auf falscher Grundlage aus]
    spread[Vergiftung breitet sich ueber Sessions, Nutzer oder weitere Agenten aus]
    damage((Policy-Bypass, Datenabfluss, Drift oder Fehlentscheidung))

    source --> ingest --> write --> gate
    gate -->|Ja| block
    gate -->|Nein oder zu schwach| stored --> retrieve --> plan --> action --> damage
    stored --> spread --> damage

    classDef normal fill:#ffffff,stroke:#406749,stroke-width:1.5px,color:#181c1e;
    classDef warning fill:#f1f4f7,stroke:#406749,stroke-width:1.5px,color:#181c1e;
    classDef danger fill:#fdeceb,stroke:#844f59,stroke-width:1.5px,color:#181c1e;

    class source,ingest normal;
    class write,gate,stored,retrieve,plan,action,spread warning;
    class block,damage danger;
		

			flowchart TB
    source[Untrusted Quelle wie Upload, API, Webseite oder Chat]
    ingest[Agent liest den Inhalt im laufenden Workflow]
    write[Memory, Summary, Embedding oder RAG-Store wird beschrieben]
    gate{Write-Validation, Provenance und Isolation aktiv?}
    block[Eintrag wird blockiert, quarantainiert oder markiert]
    stored[Vergifteter Kontext bleibt als scheinbar legitimer Zustand erhalten]
    retrieve[Spaeteres Retrieval oder Wiederverwendung im naechsten Run]
    plan[Planner, Prioritaeten oder Tool-Auswahl werden beeinflusst]
    action[Agent fuehrt Entscheidungen oder Tool-Calls auf falscher Grundlage aus]
    spread[Vergiftung breitet sich ueber Sessions, Nutzer oder weitere Agenten aus]
    damage((Policy-Bypass, Datenabfluss, Drift oder Fehlentscheidung))

    source --> ingest --> write --> gate
    gate -->|Ja| block
    gate -->|Nein oder zu schwach| stored --> retrieve --> plan --> action --> damage
    stored --> spread --> damage

    classDef normal fill:#ffffff,stroke:#406749,stroke-width:1.5px,color:#181c1e;
    classDef warning fill:#f1f4f7,stroke:#406749,stroke-width:1.5px,color:#181c1e;
    classDef danger fill:#fdeceb,stroke:#844f59,stroke-width:1.5px,color:#181c1e;

    class source,ingest normal;
    class write,gate,stored,retrieve,plan,action,spread warning;
    class block,damage danger;
		

Das zentrale Problem ist also nicht nur bösartiger Input, sondern wiederverwendete Vertrauenswürdigkeit. Sobald ein Agent später auf vergiftete Erinnerung oder vergifteten Kontext zugreift, sieht der Run oft normal aus, obwohl die Ausgangsbasis bereits manipuliert wurde.

Memory Poisoning vs. Context Poisoning vs. Prompt Injection vs. RAG Poisoning

Viele Suchanfragen vermischen mehrere Begriffe. Für Architektur und Detection lohnt sich die Trennung trotzdem:

Manipulativer Inhalt ist also oft der Mechanismus, über den problematische Steuerimpulse in den Agentenlauf gelangen. Memory and Context Poisoning beschreibt den persistenten Zustand danach, wenn der Agent diesen Inhalt speichert, erneut abruft oder später wieder in Prompt, Summary oder Planner-State einspeist.

Nicht jede Prompt Injection führt zu Memory Poisoning. Umgekehrt kann persistenter Fehlzustand auch durch schlechte Summaries, schwache Memory-Governance oder fehlerhafte Konsolidierung entstehen, ohne dass ein einzelner bösartiger Prompt später noch sichtbar ist.

Warum Memory and Context Poisoning in Unternehmen besonders relevant ist

In vielen produktiven Umgebungen arbeiten Agenten gleichzeitig mit E-Mail, Browser, RAG, CRM, Ticketing, Drive, APIs und internen Wissensquellen. Genau diese Vielseitigkeit vergrössert die Angriffsoberfläche. Der Agent muss viel Kontext aufnehmen, aber genau dieser Kontext kann spätere Antworten und Aktionen systematisch verschieben.

Besonders anfällig sind Workflows, in denen der Agent:

• zwischen Information und Anweisung nicht sauber trennt
• Session-Summaries oder Langzeit-Memory später erneut nutzt
• mit Schreibrechten, Exportfunktionen oder externen Kommunikationskanälen arbeitet
• mehrere Nutzer, Agenten oder Mandanten über gemeinsame State-Layer verbindet
• Entscheidungen vorbereitet, die Menschen nur noch bestätigen

Der praktische Schaden entsteht dabei häufig erst später. Ein heute gespeicherter Poison kann in einer anderen Session, bei einem anderen Task oder sogar in einem anderen Agenten wieder auftauchen. Genau deshalb ist der Threat für Unternehmen nicht nur ein Qualitätsproblem, sondern ein Security- und Governance-Thema.

Realistische Beispiele für Memory and Context Poisoning

Welche Risiken entstehen für Unternehmen?

Memory and Context Poisoning ist für Unternehmen gefährlich, weil die Manipulation meist nicht wie ein klassischer Angriff aussieht. Der Agent argumentiert oft konsistent und führt formal korrekte Schritte aus. Das Problem liegt tiefer: Er arbeitet mit einem kompromittierten Zustand.

Wie verhindert man Memory and Context Poisoning?

Wirksame Mitigation kombiniert Write-Validation, State-Governance, Isolation, Least Privilege und Recovery-Fähigkeit. Es reicht nicht, nur am Prompt-Eingang zu filtern. Entscheidend ist, dass wiederverwendeter Kontext nicht automatisch vertrauenswürdig wird, nur weil er schon im System liegt.

In der Praxis ist die Kombination aus Memory und Context Security, Least Privilege, Monitoring und Logging und Human-in-the-Loop meist deutlich wirksamer als einzelne Guardrails ohne State-Governance.

Wie erkennt man Memory and Context Poisoning?

Detection ist schwierig, weil die Wirkung oft zeitversetzt auftritt. Gute Erkennung braucht deshalb Sicht auf den gesamten State-Lifecycle: Was wurde eingelesen, gespeichert, später wieder abgerufen und schliesslich für Entscheidungen oder Aktionen verwendet?

Wichtig sind dabei nicht nur Modell- oder Prompt-Logs, sondern auch Memory create/update/delete/retrieve, Session-Summary-Events, Retrieval-Treffer, Tool-Parameter, Policy-Entscheidungen und User-Approval-Schritte. Genau hier wird Agent Observability zur Sicherheitsvoraussetzung statt zum reinen Debugging-Werkzeug.

FAQ zu Memory and Context Poisoning bei KI-Agenten