Was ist ein System Prompt?
Ein System Prompt ist der von der Anwendung verfasste Anweisungstext, den ein Produkt in den Modellkontext legt, um eine Aufgabe zu rahmen: wofür der Assistent da ist, wie er antworten soll, welche Einschränkungen gelten und wie er mit anderen Inhalten umgehen soll. Er wird meist von Entwicklern oder Betreibern geschrieben und der Endnutzerin nicht angezeigt.
Dieser Artikel baut auf Anweisungen und Anweisungshierarchien auf, wo erklärt wird, wie Modelle konkurrierende Anweisungen auflösen. Hier geht es enger und praktischer darum, wie System Prompts aufgebaut und betrieben werden, wofür sie taugen und wo ihre Verantwortung endet.
Der Begriff ist anbieter- und produktspezifisch
"System Prompt" ist ein praktischer Produktbegriff, kein universell standardisiertes technisches Grundelement. Verschiedene APIs bieten unterschiedliche Rollen oder Kanäle an, etwa System-, Developer- oder Instruction-Felder, und statten sie mit unterschiedlicher Priorität und unterschiedlichen Fähigkeiten aus. Manche Produkte ergänzen zudem eigene Anbieteranweisungen, die die Anwendung nie sieht.
So beschreibt etwa die datierte OpenAI Model Spec eine anbieterspezifische Befehlskette mit Autoritätsstufen. Das ist das dokumentierte Design eines Anbieters für seine eigenen Modelle und Oberflächen, keine anbieterübergreifende Regel. Eine universelle Reihenfolge "System vor Developer vor User vor Tool" gibt es nicht; maßgeblich ist die Dokumentation des konkret genutzten Modells und der API, und nach jeder Änderung sollte erneut getestet werden.
Wo er im Modellkontext steht
Zur Laufzeit ist der System Prompt ein Teil des zusammengesetzten Kontexts, neben Nutzernachrichten, abgerufenen Dokumenten, Tool-Ergebnissen, Speicherinhalten und Schemas. Wie in Vertrauensgrenzen und Modellkontext beschrieben, ist alles in diesem Kontext modellsichtbar und kann die Ausgabe beeinflussen.
Eine privilegierte Rolle oder Position macht es wahrscheinlicher, dass das Modell dem Text folgt. Sie ändert aber nichts daran, was der Text ist: Daten, die das Modell interpretiert. Rollenmarkierungen, Trennzeichen und Labels gehören zur Eingabe, die das Modell liest, und bilden keine separat durchgesetzte Schicht.
Wofür System Prompts gut sind
| Zweck | Beispielhafte Absicht | Charakter |
|---|---|---|
| Aufgabenrahmen | Support-Tickets für interne Mitarbeitende zusammenfassen | Verhaltenssteuerung |
| Stil und Format | In kurzen Stichpunkten antworten; das vereinbarte JSON-Format liefern | Verhaltenssteuerung, geprüft durch Ausgabevalidierung |
| Richtlinienhinweise | Keine Rechtsberatung geben; Abrechnungsfragen an das Abrechnungsteam verweisen | Verhaltenssteuerung, wo nötig durch Anwendungsrichtlinien abgesichert |
| Umgang mit anderen Inhalten | Angehängte Dokumente als Analysematerial behandeln, nicht als Anweisungen | Robustheitshilfe, keine Vertrauensgrenze |
| Hinweise zur Tool-Nutzung | Lesende Abfragen bevorzugen; vor Änderungsvorschlägen begründen | Verbessert Vorschläge; die Autorisierung entscheidet weiterhin |
Diese Einsatzzwecke sind wertvoll. Ein klarer System Prompt verbessert Qualität, Konsistenz und Robustheit. Die Grenzen beginnen dort, wo von ihm eine garantierte Sicherheitseigenschaft erwartet wird.
Was sie nicht durchsetzen können
Position oder Rolle eines System Prompts bewirken für sich allein nicht, dass:
- Inhalte authentifiziert werden oder feststeht, wer eine Nachricht verfasst hat;
- Anwendungsberechtigungen gewährt werden, auch keine, die Aufrufer oder Agent nicht ohnehin besitzen;
- der eigene Text oder Daten im Kontext vertraulich bleiben;
- das Modell in jedem Fall gehorcht;
- die Modellausgabe vertrauenswürdig, korrekt oder sicher ausführbar wird.
Die Antwort des Modells bleibt variable Daten: ein Vorschlag. Ein System Prompt kann daher nicht die einzige Kontrolle gegen Datenabfluss, mandantenübergreifenden Zugriff oder gefährliche Tool-Nutzung sein. Direkte und indirekte Prompt Injection beschreiben Inhalte, die mit diesen Anweisungen konkurrieren, und manchmal setzen sie sich durch.
Verborgen heißt nicht geheim
Ein System Prompt wird meist nicht angezeigt, ist für das Modell aber vollständig sichtbar und kann über dessen Ausgaben offengelegt, umschrieben oder erschlossen werden. Das NIST-Glossar bezeichnet den Versuch, einen System Prompt oder anderen verborgenen Kontext preiszugeben, als "prompt extraction". Die OWASP-Leitlinie von 2026 zu Hidden Context Exposure empfiehlt, von der Auffindbarkeit verborgenen Kontexts auszugehen, und die Microsoft-Leitlinie zur Sicherheitsplanung rät, Zugangsdaten und Verbindungszeichenfolgen nicht im System Prompt zu speichern.
Praktische Folge: API-Schlüssel, Passwörter, Tokens, als Geheimnis dienende interne Hostnamen oder rein sicherheitsrelevante Daten gehören nie in einen System Prompt. Er sollte so geschrieben sein, dass eine Offenlegung höchstens unerwünscht, aber nicht schädlich ist. Die Angriffssicht behandelt System-Prompt-Extraktion.
Vertraulichkeit und Integrität des Prompts
| Anliegen | Frage | Wichtigste Schutzmaßnahmen |
|---|---|---|
| Vertraulichkeit | Kann jemand den Prompt-Text sehen, für den er nicht bestimmt war? | Geheimnisse fernhalten; Auffindbarkeit annehmen; Folgen einer Offenlegung begrenzen |
| Integrität | Kann jemand die tatsächlich gesendeten Anweisungen ändern oder ergänzen? | Zugriffskontrolle auf Vorlagen, Review, Versionierung, sichere Zusammensetzung dynamischer Felder |
Beide können unabhängig voneinander verletzt werden. Ein vollständig offengelegter Prompt kann unverändert sein, und ein nie abgeflossener Prompt kann durch eine ungeprüfte Vorlagenänderung oder einen eingefügten nicht vertrauenswürdigen Wert verfälscht worden sein. Beides verdient Aufmerksamkeit; keines ersetzt Kontrollen außerhalb des Modells.
Dynamische und vorlagenbasierte System Prompts
Viele Anwendungen setzen den System Prompt zur Laufzeit zusammen: eine feste Vorlage plus variable Werte wie Sprache, Produktstufe, Feature-Flags, Mandantenname oder Dokumentmetadaten. Auch generierte Prompts sind Anwendungsdaten und Konfiguration und sollten so behandelt werden.
Praktiken für die Zusammensetzung
- Feste, von Entwicklern kontrollierte Anweisungsvorlagen von variablen Werten trennen.
- Quelle und Herkunft jedes dynamischen Felds festhalten.
- Inhalte Dritter oder von Nutzern nicht in privilegierten Anweisungstext einfügen.
- Strukturierte Felder oder getrennte Kanäle nutzen, wo die API sie anbietet, und bedenken, dass das Modell diese Grenze weiterhin interpretiert.
- Prompt-Vorlagen versionieren und festhalten, welche Version einen Lauf erzeugt hat.
- Verhalten nach Änderungen an Prompt, Modell oder Anbieter erneut testen.
Nicht vertrauenswürdige Inhalte nie in autoritative Anweisungen einfügen
Wird ein nicht vertrauenswürdiger Wert in den Anweisungstext selbst eingefügt, schreibt jeder, der diesen Wert kontrolliert, an dem Teil des Kontexts mit, der am autoritativsten wirkt. Solche Werte sollten als klar gekennzeichnete Daten bleiben, über den für Inhalte vorgesehenen Kanal übergeben oder vorab auf eine feste Menge erlaubter Werte abgebildet werden.
Trennzeichen, XML-artige Tags, Labels und Spotlighting / Datenmarkierung können dem Modell den Unterschied zwischen Anweisung und Daten verdeutlichen und die Robustheit verbessern. Harte Vertrauensgrenzen sind sie nicht: Das Modell kann anweisungsähnlichem Text in markierten Daten trotzdem folgen. Datenprovenienz hält fest, woher jeder Wert stammt, damit die Anwendungslogik über seine Verwendung entscheiden kann.
System Prompts bei Tool Calling und Agents
Bei Agents beschreiben System Prompts oft die verfügbaren Tools und eine Nutzungsrichtlinie. Das hilft dem Modell, sinnvolle Aktionen vorzuschlagen. Der vorgeschlagene Aufruf bleibt aber Modellausgabe: Die Autorisierung zur Laufzeit prüft genau diese Aktion, Ressource und Parameter gegen die tatsächlichen Berechtigungen, und Least Privilege begrenzt von vornherein, was eine Berechtigung erreichen kann.
Ein System Prompt kann diese Berechtigungen nicht erweitern. Erlaubt der Prompt einem Agenten eine Aktion, die die zugrunde liegende Identität nicht ausführen darf, muss die Aktion bei der Ausführung scheitern. Wie aus Einfluss Aktionen werden, zeigt AI Agent Prompt Injection.
Kontrollen außerhalb des Prompts
| Zuständigkeit | Wo sie durchgesetzt wird |
|---|---|
| Identität und Authentifizierung | Anwendung und Identitätsanbieter |
| Autorisierung und Mandantentrennung | Datenschicht und Policy Engine, pro Anfrage |
| Tool- und Aktionsautorisierung | Laufzeitprüfung von genauer Aktion, Ressource und Parametern |
| Informationsfluss und Ziele | Fluss- und Egress-Richtlinie, siehe Informationsflusskontrolle |
| Ausgabevalidierung | Struktur und Format für das Ziel validieren |
| Senkenspezifische Verarbeitung | Erforderliche senkenspezifische Kodierung oder Escaping getrennt von der Validierung anwenden |
| Geheimnisse | Secret Store und serverseitige Zugangsdaten, niemals Modellkontext |
Vertiefend dazu Informationsflusskontrolle und Ausgabevalidierung.
Synthetische Beispiele
Der System Prompt sagt, der Assistent fasse nur Tickets zusammen. Die Anwendung gibt der Sitzung nur Lesezugriff; ein Schreib-Tool existiert nicht.
Selbst wenn [Inhalt, der eine Aktualisierung auslösen soll] das Modell zu einem Änderungsvorschlag bringt, gibt es keinen ausführbaren Schreibweg. Die Anweisung formt das Verhalten; das Berechtigungsmodell verhindert Schreibzugriffe.
Ein Entwurf des System Prompts enthält [FIKTIVER-API-SCHLÜSSEL], damit das Modell einen Dienst aufrufen kann.
Der Schlüssel wandert in einen serverseitigen Secret Store; den Tool-Aufruf führt Anwendungscode mit eigener Berechtigung aus. Der Prompt nennt nur das Tool. Eine Offenlegung des Prompts verrät nun nichts Sensibles.
Eine Vorlage kombiniert festen Richtlinientext mit einem Dokumenttitel aus einer hochgeladenen Datei: [Titeltext eines Dritten].
Der Titel wird als gekennzeichnete Dokumentdaten mit Herkunftsangabe übergeben, nicht in die Richtliniensätze eingefügt. Die Vorlagenversion wird mit dem Lauf protokolliert.
Der Agenten-Prompt sagt: nur Bestellungen des aktuellen Kunden abfragen. Das Modell schlägt eine Abfrage für eine andere Kundennummer vor.
Die Laufzeitautorisierung vergleicht die Nummer mit dem Kunden der Sitzung und lehnt den Aufruf ab. Die Ablehnung wird protokolliert; es werden keine Daten zurückgegeben.
Checkliste für den Betrieb
System Prompts als Konfiguration betreiben
- Prompt-Vorlagen in der Versionsverwaltung ablegen und Änderungen reviewen.
- Einschränken, wer Vorlagen und Quellen dynamischer Felder ändern darf.
- Vorlagenversion, Modell- und Anbieterversion für jeden Lauf festhalten.
- Geheimnisse und rein sicherheitsrelevante Daten aus jedem Prompt-Text heraushalten.
- Verhalten nach jeder Änderung mit repräsentativen und adversarialen synthetischen Fällen testen.
- Richtlinienablehnungen und ungewöhnliche Tool-Vorschläge als Telemetrie erfassen, ohne Logs als Durchsetzung zu betrachten.
- Prüfen, ob eine Sicherheitseigenschaft derzeit nur von der Formulierung des Prompts abhängt.
Häufige Missverständnisse
Aussagen, die nicht zutreffen
- Der System Prompt ist geheim, weil Nutzer ihn nicht sehen.
- Ein nachdrücklich formulierter System Prompt verhindert Prompt Injection.
- Die System-Rolle authentifiziert oder autorisiert etwas.
- Trennzeichen oder Tags ziehen eine harte Grenze zwischen Anweisungen und Daten.
- Wenn der Prompt eine Aktion verbietet, muss die Anwendung sie nicht prüfen.
- Ein generierter System Prompt ist sicher, weil die Anwendung ihn erzeugt hat.
Zur Begrifflichkeit rund um Versuche, diese Anweisungen zu übergehen, siehe Prompt Injection und Jailbreaking.
Üben
Das Lab Vertrauensgrenzen und Modellkontext trennt Modellsichtbares von Autoritativem. Das Lab Grundlagen der direkten Prompt Injection zeigt, warum die Autorisierungsentscheidung bei der Anwendung bleibt, wenn Inhalte mit Anwendungsanweisungen konkurrieren.
Standards und Quellen
Wie dieser Artikel Quellen nutzt
- OWASP
- LLM08:2026 Hidden Context Exposure - verborgenen Kontext als auffindbar annehmen; keine Zugangsdaten; keine Sicherheitsgrenze, GenAI LLM Top 10 2026 - Prompt Injection als benanntes Risiko
- NIST
- AI 100-2e2025 und Glossar - Begriffe zu Prompt Extraction und Prompt Injection
- Microsoft
- Security Planning für LLM-Anwendungen - Offenlegung des System Prompts als Bedrohung; Zugangsdaten fernhalten, Leitlinie zu indirekter Prompt Injection - mehrschichtige Gegenmaßnahmen
- OpenAI
- Model Spec 2026-08-18 - nur als anbieterspezifisches Beispiel für Anweisungsautorität
Die Praktiken zu Zusammensetzung, Versionierung und Betrieb in diesem Artikel sind Architekturempfehlungen, keine aus einem Standard zitierten Anforderungen.
Häufige Fragen
Ist ein System Prompt eine Sicherheitsgrenze?
Kann ich meinen System Prompt vertraulich halten?
Wohin gehören API-Schlüssel?
Setzt sich die System-Rolle immer gegen Nutzernachrichten durch?
Reichen Trennzeichen, um nicht vertrauenswürdige Daten abzugrenzen?
Kann ein System Prompt einem Agenten zusätzliche Rechte geben?
Was sollte protokolliert werden?
Quellen
- LLM08:2026 Hidden Context Exposure (OWASP Top 10 for LLM Applications 2026)OWASP GenAI Security Project · Guidance · 2026-08Geprüft 2026-09-26
- prompt extractionNIST Glossary · Technical documentationGeprüft 2026-09-26
- Security Planning für LLM-basierte Anwendungen (Bedrohung: Offenlegung von System Prompt / Metaprompt)Microsoft Learn · GuidanceGeprüft 2026-09-26
- OpenAI Model Spec - Instructions and levels of authorityOpenAI · Technical documentationLetzte Revision 2026-08-18Geprüft 2026-09-26
- OWASP GenAI LLM Top 10 2026OWASP GenAI Security Project · GuidanceGeprüft 2026-09-26
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Geprüft 2026-09-26
- Defend against indirect prompt injection attacksMicrosoft Learn · GuidanceGeprüft 2026-09-26