System-Prompt-Extraktion

Was ist System-Prompt-Extraktion?

System-Prompt-Extraktion ist das Ziel, ein Modell dazu zu bringen, verborgenen Kontext offenzulegen, zu reproduzieren oder zu rekonstruieren, den die Anwendung in sein Kontextfenster gelegt hat, ohne ihn dem Anfragenden zeigen zu wollen. Das NIST-CSRC-Glossar definiert Prompt Extraction als Angriff, der versucht, den System Prompt oder andere Informationen im Kontext eines Large Language Model offenzulegen, die normalerweise vor einem Nutzer verborgen wären, in Anlehnung an die Terminologie von NIST AI 100-2e2025.

Der System Prompt ist das sichtbarste Element dieses verborgenen Kontexts, aber nicht das einzige. Entwickleranweisungen, abgerufener Richtlinientext, Tool-Schemata, Routing-Regeln, Konfigurationsfragmente und interne Kennungen können alle modell-sichtbar sein, ohne für Nutzer bestimmt zu sein. Extraktion zielt auf jedes dieser Elemente.

Ziel vs. Mechanismus

Die Angriffstaxonomie dieser Seite trennt Eintrittspfade von Zielen. Direkte und indirekte Prompt Injection sind Eintrittspfade: Sie beschreiben, wie angreiferkontrollierte Inhalte das Modell erreichen. System-Prompt-Extraktion ist eine Ergebnisklasse: Sie beschreibt ein beabsichtigtes Resultat, unabhängig davon, welcher Pfad den Versuch getragen hat.

Nicht jeder Extraktionsversuch ist eine Prompt Injection im engen Sinn, und nicht jede Prompt Injection zielt auf Extraktion. Ein Extraktionsversuch kann gelingen, während ein Verhaltensmanipulationsversuch scheitert, und umgekehrt. Berichte sollten angeben, welches von beiden beobachtet wurde.

Die Grenze des modell-sichtbaren Kontexts

Die entscheidende Grenze ist nicht, ob Inhalte als System Prompt bezeichnet werden. Sie ist, ob die Inhalte überhaupt in den Modellkontext gelegt werden. Alles, was das Modell lesen kann, kann grundsätzlich seine Ausgabe beeinflussen oder in ihr gespiegelt werden. Material außerhalb des aktuell modellsichtbaren Kontexts kann aus diesem Kontext über die Modellausgabe nicht extrahiert werden, weil das Modell es nie gesehen hat. Das gilt nur für den aktuellen Kontext: Wenn ein späterer autorisierter Tool-Aufruf oder Abrufpfad dieses Material oder daraus abgeleitete Informationen in den modellsichtbaren Kontext zurückgibt, entsteht eine eigenständige Tool-, Datenfluss- oder Abruf-Exposition, die unabhängig kontrolliert werden muss. Zugangsdaten und Autorisierungsentscheidungen sollten deshalb dauerhaft außerhalb des modellsichtbaren Kontexts bleiben, nicht nur außerhalb des aktuellen Prompts.

Anwendungen setzen Kontext aus vielen Quellen zusammen: Entwickleranweisungen, Nutzereingaben, Retrieval-Ergebnisse, Tool-Schemata und Tool-Ausgaben, Gedächtnis und Gesprächsverlauf. Der Assembly-Code entscheidet, was modell-sichtbar wird. Wer die Extraktionsgefährdung prüft, stellt daher eine konkrete Architekturfrage: Was legt diese Anwendung in das Kontextfenster, und was hält sie bewusst außerhalb?

Was verborgener Kontext typischerweise enthält

Dieselbe Extraktionsausgabe kann in einem Deployment harmlos und in einem anderen schwerwiegend sein. Entscheidend ist, welche dieser Bestandteile die Anwendung tatsächlich in den Kontext gelegt hat, nicht die Tatsache, dass ein System Prompt existiert.

Grade der Offenlegung

Extraktion ist nicht binär. Ein Bericht, der jede ausgabeseitig erkennbare Anweisung als vollständige Kompromittierung wertet, überzeichnet den Befund; ein Bericht, der alles unterhalb wörtlicher Offenlegung abtut, unterschätzt ihn. Vier Grade sollten unterschieden werden.

Voraussetzungen und erreichbarer Kontext

Ein Extraktionsversuch kann nur offenlegen, was tatsächlich erreichbar ist. Drei Voraussetzungen müssen erfüllt sein, bevor irgendein Grad der Offenlegung möglich ist: Im modell-sichtbaren Kontext des Ziel-Deployments muss verborgener Kontext existieren; der Versuch muss ein Modell erreichen, dem dieser Kontext zusammengestellt wurde; und die Modellausgabe muss den Anfragenden erreichen. Scheitert eine der drei Bedingungen, gibt es über das Modell nichts zu extrahieren.

Die Erreichbarkeit variiert je nach Deployment. Manche Anwendungen legen nur eine kurze Verhaltensanweisung in den Kontext; andere stellen große verborgene Kontexte mit Richtlinientext, Schemata und Konfiguration zusammen. Manche Deployments stellen jedem Anfragenden denselben Kontext bereit; andere stellen Kontexte pro Mandant oder Rolle zusammen, was verändert, wer was erreichen kann. Eine Prüfung, die nicht feststellt, was zusammengestellt wurde, kann nicht feststellen, was offengelegt wurde.

Die Erfolgskette der Extraktion

Extraktion ist eine Kette getrennter Bedingungen, von denen jede unabhängig erfüllt oder nicht erfüllt sein kann.

Die Kettenbetrachtung ist wichtig, weil Abwehrmaßnahmen sie an mehreren unabhängigen Stellen unterbrechen können: indem sie minimieren, was in den Kontext gelangt, begrenzen, was die Ausgabe spiegeln darf, und sicherstellen, dass nichts Sicherheitskritisches davon abhängt, dass verborgener Kontext geheim bleibt.

Getrennte Sicherheitsfakten

Ein akzeptierter Request ist nicht dasselbe wie existierender verborgener Kontext, das ist nicht dasselbe wie gespiegelter Kontext, das ist nicht dasselbe wie exakte Extraktion, das ist nicht dasselbe wie sensible Offenlegung, das ist nicht dasselbe wie eine umgangene Kontrolle, und das ist nicht dasselbe wie eine nachgelagerte Auswirkung. Jedes davon ist eine eigene, prüfbare Tatsache.

Diese Trennung hält Berichte ehrlich und die Abhilfe verhältnismäßig. Die exakte Offenlegung einer nicht geheimen Routing-Anweisung und die Offenlegung eingebetteter Zugangsdaten sind beides Extraktionen, aber nicht derselbe Vorfall.

Offensive Perspektive: Prüffragen

Bei der autorisierten Prüfung eigener Systeme geht es bei Extraktionstests um Erreichbarkeit und Grad, nicht um das Sammeln cleverer Formulierungen. Dieser Artikel stellt bewusst keine Extraktions-Prompts, Payload-Kataloge oder Verschleierungsrezepte bereit.

Eine Prüfung, die diese Fragen mit Belegen beantwortet, ist nützlicher als ein Screenshot eines Modells, das Anweisungen rezitiert, weil sie den Erreichbarkeitsbefund von der Folgenabschätzung trennt.

Direkte und indirekte Pfade zum selben Ziel

Das Ziel kann über beide Eintrittspfade verfolgt werden. Über den direkten Pfad steuert die eigene Eingabe des Anfragenden das Modell zur Offenlegung seines Kontexts. Über den indirekten Pfad enthält Inhalt, den das System abruft oder verarbeitet - eine Seite, ein Dokument, ein Retrieval-Ergebnis oder eine Tool-Ausgabe - Text mit demselben Offenlegungsziel, etwa um einen Agenten zu veranlassen, seine verborgenen Anweisungen in eine ausgehende Zusammenfassung oder ein geteiltes Artefakt aufzunehmen.

Die indirekte Variante wird leicht unterschätzt, weil der Anfragende ein legitimer Nutzer sein kann, der nie etwas Feindseliges eingegeben hat: Die Offenlegung wird durch Inhalt ausgelöst und landet in der Ausgabe, die dieser Nutzer erhält, oder in einem gespeicherten Artefakt, das über persistenten Zustand bestehen bleibt. Die Einordnung des Eintrittspfads und die Bewertung der Offenlegung bleiben getrennte Fragen.

Benachbarte Klassen und Abgrenzungen

Die Grenzen sind für die Einordnung wichtig. Die OWASP-Ausgabe 2026 verortet die Offenlegung von Laufzeitkontext unter LLM08:2026 Hidden Context Exposure und den Injektionsmechanismus unter LLM01:2026 Prompt Injection; das Auslaufen regulierter Nutzer- oder Trainingsdaten ordnet sie LLM02:2026 Sensitive Information Disclosure zu. Ein Vorfall kann mehrere Codes berühren.

Warum der System Prompt kein Geheimnis sein darf

Die zentrale Architekturregel: Alles, was im modell-sichtbaren Kontext liegt, ist als potenziell auffindbar zu behandeln. Die OWASP-Leitlinie von 2026 formuliert die Entwurfsannahme direkt - Entwerfende sollten davon ausgehen, dass verborgener Kontext auffindbar ist, sollten sicherstellen, dass eine Offenlegung keine oder kaum direkte Sicherheitsfolgen hat, und sollten weder Zugangsdaten einbetten noch verborgenen Kontext als Sicherheitsgrenze für Autorisierung, Rechtetrennung, Richtliniendurchsetzung oder Inhaltsfilterung verwenden.

Die Microsoft-Leitlinie zur Sicherheitsplanung für LLM-basierte Anwendungen trifft von Anbieterseite dieselbe Aussage: Sie führt die Offenlegung des System Prompts oder Metaprompts als zu bedenkende Bedrohung und empfiehlt, sensible Zugangsdaten und Verbindungszeichenfolgen dort nicht zu speichern. Dieser Artikel zitiert beide als Leitlinien, nicht als Garantie für ein bestimmtes Produkt.

Grundlagen dazu, was System Prompts leisten können und was nicht, bietet der Lernartikel System Prompts.

Die Auswirkung hängt vom Offengelegten ab

Der Schweregrad folgt dem Inhalt und der Abhängigkeit, nicht der Tatsache der Offenlegung. Die OWASP-Schweregradeinordnung von 2026 für Hidden Context Exposure reicht von informativ, wenn keine Geheimnisse oder sicherheitsrelevante Logik offengelegt wurden und nichts auf Vertraulichkeit beruhte, über mittel, wenn interne Regeln oder Workflow-Logik einem Angreifer spürbar helfen, ohne kritische Entscheidungen zu steuern, bis zu hoch, wenn Zugangsdaten eingebettet waren oder Geheimhaltung tragend war, und kritisch, wenn die Offenlegung in Remote Code Execution, breite Datenexfiltration oder Rechteausweitung in einem verbundenen System mündet.

Offengelegter Wortlaut allein - eine Rollenbeschreibung, eine Stilregel - ändert selten, was ein Angreifer tun kann. Offengelegte Richtlinienkriterien, Tool-Schemata, interne Kennungen oder eingebettete Zugangsdaten können das. Die Folgefrage lautet immer: Was ermöglicht dieses Material, das vorher nicht möglich war?

Durchgespieltes synthetisches Szenario

Ein Test-Deployment eines internen Dokumentationsassistenten wird vom eigenen Team geprüft. Der System Prompt enthält nicht geheime Routing- und Stilanweisungen sowie eine synthetische Konfigurationsmarkierung, die für die Übung platziert wurde. Eine separate synthetische vertrauliche Kanarienmarkierung liegt außerhalb des modell-sichtbaren Kontexts an einer vertrauenswürdigen Test- und Kontrollstelle; echte Geheimnisse oder vertrauliche Kanarienmarkierungen in Produktions-Prompts zu platzieren, wäre selbst der Architekturfehler, den dieser Artikel beschreibt. Zugangsdaten liegen in einem Tresor, und die Autorisierung wird von einem Gateway außerhalb des Modells durchgesetzt.

Der Kontrastfall ist das Antimuster: dasselbe Deployment mit einer Verbindungszeichenfolge oder einer Regel zum Umgehen von Freigaben im Prompt. Identische Extraktionsmechanik, kategorial anderer Vorfall. Das Szenario ist synthetisch; kein reales System, kein Payload und kein Geheimnis ist beteiligt.

Das architektonische Antimuster

Der Fehler hinter schwerwiegenden Extraktionsvorfällen ist nicht die Extraktion. Er ist, dass etwas Sicherheitskritisches im modell-sichtbaren Kontext platziert wurde oder dass eine Kontrolle still davon abhing, dass verborgener Kontext verborgen bleibt.

Jedes dieser Antimuster verwandelt einen Extraktionsbefund von informativ in schwerwiegend. Ihre Beseitigung ist die wirksamste Abhilfe, weil sie die Folgeseite jedes künftigen Extraktionsversuchs verändert, unabhängig davon, wie der Versuch ankommt.

Erkennung

Erkennung hat zwei Flächen. Auf der Eingabeseite können probabilistische Klassifikatoren Interaktionen markieren, die Extraktionsversuchen ähneln - mit den üblichen Grenzen probabilistischer Filterung. Auf der Ausgabeseite ist das stärkere Signal die Übereinstimmung: Modellausgaben werden mit dem bekannten zusammengestellten Kontext verglichen, einschließlich platzierter Canary-Markierungen, um Spiegelung oder Rekonstruktion zu erkennen.

Telemetrie kann Abfolge und Übereinstimmung feststellen. Sie kann in der Regel keine interne Modellkausalität beweisen - dass jenes Ausgabetoken aus jener Kontextzeile stammt. Erkennungsaussagen sollten auf dem Niveau bleiben, das die Belege hergeben.

Logging und Telemetrie

Extraktionsrelevante Telemetrie beantwortet, was zusammengestellt, was angefragt, was zurückgegeben wurde und was danach geschah - ohne selbst Geheimnisse zu protokollieren.

Kontextinhalte selbst sind sensible Betriebsdaten. Es sind Referenzen, Hashes und Klassifikationen zu protokollieren statt Rohkontext, damit das Telemetriesystem nicht zum nächsten Offenlegungskanal wird.

Vorfallreaktion

Die Reaktion ist verhältnismäßig, wenn sie der Inhaltsklassifikation folgt. Wörtliche Offenlegung nicht geheimer Stilregeln ist eine Härtungsaufgabe. Jede Offenlegung von Zugangsdaten oder tragender Richtlinien ist ein Vorfall mit Rotation, Prüfung abhängiger Kontrollen und, soweit erforderlich, Meldepflichten.

Prävention und Abschwächung

1. 01
   Verborgenen Kontext minimieren

   Nur das ins Kontextfenster legen, was die Aufgabe braucht. Jede weggelassene Zeile ist eine Zeile, die nicht extrahiert werden kann.

2. 02
   Geheimnisse außerhalb der Grenze halten

   Zugangsdaten, Tokens und Verbindungszeichenfolgen liegen in Tresoren und Gateways, die das Modell nie liest.

3. 03
   Kontrollen außerhalb des Modells durchsetzen

   Autorisierung, Datenflussrichtlinien und Filterung sind deterministische Systementscheidungen, keine Anweisungen an das Modell.

4. 04
   Ausgabespiegelung begrenzen

   Ausgabeseitige Prüfungen vergleichen Antworten mit dem zusammengestellten Kontext und blockieren oder markieren sensible Übereinstimmung, als probabilistische Schicht.

5. 05
   Kontexte nach Principal und Mandant trennen

   Kontextzusammenstellung pro Anfragendem begrenzt, welchen verborgenen Kontext eine einzelne Interaktion erreichen kann.

6. 06
   Kontextzusammenstellung prüfen und versionieren

   Kontextinhalte werden wie Konfiguration aufgezählt, geprüft und versioniert, weil sie genau das sind.

Keine dieser Schichten setzt voraus, dass der Extraktionsversuch scheitert. Sie sorgen dafür, dass ein erfolgreicher Versuch Material offenlegt, das nicht geheim und nicht tragend ist - das ist das erreichbare und ehrliche Ziel.

Sichere Architektur

Die stärkere Architektur kombiniert Kontrollen, die diese Seite separat behandelt: Agentenautorisierung entscheidet, welche Aktionen ausgeführt werden dürfen, Informationsflusskontrolle entscheidet, welche Daten wohin fließen dürfen, und Retrieval-Hygiene in RAG-Systemen begrenzt, welcher verborgene Kontext überhaupt zusammengestellt wird. Extraktion fällt dann auf einen folgenarmen Informationsbefund zurück.

Checkliste für das Threat Modeling

Kontrolliertes Testen und Metriken

Extraktionstests gehören in autorisierte Test-Deployments mit synthetischen Markierungen, niemals gegen Systeme Dritter. Metriken bleiben getrennt, jeweils mit explizitem Nenner, und werden nicht zu einem einzigen Score zusammengefasst.

Prompt-artige Ausgabe, die zu keinem bekannten verborgenen Material passt, ist ein Ergebnis falscher Offenlegung oder eines halluzinierten Prompts, kein Beleg dafür, dass der echte Prompt offengelegt wurde. Es gibt keinen universellen Schwellenwert für diese Zahlen. Ein Deployment, das seinen Kontext als nicht geheim behandelt, kann eine hohe Offenlegungsrate bewusst akzeptieren; eines, das sensiblen Richtlinientext zusammenstellt, nicht. Die Metrik wird erst zusammen mit der Inhaltsklassifikation zur Entscheidungsgrundlage.

Häufige Fehlvorstellungen

Standards und Klassifikationen

Die OWASP-Ausgabe 2025 führte System Prompt Leakage als eigenen Eintrag; die aktuelle Ausgabe 2026 behandelt das Risiko als LLM08:2026 Hidden Context Exposure, und diese Seite ordnet der Ausgabe 2026 zu. ATLAS katalogisiert die Technik als AML.T0056 Extract LLM System Prompt, erreichbar durch Prompt Injection oder durch Offenlegung von Konfiguration. Die Microsoft-Leitlinie ist als Herstellerleitlinie gekennzeichnet, nicht als universelle Produkteigenschaft.

Häufig gestellte Fragen