Persistente Prompt Injection

Was ist persistente Prompt Injection?

Persistente Prompt Injection beschreibt Prompt-Injection-Einfluss, der die Begegnung überdauert, in der er entstanden ist. Der beeinflussende Inhalt wird entweder in einen Zustand geschrieben, den das System behält, oder er bleibt an einer Quelle erreichbar, die das System erneut liest. Dadurch können spätere Aufgaben, spätere Sitzungen, andere Nutzer oder andere Agenten von Material betroffen sein, das in diesem späteren Moment niemand eingegeben hat.

Der Eintrittsmechanismus ist nicht neu. Konkurrierende Anweisungen kommen weiterhin über einen vorgesehenen Eingabekanal, wie unter direkte Prompt Injection beschrieben, oder über externe Inhalte, die das System abruft, liest oder verarbeitet, wie unter indirekte Prompt Injection beschrieben. Dieser Artikel behandelt den Lebenszyklus danach: was das System behält, ob und wie die Provenienz dieses Materials erhalten bleibt, geschwächt wird oder verloren geht, wann es erneut modellsichtbar wird und welche Entscheidungen zwischen Reaktivierung und einer tatsächlichen Sicherheitswirkung stehen.

Persistenz ist eine Lebenszykluseigenschaft, kein dritter Eintrittsmodus

Es liegt nahe, Persistenz neben direkt und indirekt als dritten Weg hinein einzuordnen. Das ist sie nicht. Jeder persistente Fall beginnt mit einem der beiden etablierten Eintrittsmodi und erhält dann eine zweite Eigenschaft: das beeinflussende Material oder ein davon abgeleitetes Artefakt überdauert.

Persistenz als Eigenschaft statt als Klasse zu lesen, trennt zwei nützliche Fragen. Erstens: Wie ist der Inhalt hineingekommen? Zweitens: Was hat das System behalten, und unter welcher Autorisierung? Die zweite Frage ist der eigentliche Gegenstand dieses Artikels.

Umfang und verwandte Klassen

Zwei Familien der Persistenz

Persistente Prompt Injection ist breiter als Memory Poisoning, denn ein System kann wiederholt von demselben Material beeinflusst werden, ohne jemals ein Memory-Objekt zu schreiben. Zwei Familien verdienen gleiches Gewicht.

Beide Familien versagen unterschiedlich. Abgeleiteter Zustand ist für die betroffene Person oft weniger sichtbar und schwerer prüfbar und trägt einen impliziten Relevanzanspruch. Wiederverarbeitete Quellen können je nach System und Arbeitsablauf sichtbar sein, erzeugen aber weiter Einfluss, solange niemand die Quelle oder die Abrufregel ändert. Ein Programm, das nur Schreibpfade härtet, liest die vergiftete Datei weiter; ein Programm, das nur Quellen bereinigt, behält die Zusammenfassung, die sie verdichtet hat. Aus Vektorsicht behandeln das Quellcode-Prompt-Injection und RAG-Prompt-Injection; hier gelten beide als Persistenzflächen.

Der Persistenz-Lebenszyklus

Jeder Pfeil in dieser Kette ist eine Stelle, an der der Versuch enden kann. Inhalte können modellsichtbar werden, ohne je gespeichert zu werden. Gespeichertes kann nie wieder abgerufen werden. Abgerufenes kann so zusammengefasst werden, dass die Anweisung nicht mehr enthalten ist. Und reaktivierter Einfluss kann nichts weiter erzeugen als einen abgelehnten Vorschlag, weil die Autorisierungsschicht das Modell nicht danach fragt, was es tun darf.

Sicherheitszustände, die sauber getrennt bleiben müssen

Dieselbe Disziplin gilt für das Wort Kompromittierung. Ein geschriebener Memory-Eintrag mit beeinflusstem Text ist eine sicherheitsrelevante Zustandsänderung und verdient eine Untersuchung. Er ist für sich genommen kein kompromittiertes System, kein kompromittiertes Nutzerkonto und kein kompromittiertes Modell.

Inventar der Persistenzflächen

Provenienzrisiko bei Zusammenfassungen und Kompaktierung

Die Kompaktierung kann ein wesentlicher Punkt sein, an dem Provenienz verloren geht, und das geschieht unauffällig. Werden Eingaben gemischter Vertrauensstufen ohne Herkunfts- und Vertrauensangaben je Quelle zu einem einzigen Artefakt verdichtet, können die Herkunftsunterschiede verloren gehen. Speichert die Pipeline die Zusammenfassung als ein Artefakt ohne Herkunftsangaben je Quelle, kann zuvor als nicht vertrauenswürdig markiertes Material später als neutral wirkende Prosa wieder auftauchen, scheinbar vom System selbst erzeugt.

Anforderungen an Provenienz und Herkunftsketten

Alles, was auf eine Persistenzfläche geschrieben wird, sollte genug Metadaten tragen, damit eine spätere Leseentscheidung möglich ist und eine spätere Untersuchung jede Kopie findet.

Die Herkunftskette ist für die Bereinigung besonders wichtig. Ohne sie lassen sich Ableitungen nicht zuverlässig aufzählen, und das Löschen einer vergifteten Quelle lässt offen, was daraus abgeleitet wurde.

Memory-Schreibvorgänge sind sicherheitsrelevante Zustandsänderungen

Ein Schreibvorgang, der künftiges Verhalten prägen kann, sollte als sicherheitsrelevante, konfigurationsähnliche Zustandsänderung behandelt werden. Er sollte entsprechend geregelt werden, und die regelnde Entscheidung sollte nicht von der Komponente getroffen werden, die gerade beeinflusst wird.

Die Trennung hat praktische Folgen. Ein Vorschlag kann protokolliert und geprüft werden, ohne gespeichert zu werden. Ein abgelehnter Vorschlag belegt Einfluss, nicht einen vergifteten Speicher. Und ein genehmigter Schreibvorgang lässt sich mit der genehmigenden Richtlinienversion erfassen, was die spätere Prüfung erst handhabbar macht.

Schemagebundene, eingegrenzte und umkehrbare Speicherung

Freitext-Memory ist in der Regel schwerer einzugrenzen, weil jeder Satz wie eine Regel wirken kann. Wo die Domäne es zulässt, kann die Speicherung typisierter Felder statt Prosa die Instruktionsfläche verringern, ohne die Funktion zu entfernen.

1. 01
   Typisiertes Schema

   Bekannte Felder mit bekannten Wertebereichen speichern und Schreibvorgänge ablehnen, die nicht ins Schema passen.

2. 02
   Expliziter Geltungsbereich

   Jeden Eintrag an Nutzerin, Projekt, Mandant oder Aufgabe binden und Abrufe außerhalb dieses Bereichs verweigern.

3. 03
   Vertrauenslabel

   Die Klassifikation der zugrundeliegenden Inhalte erfassen und über jede Transformation hinweg mitführen.

4. 04
   Ablauf und Revalidierung

   Einträge mit Gültigkeitsdauer versehen und alles revalidieren lassen, was Verhalten einschränken will.

5. 05
   Versionierung und Diff

   Frühere Versionen behalten, damit eine Änderung prüfbar und umkehrbar ist, ohne den ganzen Speicher neu aufzubauen.

6. 06
   Rollback und gezielte Löschung

   Es muss möglich sein, einen Eintrag samt Ableitungen zu entfernen, nicht nur alles zu löschen.

Der Abruf ist eine eigene Risikoentscheidung

Auch ein korrekt autorisierter Schreibvorgang bedeutet keine automatische spätere Nutzung. Die Zusammenstellung des Kontexts ist eine eigene Entscheidung, zu anderer Zeit, oft für eine andere Aufgabe und manchmal für eine andere Person.

Prüfungen zum Abrufzeitpunkt können verhindern, dass ein in einem Projekt vergifteter Eintrag eine unabhängige Aufgabe prägt. Sie liefern zugleich einen natürlichen Protokollpunkt: dass ein Eintrag geprüft und verworfen wurde, ist eine nützliche Spur.

Geltungsbereich und Ausweitung des Geltungsbereichs

Persistenter Zustand existiert in verschiedenen Geltungsbereichen: einzelne Aufgabe, Sitzung, Nutzerin, Projekt, Workspace, Mandant, Agent oder global. Der Geltungsbereich entscheidet, wer betroffen sein kann, und sollte eine explizite Eigenschaft sein statt ein Nebenprodukt.

Wiederverwendung über Sitzungen, Nutzer und Agenten hinweg

Wiederverwendung über Grenzen hinweg kann die mögliche Auswirkung über die ursprüngliche Aufgabe oder Identität hinaus ausweiten. Drei Muster treten wiederholt auf und sollten getrennt werden.

Der agentenübergreifende Fall führt direkt zu Multi-Agent-Prompt-Injection: Ausbreitung bewegt Einfluss innerhalb einer Aufgabe über Agentengrenzen, Persistenz bewegt ihn über die Zeit, und im geteilten Gedächtnis treffen sich beide.

Verzögerte und schlafende Reaktivierung

Forschung zu Memory Poisoning in Agentensystemen hat Einträge untersucht, die beim Schreiben keine sichtbare Wirkung haben und erst in einem späteren Gespräch unter bestimmten Bedingungen Verhalten prägen. Dieses Muster ist defensiv nützlich, weil es die Annahme zerstört, ein harmlos wirkender Schreibvorgang sei ein harmloser Schreibvorgang.

Die Erfolgskette der Persistenz

Für Bewertung und Bericht ist die Kette als Folge von Toren leichter handhabbar, die sich jeweils unabhängig beobachten lassen.

Das tiefste erreichte Tor ist der Befund. Nur das Endergebnis zu berichten, verbirgt, ob das System die Kette planmäßig früh oder zufällig spät gestoppt hat.

Autorisierte offensive Bewertung

Eine autorisierte Bewertung von Persistenz beantwortet Architekturfragen. Der Wert liegt in der Kartierung der Schreib- und Abrufpfade, nicht im Formulieren von Text, dem ein bestimmtes Modell zufällig folgt.

Durchgespieltes synthetisches Szenario

Das folgende Szenario ist synthetisch, begrenzt und umkehrbar. Es zeigt, welche Zustände sich unterscheiden lassen, und ist nicht dafür gedacht, gegen ein produktives System nachgestellt zu werden.

Erkennung und Telemetrie

Eine durchgängige Rekonstruktion von Persistenz setzt Einblick in Schreiben, Abrufen und Verwenden voraus. Protokolliert eine Installation nur das Gespräch und nichts über die Memory-Schicht, wird eine spätere Rekonstruktion schwierig.

Semantik von Löschung und Bereinigung

Ein typischer Bereinigungsfehler besteht darin, die Quelle zu löschen und die Sache für erledigt zu erklären. Abgeleitete Artefakte folgen ihren Eingaben nicht von selbst.

Deshalb gehören Herkunftsverweise in die Schreibmetadaten und nicht in ein Runbook. Ohne sie lässt sich Vollständigkeit der Bereinigung nicht prüfen, sondern nur behaupten.

Defensive Architektur

1. 01
   Kontrollierter Schreibpfad

   Kein persistenter Schreibvorgang ohne externe Autorisierungsentscheidung und erfassten Grund.

2. 02
   Unveränderliche Provenienz und Herkunftskette

   Quelle, Schreibender, Geltungsbereich, Richtlinienversion und Ableitungsverweise werden einmal geschrieben und sind für das Modell nicht änderbar.

3. 03
   Isolation

   Grenzen je Nutzerin, Mandant und Aufgabe werden beim Abruf durchgesetzt, nicht nur beim Schreiben.

4. 04
   Schemagebundene Speicherung und Vertrauenslabel

   Wo möglich typisierte Felder, wobei Provenienz und Vertrauen über Transformationen hinweg granular erhalten bleiben; lässt sich diese Granularität nicht halten, erben Ableitungen ersatzweise die niedrigste Vertrauensklasse ihrer Eingaben.

5. 05
   Ablauf und Freigabe bei höherer Wirkung

   Befristete Einträge und menschliche Freigabe für alles, was Verhalten einschränken will.

6. 06
   Kontexttrennung

   Abgerufener Zustand steht in einem klar markierten Datenbereich und wird nie in den Instruktionskanal gemischt.

7. 07
   Autorisierung der exakten Aktion

   Die Aktion wird gegen ihre konkreten Parameter und ihr Ziel autorisiert, unabhängig vom zusammengestellten Kontext.

8. 08
   Egress- und Datenflusskontrolle

   Ausgehende Pfade sind so begrenzt, dass ein beeinflusster Plan kein nicht freigegebenes Ziel erreichen kann.

9. 09
   Versionierung, Diff und Rollback

   Jede Änderung ist prüfbar und umkehrbar, ohne alles neu aufzubauen.

10. 10
    Beobachtbarkeit von CRUD und Nutzung

    Schreiben, Abrufen und Verwenden werden protokolliert und sind durchgängig korrelierbar.

Incident Response für persistenten Zustand

Saubere Einordnung zählt hier aus demselben Grund wie bei agentischen Fällen: Eine reaktivierte Notiz, die zu einem abgelehnten Vorschlag geführt hat, und eine Notiz, die zu einer ausgeführten Überweisung geführt hat, sind verschiedene Vorfälle mit verschiedenen Pflichten.

Kontrollierte Tests und Kennzahlen

Persistenztests brauchen eine Zeitdimension, was sie langsamer als Einzelrunden-Tests macht und deutlich aussagekräftiger. Jede Kennzahl unten wird getrennt berichtet, mit genanntem Nenner.

Standards und Forschungskontext

OWASP LLM01:2026 liefert den Injection-Mechanismus. Der Eintrag ASI06 der OWASP Top 10 for Agentic Applications 2026 behandelt gespeicherte und abrufbare Informationen und nennt Konversationsauszüge, Memory-Werkzeuge, erweiterten Kontext, Zusammenfassungen, Embeddings und RAG-Stores; einmalige Eingabeprompts bleiben ausgenommen und fallen unter LLM01:2026. Ein begleitender OWASP-Projektbeitrag vom Mai 2026 behandelt Memory als Funktion, die zugleich Angriffsfläche ist; das ist Fachkommentar aus dem Projekt, keine normative Anforderung. NIST AI 100-2e2025 liefert die hier genutzte Terminologie.

Der Microsoft-Katalogeintrag zu AI Memory und Context Poisoning beschreibt Langzeit-Kontextspeicher, Grounding-Caches, Präferenzspeicher, Vektordatenbanken und Gesprächshistorien als dauerhafte Angriffsflächen. Die Microsoft-Leitlinie zur Memory-Sicherheit in agentischen Systemen behandelt Memory als Konfigurationsschicht des Systems, empfiehlt kontrollierte Schreibvorgänge, Isolation, den Abruf als eigene Entscheidung sowie Beobachtbarkeit über den Lebenszyklus mit Versionierung, Auditing und Rollback. Das sind Herstellerempfehlungen und werden als solche zitiert. Wo dort Sanitisierung oder Trust Scoring genannt sind, behandelt dieser Artikel sie als probabilistische Schichten, nicht als Autorisierung.

Als offengelegter produktspezifischer Fall hat Cisco im April 2026 Forschung veröffentlicht, die eine Methode beschreibt, das Memory von Claude Code zu kompromittieren und Persistenz über die unmittelbare Sitzung hinaus zu halten, über Projekte und Sitzungen hinweg und über Neustarts, in der untersuchten Version. Cisco berichtet, dass nach Zusammenarbeit mit dem Application-Security-Team von Anthropic eine Änderung in Claude Code v2.1.50 ausgeliefert wurde, die die genutzte Fähigkeit aus dem System Prompt entfernt. Die Lehre betrifft Vertrauensgrenzen um Memory- und Instruktionszustand, nicht eine allgemeine Eigenschaft aller Memory-Systeme; Teile des Angriffswegs werden hier nicht wiedergegeben.

Auf der Forschungsseite untersuchen eine systematische Studie zu Memory-Poisoning-Angriffen in Agentensystemen und Arbeiten zu verzögertem, schlafendem Memory Poisoning, wie aus nicht vertrauenswürdiger Eingabe vertrauenswürdiges Gedächtnis wird und wie Wirkungen erst in späteren Gesprächen auftreten. Spätere Arbeiten aus 2026 setzen diese Richtung fort. Alles davon ist zugeschriebene Forschung, deren Ergebnisse zu den untersuchten Konfigurationen gehören und hier nicht verallgemeinert werden. Verwandtes Material auf dieser Seite behandelt die Eintrittspfade unter indirekte Prompt Injection und RAG-Prompt-Injection, die Agentenschleife unter AI-Agent-Prompt-Injection, die Antwortseite von Tools unter Tool-Output-Injection und die Kontrollarchitektur im Abwehrbereich.

Häufige Fragen