Canary-Token
Ein Canary-Token ist eine absichtlich platzierte, eindeutige Kontrollmarke in einem System-Prompt oder anderen geschützten Modellkontext. Erscheint diese Marke in einer überwachten Modellausgabe, einem Tool-Argument oder einem Übertragungskanal, ist dies ein Indikator dafür, dass dieser Kontext einen unerwarteten Weg genommen hat.1
Einordnung
Der Begriff ist kein standardisiertes Protokollmerkmal, sondern ein Detektionsmuster aus der Sicherheitsüberwachung. Seine Stärke liegt in der Beobachtbarkeit: Ein Token kann den exakten Weg einer beliebigen Kontextinformation nicht erklären, aber es kann eine messbare Bedingung für Alarmierung, Abbruch und Untersuchung schaffen. Im Unterschied zu einem Guardrail entscheidet der Canary-Token nicht selbst über die Zulässigkeit einer Eingabe. Er liefert ein Signal, das ein Guardrail, ein Monitor oder ein Incident-Response-Prozess auswertet.
Die Aussagekraft ist eng begrenzt. Ein Treffer zeigt, dass genau diese Markierung in einem überwachten Sink angekommen ist; er beweist nicht, dass der gesamte System-Prompt offengelegt wurde. Umgekehrt beweist das Ausbleiben eines Treffers nicht, dass kein Kontext oder keine sensible Information abgeflossen ist. Paraphrasen, Teilabflüsse, alternative Repräsentationen und nicht überwachte Kanäle können unsichtbar bleiben. Deshalb müssen die Tokens ausreichend eindeutig sein, pro Anwendung oder Sitzung unterscheidbar bleiben und in allen relevanten Ausgabe- und Aktionspfaden geprüft werden. Eine Zuordnung zu Sitzung, Modellversion und Kontextquelle macht spätere Befunde erst für Incident Response und Regressionstests nutzbar.
Dokumentiertes Beispiel
AWS beschreibt Canary-Tokens als eindeutige Wörter oder Phrasen im System-Prompt, deren Vorkommen in einer Modellantwort auf ein System-Prompt-Leak hindeutet. Der Beitrag weist zugleich auf Fehlalarme bei zu allgemeinen Markierungen und auf mögliche Umgehungen über abgewandelte Darstellungen hin.1 Die wissenschaftliche Evaluation von Gakh und Bahsi verglich mehrere frühe Prompt-Injection-Detektoren und fand, dass die damals untersuchten Canary-Word-Implementierungen in Vigil und Rebuff Prompt-Leaks nicht wirksam erkannten.2 Das stützt eine vorsichtige Einordnung: Canary-Tokens sind Telemetrie, keine vollständige Leak-Prävention.
Bedeutung für die Abwehr
Sinnvoll eingesetzt unterstützen Canary-Tokens Red Teaming, Regressionstests und Betriebsüberwachung. Ein Treffer muss operativ verwertbar sein: Antwort oder Tool-Aufruf verwerfen, Ereignisdaten sichern, betroffene Kontexte abgrenzen und die Ursache prüfen. Die stärkste Maßnahme bleibt jedoch, keine wertvollen Geheimnisse oder Zugriffsentscheidungen im Modellkontext zu hinterlegen. OWASP warnt ausdrücklich davor, System-Prompts als Geheimnis oder Sicherheitskontrolle zu behandeln.3 So bleibt ein Canary-Treffer ein frühes Warnsignal statt der letzte Schutz vor Datenabfluss.
Quellen
- Manideep Konakandla, „Designing for the inevitable: System prompt leakage and mitigations in generative AI applications“, 08.07.2026, https://aws.amazon.com/blogs/security/designing-for-the-inevitable-system-prompt-leakage-and-mitigations-in-generative-ai-applications/ ↩
- Valerii Gakh und Hayretdin Bahsi, „Enhancing Security in LLM Applications: A Performance Evaluation of Early Detection Systems“, 23.06.2025, https://arxiv.org/html/2506.19109v1 ↩
- OWASP Foundation, „LLM08:2026 Hidden Context Exposure“, 3. August 2026, https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ ↩