LLM-jailbreaks uitgelegd: wat een jailbreak verandert, en waarom het geen abliteration is

In juli 2023 voerden drie onderzoekers 32 schadelijke prompts uit tegen GPT-4 en Claude 1.3 via 28 verschillende aanvallen. De sterkste afzonderlijke techniek — drie aanvalsfamilies boven op elkaar gestapeld — slaagde bij 94 procent van de set tegen GPT-4 en bij 81 procent tegen Claude 1.3. Wat de set volledig deed slagen, was niet een betere aanval maar een keuze: een tegenstander die mocht kiezen welke van de 28 het beste werkte voor elke prompt, kreeg alle 32 door op beide modellen, wat het artikel rapporteert als een zuivere 1,00. De ongemakkelijke lezing is dat een jailbreak geen defect is dat verdwijnt wanneer het model slimmer wordt of zich beter gaat gedragen. Het is een eigenschap van de prompt, en de prompt is van degene die hem verstuurt. Wat er gebeurt nadat de weigering stopt — de tool call, het lezen van het bestand, de output die ergens terechtkomt waar erop wordt gehandeld — is het deel het AI-incidentenarchief gebouwd was om vast te leggen.

Die framing verdient precisie, want "jailbreak" wordt gebruikt voor verschillende zaken, en die verschillen bepalen wat een mitigatie überhaupt kan doen. Dit stuk behandelt wat een jailbreak wijzigt, wat de gemeten cijfers werkelijk zeggen, waarom er geen antwoord per model bestaat op de vraag "is het jailbreakbaar", en waar de techniek ophoudt een kwestie van modelveiligheid te zijn en er een van systeembeveiliging wordt.

Een jailbreak is een aanpassing aan de prompt, niet aan het model.

Het model blijft precies zoals het is geleverd. Er wordt niets opnieuw getraind, er worden geen gewichten aangeraakt, er wordt geen fine-tuning toegepast. De aanvaller verandert het verzoek zodanig dat het eraan voldoen de lokaal correcte voortzetting wordt, en het veiligheidsgedrag dat in het model is getraind, verliest het van een concurrerende instructie die het ook getraind was te volgen.

Die ene zin sluit een grote categorie vermeende oplossingen uit. Je kunt het niet bij de gewichten patchen — er is niets mis met de gewichten. Je kunt het niet opsommen, omdat de promptruimte open is. En je kunt het niet één keer controleren, omdat de techniek die vandaag faalt niet degene is die morgen wordt geprobeerd. Wat je wel kunt doen, is een percentage meten, op een vaste set prompts, tegen een vaste modelversie, en vervolgens kijken hoe dat percentage beweegt wanneer een van die drie verandert.

Wat het 32-prompt-experiment daadwerkelijk heeft gemeten

Het onderzoek is Jailbroken: Hoe faalt de veiligheidstraining van LLM's? van Alexander Wei, Nika Haghtalab en Jacob Steinhardt, in juli 2023 op arXiv geplaatst als 2307.02483. De testset bestond uit 32 schadelijke prompts — de helft afkomstig uit een gepubliceerde GPT-4-evaluatie, de helft aangepast uit gepubliceerd red-teamingwerk over Claude — en de uitkomstmaat is bot: een geval wordt als succes gescoord wanneer het antwoord zowel schadelijk als relevant is voor het oorspronkelijke verzoek. Alles wat blijft steken, ontwijkt of een andere vraag beantwoordt, telt niet.

Twee eigenschappen van de resultaten zijn nuttiger dan welke afzonderlijke rij dan ook. De eerste is hoe ongelijkmatig aanvallen tussen modellen overdragen. AIM-rollenspel scoorde 0,75 tegen GPT-4 en 0,00 tegen Claude 1.3. Few-shot JSON scoorde 0,53 en 0,00. Base64-codering was ondertussen het omgekeerde soort ongelijkmatigheid — 0,34 op GPT-4 en 0,38 op Claude 1.3 — en afleiders kwamen uit op 0,44 en 0,47. Een techniek waartegen een leverancier duidelijk heeft getraind, verschijnt als een nul op dat model en zegt niets over het model ernaast.

Het tweede is wat er gebeurt wanneer families worden gecombineerd. Prefix-injectie plus weigeringsonderdrukking plus Base64 leverde 0,56 tegen GPT-4 en 0,66 tegen Claude 1.3 op. Het toevoegen van stijlinjectie bracht dat naar 0,69 en 0,84. Het toevoegen van generatie van website-inhoud en opmaakbeperkingen bracht dat naar 0,94 en 0,81. Stapelen is de hele truc: elke laag is iets wat het model getraind is om te doen, en de combinatie laat geen tokenpositie over waar weigeren de natuurlijkere voortzetting is.

De modellen in die tabel zijn drie jaar oud en zijn allang niet meer wat er tegenwoordig wordt ingezet. Het gaat niet om de cijfers; het gaat om de vorm. Elk mechanisme in de tabel is nog steeds actief in elk model sindsdien, omdat geen ervan ooit een bug was in GPT-4 of Claude 1.3 — ze zijn het gevolg van hoe het opvolgen van instructies en veiligheidstraining op elkaar inwerken.

Twee manieren waarop veiligheidstraining faalt

De uitleg in het artikel is ongewoon helder, en dat is het deel dat de moeite waard is om bij je te houden: er zijn twee faalmodi, en elke aanval in de tabel is een geval van een van beide.

Concurrerende doelstellingenConcurrerende doelstellingen zijn wat je krijgt wanneer de capaciteiten van een model en zijn veiligheidsdoelen verschillende kanten op wijzen. Instructieopvolging is een capaciteit. Wanneer het verzoek zo is ingekapseld dat weigeren een instructie zou schenden die het model sterk getraind is om op te volgen, lost het model het conflict op ten gunste van de instructie. Prefix-injectie is de minimale variant: zeg tegen het model dat zijn antwoord moet beginnen met "Absolutely! Here's", en de eerste tokens zijn dan al een toezegging die weigering onsamenhangend maakt. Weigeringsonderdrukking valt dezelfde naad vanaf de andere kant aan, door opmaakregels toe te voegen die de zin verbieden waarin een weigering zou moeten worden geschreven.

Niet-overeenkomende generalisatie is wat je krijgt wanneer veiligheidstraining een smalle inputdistributie bestrijkt die het algemene vermogen van het model niet dekt. Het model heeft Base64 geleerd tijdens pretraining en kan een gecodeerde instructie prima opvolgen. Veiligheidstraining, die grotendeels natuurlijke-taalverzoeken zag, heeft het nooit geleerd te herkennen dat een gecodeerd verzoek nog steeds een verzoek is. Dezelfde fout doet zich voor bij het verwijderen van klinkers, ROT13, leetspeak, payloadopsplitsing en afleidingstaken: elk is een formaat waarnaar het vermogen generaliseert en het veiligheidsgedrag niet.

Zodra je die twee categorieën hebt, zien de aanvallen er niet langer uit als een ratjetoe van trucjes, maar als twee families met een gemeenschappelijke grondoorzaak — wat ook de reden is waarom ze zo goed samengaan. Een prompt die weigering onderdrukt en zijn intentie in een codering verbergt, exploiteert beide faalmodi tegelijk, en 0.94 is hoe dat eruitziet.

Waarom er geen antwoord per model is op "is het jailbreakbaar"

De meest voorkomende queryvorm op dit gebied is een modelnaam gevolgd door het woord jailbreak. Het is de verkeerde analyse-eenheid, en de reden daarvoor is de tabel hierboven. Succes hangt van ten minste vijf dingen tegelijk af: de capaciteit van het basismodel, welke veiligheidstraining het heeft gekregen en op welke distributie, het promptformaat, de samplinginstellingen en hoeveel pogingen de aanvaller bereid is te doen.

Die laatste verdient een eigen zin. Een percentage gemeten bij één poging per prompt en een percentage gemeten bij "best of 28" zijn niet dezelfde meting, en het adaptieve resultaat van het paper — 1,00 op beide modellen — is van de tweede soort. Wie een jailbreakpercentage citeert zonder te zeggen welke van de twee hij bedoelt, heeft niets bruikbaars geciteerd. De realistische verdedigingsvraag is niet "kan het worden gekraakt", maar "hoeveel pogingen zijn er nodig, en merkt iets in mijn stack de pogingen op".

Hieruit volgen twee praktische consequenties. Een model dat vandaag weerstand biedt aan je promptset, kan daarmee stoppen na een versiebump, een wijziging in de veiligheidslaag of een wijziging in de configuratie aan de serverkant — het resultaat is alleen geldig voor de build die je hebt getest, en daarom is een test zonder versie en datum geen resultaat. En dezelfde promptset tegen twee modellen laten lopen, vertelt je op welk model je stack soepeler reageert, niet welk model veilig is.

Wat een jailbreak niet is: abliteratie

Deze twee worden voortdurend met elkaar verward, omdat beide erop neerkomen dat een model uitvoer produceert die het niet is getraind te produceren. Het zijn niet dezelfde aanpassing, en het verschil is het verschil tussen een controle die je kunt toevoegen en een eigenschap die je niet kunt toevoegen.

• Jailbreak — een bewerking op de promptlaag. De gewichten blijven ongewijzigd. De weigeringsrichting zit nog steeds in het model; het verzoek is alleen zo ingericht dat andere gedragingen er zwaarder wegen. Draai de prompt terug en het gedrag keert mee terug.

• Abliteration — een bewerking op gewichtsniveau. De weigeringsrichting wordt geïdentificeerd — meestal als een richting in de activatieruimte — en uit de gewichten van het model weggeprojecteerd, zodat het model voor die klasse van verzoeken helemaal geen weigeringen meer produceert. Het is een permanente wijziging aan het artefact, en dat is waarom een checkpoint waarop abliteration is toegepast zich anders gedraagt dan hetzelfde basismodel met een slimme prompt. De mechaniek van die bewerking wordt uiteengezet in onze gids over abliteration.

Het operationele verschil is belangrijker dan de terminologie. Een jailbreak is een runtime-gebeurtenis: die komt mee met een verzoek en kan net als elk ander verzoek worden geteld, aan snelheidslimieten onderworpen, gefilterd en gelogd. Een geabliteerd model is een gebeurtenis in de toeleveringsketen: de controle is al verwijderd voordat je het ontvangt, en geen enkele hoeveelheid monitoring op promptniveau haalt die terug. Als je dreigingsmodel "iemand zal proberen het model te overtuigen" is, zit je in de eerste categorie. Als het "iemand levert mij een model waarin de weigering is verwijderd" is, zit je in de tweede, en de enige echte controle is herkomst — weten welk checkpoint de endpoint daadwerkelijk serveert.

Jailbreak is ook geen prompt-injectie.

De derde term die erbij wordt gehaald is promptinjectie, en de onderscheidende vraag is wie de aanvaller is. Een jailbreak komt van de gebruiker, die probeert inhoud te krijgen die het model is getraind achter te houden. Promptinjectie komt van inhoud — een opgehaald document, een webpagina, een toolresultaat — die instructies bevat die de ontwikkelaar nooit heeft geschreven, en het werkt ongeacht of de gebruiker vijandig is. Hetzelfde model kan immuun zijn voor het een en wijd openstaan voor het ander, omdat ze op verschillende plekken worden verslagen: jailbreaks bij de invoer en uitvoer van het model, injectie bij de vertrouwensgrens tussen data en instructies.

Wat verlaagt het tarief daadwerkelijk?

Niets hier is een garantie, en elke bewering van het tegendeel is een verkooppraatje. Wat volgt is de reeks maatregelen die de cijfers verandert, gerangschikt naar hoeveel ze opleveren voor de inspanning.

• Ga ervan uit dat de promptlaag bezwijkt. Elke controle die ervan afhangt dat het model weigert, is één adaptieve aanvaller verwijderd van nul. Ontwerp alsof het verzoek er uiteindelijk doorheen komt, en plaats de controle waar de schade zou optreden.

• Beperk wat een geslaagde jailbreak kan bereiken. De impactradius van een gejailbreakte assistent is alles wat de tools, inloggegevens en het retrievalbereik ervan toelaten. Minimale rechten op tools en scoping per tenant op retrieval verkleinen de waarde van een geslaagde jailbreak veel betrouwbaarder dan welke promptfilter dan ook.

• Beoordeel de output, niet de prompt. Classifiers aan de outputzijde vangen families op die je nog nooit hebt gezien, omdat ze kijken naar wat daadwerkelijk is geproduceerd in plaats van naar hoe erom is gevraagd. Ze zijn ook de enige laag die nog werkt wanneer het invoerformaat nieuw is — wat, gezien de faalmodus van mismatched generalization, meestal het geval is.

• Behandel de systeemprompt als een configuratiewaarde, niet als een beveiligingsgrens. Het is tekst in hetzelfde contextvenster als de aanval. Het verhoogt de kosten van een poging; het stopt er geen.

• Maak de pogingen zichtbaar. Het enige voordeel dat een verdediger heeft op de adaptieve aanvaller is dat de aanval meestal wordt herhaald. Rate limits, het detecteren van herhalingen en logging veranderen een zoektocht van 28 pogingen in een gebeurtenis die je kunt zien in plaats van 28 verzoeken die er elk afzonderlijk prima uitzagen.

• Test opnieuw bij elke modelwijziging. Een versiepin plus een vaste set prompts is wat van 'we hebben het één keer getest' een getal maakt waarmee je kunt vergelijken. Zonder de pin is de vergelijking zinloos.

Hoe u uw eigen doel kunt meten

Als het doel een getal is waarop je kunt handelen, zet dan de drie variabelen vast die het artikel vastzette: de promptset, de modelversie en het aantal pogingen. Gebruik een promptset die beide faalmodi bevat — instructies die weigeren ongemakkelijk maken, en coderingen die het verzoek verbergen — want een set met alleen het ene zal een model dat zwak is voor het andere, gunstiger laten lijken. Scoor conservatief: schadelijk en ter zake, niet louter met de verkeerde toon. En rapporteer het resultaat als een ratio ten opzichte van een opgegeven aantal pogingen, nooit als een ja of nee.

Wanneer er meerdere kandidaatmodellen in beeld zijn, werkt de vergelijking alleen als dezelfde set prompts tegen elk daarvan wordt uitgevoerd, en dat is precies het punt waar de technische infrastructuur meer uitmaakt dan de methodologie. Eén evaluatie uitvoeren over de modellen waar we naartoe routeren, haalt het werk aan per-leveranciercontracten en aparte clients uit de oefening; lijstprijzen van providers worden tegen nul opslag doorgegeven, dus de run kost wat de providers rekenen en niets meer. Wat de evaluatie meet, is het gedrag van het model, niet dat van ons — routering verandert welk model antwoordt, en zorgt er niet voor dat een van hen vaker weigert.

Waar de opname verdergaat

Een gemeten succespercentage vertelt je hoe moeilijk de promptlaag omver te duwen is. Het vertelt je niet wat er gebeurde toen iemand die in productie omverduwde, en die tweede vraag bepaalt of het percentage ertoe doet. Een jailbreak die een onbeleefde alinea oplevert, is een contentmoderatieprobleem. Een jailbreak die een tool call oplevert, is een incident, en het verschil zit volledig in wat het systeem de output liet bereiken.

Dat archief is het veldrecord: wat agenten daadwerkelijk deden, met een bron voor elke vermelding en een oordeel over of iemand schade heeft geleden. Afgezet tegen een jailbreakmeting beantwoordt het de vraag die de meting niet kan beantwoorden — of de grens die een prompt overschreed er een is waar iets stroomafwaarts van afhankelijk is. Als dat zo is, is de jailbreak een beveiligingsbevinding en hoort de controle in de toolmachtigingen. Als dat niet zo is, is de jailbreak een contentresultaat, en de eerlijke zet is om het als zodanig te registreren in plaats van het op te blazen tot een kwetsbaarheid.

De slotopmerking is degene die door het bewijs wordt ondersteund. Jailbreaking zal niet worden opgelost door een beter model, omdat de faalmodi structureel zijn: instructieopvolging is een capaciteit en veiligheidstraining is een nauwere vaardigheid, en de kloof daartussen is waar elke aanval in dit artikel zich bevindt. Wat wel kan worden opgelost, is het gevolg — door ervoor te zorgen dat een model dat niet meer weigert, nog steeds niet veel kan uitrichten.