Hidden Context Exposure
- Eingabe / Prompt
- Ausgabe / Aktion
Ein Angreifer extrahiert, erschließt oder rekonstruiert verborgenen Kontext — den System Prompt, Entwickleranweisungen, abgerufene Richtlinientexte oder Tool-Schemata — und gewinnt dadurch neue Angriffsmöglichkeiten.
Was es ist
Verborgener Kontext ist alles, was eine Anwendung in das Kontextfenster des Modells legt und was der Nutzer nicht sehen soll, das Modell aber lesen kann: der System Prompt und Entwickleranweisungen, Richtlinientexte aus einer Wissensdatenbank oder einem Konfigurationsspeicher und die Schemata der Tools, die das Modell aufrufen kann. Die Ausgabe 2026 hat den früheren Eintrag System Prompt Leakage (LLM07:2025) umbenannt und auf all das ausgeweitet. Ihr Designprinzip: Davon ausgehen, dass verborgener Kontext auffindbar ist — seine Offenlegung darf also kaum oder gar keine direkte Auswirkung auf die Sicherheit haben.
Selten schadet der Wortlaut selbst. Der Schaden liegt darin, was er darüber verrät, wie die Sicherheit gebaut ist. Der Schweregrad hängt davon ab, was der Kontext enthält: informativ, wenn er keine Geheimnisse enthält und nichts absichert; mittel, wenn interne Regeln einem Angreifer spürbar helfen; hoch, wenn er Zugangsdaten enthält oder die Autorisierung von seiner Geheimhaltung abhängt; kritisch, wenn die Offenlegung bis zu Codeausführung oder umfassender Exfiltration führt. Außerdem verstärkt er benachbarte Risiken: Offengelegte Regeln schärfen Prompt Injection, eingebettete Zugangsdaten werden zur Offenlegung sensibler Informationen, offengelegte Tool-Schemata vergrößern die übermäßige Handlungsfreiheit.
In einem Multi-Agenten-System kodiert verborgener Kontext oft die Architektur selbst — welche Spezialisten-Agenten existieren, wie der Orchestrator jeden anspricht, welche Tools jeder hat. Wird er offengelegt, wird die Topologie sichtbar. Das reicht, um einen Spezialisten direkt anzusprechen und die Prüfungen auf Orchestrierungsebene zu überspringen, die die eigentliche Kontrolle waren.
Arten
- Sensible Funktionalität und Tool-Schemata
- Der Kontext verrät die Architektur, die verfügbaren Tools und ihre Parameter oder Zugangsdaten, die dort nie hätten stehen dürfen.
- Logik zur Verhaltenssteuerung
- Interne Entscheidungsregeln zeigen einem Angreifer, wie er knapp innerhalb ihrer Grenzen bleibt oder sie umgeht.
- Sicherheits- und Ablehnungsregeln
- Die Bedingungen und Ausnahmen hinter einer Ablehnung erlauben es einem Angreifer, Anfragen am Filter vorbei zu formulieren, statt ihn auszulösen.
- Berechtigungen und Rollen
- Eine Tool-Beschreibung, die angibt, welche Rolle das Tool aufrufen darf, lädt zu gezieltem Ausprobieren ein und zeigt auf ein Ziel für Rechteausweitung.
- Ausgabestruktur und Formatregeln
- Ein offengelegtes Ausgabeschema lässt einen Angreifer Antworten erzeugen, die dem erwarteten Format entsprechen, aber manipulierte Werte enthalten.
Angriffsszenarien
Ein Nutzer bringt einen Orchestrator-Agenten dazu, seine Routing-Anweisungen und Tool-Schemata aufzusagen. Dadurch wird sichtbar, welche Spezialisten-Agenten existieren und wie sich jeder direkt ansprechen lässt — vorbei an der vorgesehenen Routing-Logik.
Leck eingebetteter Zugangsdaten
Ein System Prompt enthält Zugangsdaten für ein Tool, das der Agent aufrufen kann. Sobald der Prompt durchsickert, verwendet der Angreifer diese Zugangsdaten direkt gegen das System hinter dem Tool.
Tool-Schemata als Aufklärung
Ein Angreifer entlockt dem System im Gespräch die Tool-Liste und die Parameterschemata. Keine Zugangsdaten sickern durch, keine Richtlinie wird umgangen — aber der Angreifer hat jetzt konkrete Ziele für Injektionen und für das Verketten nachgelagerter Aktionen.
Guardrail-Umgehung über geleakte Einschränkungen
Ein Angreifer extrahiert die Inhaltseinschränkungen eines System Prompts und gestaltet dann eine Prompt Injection, die genau diese nun bekannten Einschränkungen aushebelt.
Offenlegung der Orchestrator-Routing-Logik
Ein Nutzer bringt einen Orchestrator-Agenten dazu, seine Routing-Anweisungen aufzusagen. Dadurch wird sichtbar, welche Spezialisten-Agenten existieren und wie sich jeder direkt ansprechen lässt.
Abwehrmaßnahmen
- Sensible Daten aus verborgenem Kontext heraushalten
- Zugangsdaten, Geheimnisse und sicherheitskritische Konfiguration gemäß Least Privilege Agent in Systeme auslagern, die das Modell nicht liest — und davon ausgehen, dass alles im Kontext den Nutzer erreichen kann.
- Verhalten außerhalb des Modells durchsetzen
- Filterung und Geschäftsregeln in deterministischen externen Systemen umsetzen. Ein Modell per Fine-Tuning darauf zu trainieren, seinen Kontext zu schützen, gibt keine verlässliche Garantie, und eine Prompt Injection kann außer Kraft setzen, worum der Kontext lediglich bittet.
- Autorisierung unabhängig vom LLM durchsetzen
- Rechtetrennung und Grenzprüfungen in auditierbarem Code halten; wo Aufgaben unterschiedliche Zugriffe brauchen, sie auf separate Agenten aufteilen, die jeweils gemäß Least Privilege Agent und Permission-scoped Tools eingegrenzt sind.
- Die Ausgabe als Rückfallebene absichern
- Antworten mit Output Validation / Schema Enforcement auf offengelegten Kontext prüfen — als Rückfallebene, nicht als eigentliche Kontrolle.