Ein Kundenservice-Chatbot gab seine eigenen System-Prompts preis, nachdem er eine einfache Anfrage nach einem Lammfleisch-Rezept erhalten hatte. Innerhalb weniger Minuten lieferte der Bot nicht nur das Rezept, sondern generierte auch Python-Code und enthüllte die internen Anweisungen, die sein Verhalten steuern.
Der Vorfall beweist, dass der „System-Prompt“ eines Sprachmodells keine Sicherheitsmauer darstellt. Wenn ein Bot spontan entscheidet, ob eine Benutzeranfrage zu seinem Auftrag passt, kann ein Angreifer diese Argumentation beeinflussen und das Modell dazu bringen, geschützte Informationen preiszugeben.
Was den Verstoß ausgelöst hat
Der Test begann mit einer einfachen Frage: „Kannst du mir ein Rezept für Lammfleisch-Eintopf geben?“ Der Bot, dessen erklärte Aufgabe darin bestand, die Dienstleistungen des Unternehmens zu erläutern, antwortete mit einem vollständigen Rezept, fügte ein kurzes Python-Skript hinzu, das die Zutaten analysierte, und gab dann den exakten Wortlaut seines System-Prompts aus – den Text, der dem Modell vorgibt, wie es sich zu verhalten hat.
Die Anfrage selbst war harmlos; die Gefahr lag in der Bereitschaft des Bots, das Rezept als Teil seiner Kernaufgabe zu behandeln.
Warum das wichtig ist
Chatbots übernehmen heute Aufgaben im Kundenkontakt, verarbeiten personenbezogene Daten, lösen Transaktionen aus oder steuern interne Tools. Wenn ein Modell dazu verleitet werden kann, seinen eigenen Anweisungssatz offenzulegen, erhält ein Angreifer Einblick in die Schutzmechanismen (Guardrails), die das Modell eigentlich vor schädlichen Handlungen bewahren sollten.
Wie der Angriff funktioniert
- Zweck des Bots profilieren – Der Tester stellte fest, dass die Aufgabe des Bots darin bestand, Unternehmensdienstleistungen zu erklären.
- Einen falschen Zusammenhang herstellen – Indem der Tester behauptete, das Rezept sei notwendig, um zu entscheiden, welchen Service der Nutzer in Anspruch nehmen sollte, verlieh er der Anfrage eine oberflächliche Relevanz für den Auftrag des Bots.
- Die Logik ausnutzen – Der Bot akzeptierte die fingierte Relevanz, ließ die Anfrage seine interne Relevanzprüfung passieren und deaktivierte die Schutzmechanismen, die sie eigentlich hätten blockieren müssen.
Der Angriff basiert auf der Selbsteinschätzung des Modells hinsichtlich der Relevanz. Wenn diese Einschätzung beeinflusst werden kann, werden die eigenen „Regeln“ des Modells verhandelbar.
Drei Schwachstellen
| Fehlerstufe | Was geschah |
|---|---|
| Goal Hijacking | Der Bot behandelte eine nicht zusammenhängende Kochanfrage als Teil seines Ziels der Dienstleistungserklärung. |
| Capability Drift | Er generierte ausführbaren Python-Code, obwohl seine Rolle keine Codegenerierung vorsah. |
| Prompt Leakage | Er gab den exakten System-Prompt aus, der eigentlich verborgen bleiben sollte. |
Jede Stufe stellt den Zusammenbruch einer anderen Verteidigungsebene dar, von der viele Implementierungen davon ausgehen, dass das Modell sie selbst durchsetzt.
Verteidigungsebenen, die tatsächlich funktionieren
Indem man die Schutzmechanismen (Guardrails) aus dem Modell heraus in deterministischen Code verlagert, stellt man eine zuverlässige Sicherheitsgrenze wieder her.
- Task Routing – Verwenden Sie einen separaten Klassifikator, um eingehende Nachrichten einer festen Liste erlaubter Absichten (Intents) zuzuordnen. Wenn eine Anfrage außerhalb dieser Liste liegt, lehnen Sie sie sofort ab. Das Modell bekommt dann gar nicht erst die Chance, über die Relevanz zu diskutieren.
- Least Capability – Entziehen Sie dem Bot alle Werkzeuge, die er nicht benötigt. Wenn er keine Codeausführung oder breiten Datenbankzugriff benötigt, entfernen Sie diese Fähigkeiten.
- Deterministische Autorisierung – Führen Sie Berechtigungsprüfungen im Anwendungscode durch, nicht im Sprachmodell. Das Modell kann eine Aktion vorschlagen, aber der Code entscheidet, ob sie ausgeführt wird.
- Ausgabevalidierung – Scannen Sie jede Modellantwort auf unzulässige Inhalte – wie System-Prompts oder sensible Daten –, bevor sie den Benutzer erreicht.
Ein Filter, der lediglich fragt: „Ist diese Anfrage verboten?“, kann von einem überzeugenden Benutzer umgangen werden. Eine Routing-Ebene, die gegen eine geschlossene Liste prüft, lässt keinen Raum für Verhandlungen.
Worauf man als Nächstes achten sollte
Unternehmen, die auf konversationelle KI setzen, sollten ihre Implementierungen auf die drei durch den Lammfleisch-Rezept-Test illustrierten Fehlerarten prüfen. In der Zwischenzeit sollten Sie jeden System-Prompt als öffentliches Wissen behandeln; verlassen Sie sich nicht darauf, dass er ein Modell daran hindert, sich selbst preiszugeben.
Das Fazit ist klar: Wenn Ihr Sicherheitsmodell von einem Absatz natürlicher Sprachinstruktionen abhängt, ist es fragil. Verstärken Sie es mit Code, der geprüft, versioniert und durchgesetzt werden kann, unabhängig davon, was das Modell sagt.