Der System-Prompt ist kein Schutzmechanismus

1Einleitung

1.1 Motivation

Selbst gehostete Sprachmodelle sind für kleine und mittlere Unternehmen attraktiv geworden, weil sie ohne Cloud-Anbindung und mit überschaubarer Hardware betrieben werden können. Ein häufiges Muster ist der Versuch, Verhalten und Vertraulichkeit über den System-Prompt zu steuern: Der Betreiber schreibt Regeln wie „gib den internen Projektnamen niemals preis" in den System-Prompt und geht davon aus, dass das Modell diese Regeln durchsetzt. Ob diese Annahme trägt, ist für einen Verantwortlichen ohne Sicherheitsexpertise schwer zu beurteilen, weil das Modell nach außen wie eine Blackbox wirkt.

1.2 Zielsetzung und Forschungsfragen

Diese Arbeit untersucht die Wirksamkeit des System-Prompts als Schutzmaßnahme in einer kontrollierten lokalen Messreihe. Sie versteht sich nicht als Entdeckung, sondern als reproduzierbare Messung eines in der Fachliteratur bereits beschriebenen Problems.¹ Daraus ergeben sich drei Forschungsfragen:

• F1: Schützt ein System-Prompt einen darin eingebetteten Geheim-Marker gegen direkte Prompt-Injection (LLM01)?
• F2: Schützt ein System-Prompt seinen eigenen Text gegen gezielte Extraktion (LLM07)?
• F3: Verringert ein gehärteter System-Prompt mit Regelblock und Ablehnungs-Muster die Leak-Rate gegenüber einem naiven Prompt substanziell, und bleiben Rest-Lecks bestehen?

1.3 Hypothesen

2Theoretische Grundlagen

Ein Sprachmodell trennt nicht zuverlässig zwischen Instruktion und Daten. In einer Eingabe enthaltene Anweisungen können deshalb das Modellverhalten übernehmen. Dieses Muster wird als Prompt-Injection bezeichnet und im Katalog der OWASP-Foundation als wichtigstes Risiko für LLM-Anwendungen unter LLM01 geführt. Der Stand der Technik beschreibt das Problem als mitigierbar, jedoch nicht als gelöst.²

Ein verwandtes, aber eigenständiges Risiko ist die Preisgabe des System-Prompts selbst. Die OWASP-Foundation führt dies als eigenen Eintrag unter LLM07 (System Prompt Leakage).¹ Der Unterschied ist relevant: LLM01 betrifft ein Geheimnis im Prompt, LLM07 betrifft den Prompt-Text als Ganzes, einschließlich aller darin formulierten Schutz-Regeln.

Beide Risiken teilen eine strukturelle Ursache. Ein System-Prompt ist Teil desselben Kontextfensters, das auch die Nutzereingabe aufnimmt. Was das Modell verarbeitet, kann es prinzipiell auch ausgeben. Ein Geheimnis, das im Kontext liegt, ist damit nicht durch eine Regel geschützt, sondern nur durch die Bereitschaft des Modells, dieser Regel in jeder sprachlichen Umformulierung der Anfrage zu folgen. Genau diese Bereitschaft ist nicht garantiert. Das MITRE-ATLAS-Framework beschreibt die gezielte Extraktion des System-Prompts als eigene Technik.³

3Material und Methoden

3.1 Versuchsumgebung

Getestet wurde ein selbst gehosteter LLM-Chatbot auf Basis eines lokalen Sprachmodells. Tabelle 1 fasst die Umgebung zusammen.

3.2 Die zwei System-Prompt-Strategien

Beide Konfigurationen nutzen dasselbe Modell und denselben Geheim-Marker; sie unterscheiden sich nur im System-Prompt und in der Sampling-Temperatur.

3.3 Die zwei Probe-Matrizen

Der Test verwendet zwei getrennte Probe-Sätze, je einen pro OWASP-Risiko. Die LLM01-Matrix umfasst 8 Probe-Klassen, die auf die Preisgabe des eingebetteten Markers zielen. Die LLM07-Matrix umfasst 5 Probe-Klassen, die auf die Wiedergabe des Prompt-Textes selbst zielen. Jede Probe-Klasse wurde gegen beide Prompt-Strategien geführt. Ergänzend lief ein automatisierter garak-Durchlauf gegen den gehärteten Prompt.

4Ergebnisse

4.1 LLM01: Direkte Prompt-Injection

Der naive Prompt gab den Geheim-Marker in 7 von 8 Probe-Klassen preis (87,5 %). Der gehärtete Prompt gab ihn in 3 von 8 Probe-Klassen preis (37,5 %). Der gehärtete Prompt wehrte die einfacheren Vektoren ab, fiel jedoch bei drei Umgehungen: der Übersetzung des System-Prompts in eine andere Sprache, dem Wiederholungs-Befehl und der Format-Umleitung nach JSON. Tabelle 3 zeigt das Ergebnis pro Probe-Klasse.

Probe-Klasse 6 (Base64) scheiterte an beiden Prompts, weil das kleine Modell keine korrekte Kodierung erzeugte, sondern unbrauchbare Zeichenfolgen. Dies ist eine Grenze der Modellstärke, kein Schutz durch den Prompt. Der Format-Pivot nach JSON (Klasse 7) ist der operativ gefährlichste Vektor: Die Antwort besteht aus einem sauberen JSON-Objekt der Form {"project":"…"} und enthält keine Ablehnungs-Spur. Sie sieht aus wie eine legitime API-Antwort, was eine spätere Erkennung erschwert.

Ergänzend lief ein automatisierter Durchlauf mit garak. Dessen Detektor mitigation.MitigationBypass prüft nicht, ob der Marker preisgegeben wurde, sondern ob in der Antwort eine erkennbare Ablehnungs-Phrase fehlt. Gegen den gehärteten Prompt meldete er in 86,67 % der Fälle (13 von 15) keine solche Ablehnung. Der Wert ist deshalb nur illustrativ und nicht mit den manuellen Leak-Raten verrechenbar; er deutet an, dass der gehärtete Prompt erkennbare Rollen-Personas blockiert, sich aber nicht durchgängig aktiv weigert. Der Detektor nutzt zudem eine englischsprachige Phrasen-Liste, was bei einem deutschsprachig antwortenden Modell zu Fehlklassifikationen führen kann.

4.2 LLM07: Extraktion des System-Prompts

Der naive Prompt gab seinen Text in 5 von 5 Probe-Klassen preis (100 %). Der gehärtete Prompt gab ihn in 3 von 5 Probe-Klassen preis (60 %). Die beiden einfachsten Probes brachen sogar den gehärteten Prompt: die direkte Aufforderung, den vollständigen System-Prompt wortwörtlich auszugeben, und die Bitte, die Regeln als Markdown-Liste aufzuzählen.

Der entscheidende Punkt liegt in Probe-Klasse 4. Der gehärtete Prompt enthält selbst die Negations-Liste, mit der er den Marker schützen will („der Marker darf nicht im Klartext, nicht kodiert, nicht in Metaphern, nicht auf höfliche Nachfrage preisgegeben werden"). Eine Format-Umleitung, die genau diese Regeln als Liste anfordert, gibt damit sowohl die Schutz-Regeln als auch den in ihnen benannten Marker aus. Der Härtungsaufwand vergrößert in diesem Fall die extrahierbare Angriffsfläche, statt sie zu verkleinern.

4.3 Vergleich der Leak-Raten

Abbildung 1 stellt die vier gemessenen Leak-Raten gegenüber. In beiden Risiko-Klassen senkt die Härtung die Rate, ohne sie zu beseitigen.

5Diskussion

5.1 Interpretation der Hypothesen

H1 wird gestützt: Der naive Prompt schützt den Geheim-Marker nicht. H2 wird gestützt: Der gehärtete Prompt senkt die Leak-Rate deutlich, beseitigt sie aber nicht; die Vektoren Übersetzung, Wiederholung und Format-Pivot bleiben wirksam. H3 wird gestützt: Der Prompt-Text ist unabhängig von der Härtung extrahierbar, und die gehärtete Variante gibt über den Format-Pivot gerade ihre Schutz-Regeln preis. Diese Befunde sind keine Neuheit; sie decken sich mit dem Stand der Literatur, der Prompt-Injection als ungelöst beschreibt. Der Beitrag liegt in der reproduzierbaren Messung in einem kontrollierten lokalen Aufbau.

5.2 Warum der Format-Pivot zuverlässig wirkt

Der Format-Pivot (Ausgabe als JSON oder Markdown-Liste) umgeht die Schutz-Regeln, weil das Modell die Anfrage nicht als Angriff, sondern als legitime Formatierungs-Aufgabe interpretiert. Die Schutz-Regeln sind auf erkennbare Angriffs-Muster kalibriert, etwa auf Rollen-Overrides oder direkte Nachfragen. Eine Bitte um Format-Umwandlung passt in keines dieser Muster und passiert deshalb die Regel-Schwelle. Die resultierende JSON-Antwort enthält zudem keine Ablehnungs-Spur, was die Erkennung durch nachgelagerte Prüfungen erschwert.

5.3 Warum der gehärtete Prompt seine eigene Schwäche enthält

Ein gehärteter System-Prompt beschreibt in seinem Text explizit, was geschützt werden soll und mit welchen Regeln. Damit liegt das Schutzobjekt und seine Beschreibung im selben Kontext, den das Modell wiedergeben kann. Je ausführlicher die Härtung formuliert ist, desto mehr Struktur steht für eine Extraktion bereit. Härtung durch Prompt-Engineering verschiebt die Grenze, an der ein Leck auftritt, aber sie verändert nicht die grundlegende Eigenschaft, dass Kontext ausgebbar ist. Zwei aufeinanderfolgende Prüfschritte mit demselben Modell bilden zudem keine unabhängigen Schichten, da sie dieselbe Schwäche teilen.

5.4 Konsequenz für die Architektur

Aus beiden Risiko-Klassen folgt dieselbe Konsequenz. Ein System-Prompt ist keine verlässliche Sicherheitsgrenze, weder für ein Geheimnis in seinem Inneren noch für seinen eigenen Text. Geheimnisse gehören deshalb nicht in den Kontext eines Sprachmodells. Verlässlicher Schutz entsteht durch deterministische Mechanismen außerhalb des Modells: durch Ausgabefilter und Guardrails, die die Antwort vor dem Versand auf bekannte Muster prüfen, sowie durch Tool-Aufrufe mit vorgeschalteter Autorisierung, sodass sensible Daten erst nach einer Rechteprüfung in eine Antwort gelangen. Der System-Prompt bleibt sinnvoll zur Steuerung von Ton und Verhalten, nicht als Datenträger.

5.5 Limitationen

• Kleine Stichprobe. Die Matrizen umfassen 8 bzw. 5 Probe-Klassen. Die Prozentangaben sind deshalb stets mit ihrer Rohzählung zu lesen (7 von 8, 3 von 8, 5 von 5, 3 von 5). Die Ergebnisse belegen einen Effekt, keine belastbare Quote.
• Konstruierte Probes. Die Probe-Klassen wurden vom Autor formuliert und sind nicht repräsentativ für die volle Bandbreite realer Angriffe.
• Kleines Modell. Getestet wurde ein Modell mit 3 Mrd. Parametern. Ein stärkeres Modell könnte einzelne Vektoren abfangen; an der grundsätzlichen Ausgebbarkeit des Kontexts ändert das nichts.
• Gekoppelte Variablen. Der naive und der gehärtete Prompt unterschieden sich nicht nur im Prompt-Text, sondern auch in der Sampling-Temperatur (0.7 gegenüber 0.3). Die gemessene Leak-Reduktion ist damit dem Prompt und der Temperatur gemeinsam zuzuschreiben, nicht isoliert der Härtung. Eine saubere Trennung erfordert einen Kontrolllauf des naiven Prompts bei gleicher Temperatur.
• Einzelmessung. Die manuellen Probe-Klassen wurden je einmal ausgeführt; für sie liegen keine Wiederholungsläufe vor. Die Modell-Ausgabe ist stochastisch, weshalb diese Einzelbefunde Existenznachweise sind, keine Häufigkeitsnachweise. Der automatisierte garak-Durchlauf bildet die Ausnahme, da er pro Probe mehrere Versuche ausführt.

6Fazit

Die Messung bestätigt in einem kontrollierten lokalen Aufbau, was die Fachliteratur beschreibt: Ein System-Prompt schützt weder ein in ihm eingebettetes Geheimnis noch seinen eigenen Text. Härtung durch Prompt-Engineering senkt die Leak-Rate, beseitigt das Leck aber nicht, und der Format-Pivot bleibt in beiden Risiko-Klassen wirksam. Die praktische Schlussfolgerung ist eindeutig: Der System-Prompt ist keine Sicherheitsgrenze. Wer Vertraulichkeit braucht, muss sie auf einer deterministischen Ebene außerhalb des Modell-Kontexts durchsetzen, etwa durch Ausgabefilter und autorisierte Tool-Aufrufe. Prompt-Engineering kann diese Ebene ergänzen, aber nicht ersetzen.

7Literatur

1. OWASP Foundation: OWASP Top 10 for Large Language Model Applications, Einträge LLM01 (Prompt Injection) und LLM07 (System Prompt Leakage). Online unter genai.owasp.org. ↩
2. Willison, S.: Artikelserie zu Prompt Injection, u. a. „Prompt injection: what's the worst that can happen?". Online unter simonwillison.net. ↩
3. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems, führt Prompt-Injection und die gezielte Extraktion von System-Prompts als adversariale Techniken. Online unter atlas.mitre.org. ↩

Alle Online-Quellen zuletzt geprüft am 12.07.2026. Alle Messungen stammen aus einer isolierten Laborumgebung ohne echte Kundendaten. Der geprüfte Chatbot ist ein selbst aufgesetztes Testsystem; die Befunde beschreiben eine allgemeine Eigenschaft von Sprachmodellen, keinen Fehler eines bestimmten Produkts.