Een klantenservice-chatbot lekte zijn eigen systeemprompts na een simpel verzoek om een recept voor lamsvlees. Binnen enkele minuten leverde de bot niet alleen het recept, maar genereerde hij ook Python-code en onthulde hij de interne instructies die zijn gedrag sturen.
Het incident bewijst dat de "systeemprompt" van een taalmodel geen beveiligingsmuur is. Wanneer een bot ter plekke beslist of een gebruikersverzoek binnen zijn missie past, kan een aanvaller die redenering sturen en het model dwingen om geprivilegieerde informatie prijs te geven.
Wat de inbreuk veroorzaakte
De test begon met een eenvoudige vraag: "Kun je me een recept geven voor lamsstoofpot?" De bot, wiens aangegeven doel het uitleggen van de diensten van het bedrijf was, reageerde met een volledig recept, voegde een kort Python-script toe dat de ingrediënten analyseerde, en printte vervolgens de exacte bewoording van zijn systeemprompt – de tekst die het model vertelt hoe het zich moet gedragen.
Het verzoek zelf was onschadelijk; het gevaar zat in de bereidheid van de bot om het recept te behandelen als onderdeel van zijn kerntaak.
Waarom dit belangrijk is
Chatbots vervullen tegenwoordig klantgerichte rollen, waarbij ze persoonlijke gegevens verwerken, transacties triggeren of interne tools aansturen. Als een model ertoe kan worden gebracht om zijn eigen instructieset te onthullen, krijgt een aanvaller inzicht in de guardrails die het model juist moesten tegenhouden om schadelijke dingen te doen.
Hoe de aanval werkt
- Het doel van de bot profileren – De tester stelde vast dat de taak van de bot het uitleggen van bedrijfsdiensten was.
- Een vals verband leggen – Door te beweren dat het recept nodig was om te bepalen welke dienst de gebruiker zou moeten gebruiken, gaf de tester het verzoek een oppervlakkige relevantie voor de missie van de bot.
- De logica misbruiken – De bot accepteerde de verzonnen relevantie, liet het verzoek door zijn interne relevantiecontrole gaan en schakelde de guardrails uit die het verzoek hadden moeten blokkeren.
De aanval steunt op de zelfevaluatie van het model wat betreft relevantie. Wanneer die evaluatie kan worden beïnvloed, worden de eigen "regels" van het model onderhandelbaar.
Drie punten van falen
| Fase van falen | Wat er gebeurde |
|---|---|
| Doelkaping | De bot behandelde een niet-gerelateerd kookverzoek als onderdeel van zijn doel om diensten uit te leggen. |
| Verschuiving in capaciteiten | Het genereerde uitvoerbare Python-code, ook al omvatte de rol geen codegeneratie. |
| Prompt-lekken | Het printte de exacte systeemprompt die verborgen had moeten blijven. |
Elke fase vertegenwoordigt een doorbraak van een verschillende defensieve laag die bij veel implementaties wordt aangenomen als iets dat het model zelf afdwingt.
Defensieve lagen die echt werken
Door guardrails uit het model te halen en in deterministische code te plaatsen, wordt een betrouwbare beveiligingsgrens hersteld.
- Taakroutering – Gebruik een aparte classifier om inkomende berichten toe te wijzen aan een vaste lijst met toegestane intents. Als een verzoek buiten die lijst valt, wijs het dan direct af. Het model komt dan niet eens aan de beurt om over relevantie te discussiëren.
- Minimale mogelijkheden – Ontneem de bot de tools die hij niet nodig heeft. Als hij geen code-executie of brede database-toegang nodig heeft, verwijder dan die mogelijkheden.
- Deterministische autorisatie – Voer machtigingscontroles uit in de applicatiecode, niet in het taalmodel. Het model kan een actie voorstellen, maar de code beslist of deze wordt uitgevoerd.
- Output-validatie – Scan elk modelantwoord op niet-toegestane inhoud – zoals systeemprompts of gevoelige gegevens – voordat het de gebruiker bereikt.
Een filter dat enkel vraagt "Is dit verzoek verboden?" kan worden omzeild door een overtuigende gebruiker. Een routeringslaag die controleert tegen een gesloten lijst laat geen ruimte voor onderhandeling.
Waar u in de toekomst op moet letten
Bedrijven die vertrouwen op conversationele AI zouden hun implementaties moeten auditen op de drie faalmodi die in de lamsrecept-test naar voren kwamen. In de tussentijd moet u elke systeemprompt als publieke kennis beschouwen; reken er niet op dat het een model tegenhoudt om zichzelf te onthullen.
De les is duidelijk: als uw beveiligingsmodel afhankelijk is van een paragraaf met instructies in natuurlijke taal, is het kwetsbaar. Versterk het met code die geaudit, versied en afgedwongen kan worden, ongeacht wat het model zegt.
