LLM-jailbreaks förklarade: Vad ett jailbreak förändrar, och varför det inte är abliteration

I juli 2023 körde tre forskare 32 skadliga promptar mot GPT-4 och Claude 1.3 genom 28 olika attacker. Den starkaste enskilda tekniken – tre attackfamiljer staplade på varandra – tog sig igenom 94 procent av uppsättningen mot GPT-4 och 81 procent mot Claude 1.3. Det som fick hela uppsättningen att falla var inte en bättre attack utan ett val: en motståndare som fick välja vilken av de 28 som fungerade bäst för varje prompt fick igenom alla 32 på båda modellerna, vilket artikeln rapporterar som ett rent 1,00. Den obekväma tolkningen är att en jailbreak inte är en defekt som försvinner när modellen blir smartare eller sköter sig bättre. Det är en egenskap hos prompten, och prompten tillhör den som skickar den. Det som händer efter att vägran upphör – verktygsanropet, filläsningen, utdata som landar någonstans där något agerar på den – är den del som AI incident archive byggdes för att registrera.

Den inramningen är värd att vara precis kring, eftersom "jailbreak" används för flera olika saker och skillnaderna avgör vad en åtgärd ens kan göra. Den här artikeln tar upp vad ett jailbreak redigerar, vad de uppmätta siffrorna faktiskt säger, varför det inte finns något svar per modell på "går den att jailbreaka", och var tekniken slutar vara en fråga om modellsäkerhet och blir en fråga om systemsäkerhet.

En jailbreak är en ändring av prompten, inte av modellen.

Modellen förblir exakt som den levererades. Inget tränas om, inga vikter rörs, ingen finjustering tillämpas. Angriparen ändrar begäran så att det blir den lokalt korrekta fortsättningen att följa den, och det säkerhetsbeteende som tränats in i modellen förlorar mot en konkurrerande instruktion som den också tränats att följa.

Den där enda meningen utesluter en stor kategori av påstådda lösningar. Du kan inte rätta det vid vikterna – det är inget fel på vikterna. Du kan inte räkna upp det, eftersom promptrymden är öppen. Och du kan inte kontrollera det en gång, eftersom tekniken som misslyckas i dag inte är den som kommer att prövas i morgon. Det du kan göra är att mäta en frekvens, på en fast uppsättning prompter, mot en fast modellversion, och sedan se hur den frekvensen förändras när någon av dessa tre ändras.

Vad experimentet med 32 promptar faktiskt mätte

Studien är Jailbroken: Hur misslyckas LLM-säkerhetsträning? av Alexander Wei, Nika Haghtalab och Jacob Steinhardt, publicerad på arXiv i juli 2023 som 2307.02483. Dess testuppsättning bestod av 32 skadliga promptar – hälften hämtade från en publicerad GPT-4-utvärdering, hälften anpassade från publicerat red-teaming-arbete om Claude – och dess utfallsmått är trubbigt: ett fall bedöms som lyckat när svaret både är skadligt och ämnesrelevant för den ursprungliga förfrågan. Allt som stannar upp, avleder eller svarar på en annan fråga räknas inte.

Två egenskaper hos resultaten är mer användbara än någon enskild rad. Den första är hur ojämnt attacker överförs mellan modeller. AIM-rollspel fick 0,75 mot GPT-4 och 0,00 mot Claude 1.3. Few-shot JSON fick 0,53 och 0,00. Samtidigt var Base64-kodning den omvända typen av ojämnhet – 0,34 på GPT-4 och 0,38 på Claude 1.3 – och distraktorerna landade på 0,44 och 0,47. En teknik som en leverantör uppenbart har tränat emot visar noll på den modellen och säger ingenting om modellen intill.

Det andra är vad som händer när familjer kombineras. Prefixinjektion plus undertryckande av vägran plus Base64 gav 0,56 mot GPT-4 och 0,66 mot Claude 1.3. Att lägga till stil-injektion tog det till 0,69 och 0,84. Att lägga till generering av webbplatsinnehåll och formateringsbegränsningar tog det till 0,94 och 0,81. Stapling är hela tricket: varje lager är något modellen tränats att göra, och kombinationen lämnar ingen tokenposition där att vägra är den mer naturliga fortsättningen.

Modellerna i den tabellen är tre år gamla och inte längre vad någon använder i drift. Siffrorna är inte poängen; formen är det. Varje mekanism i tabellen är fortfarande aktiv i varje modell sedan dess, eftersom ingen av dem någonsin var en bugg i GPT-4 eller Claude 1.3 – de är konsekvenser av hur instruktionsföljning och säkerhetsträning samverkar.

Två sätt som säkerhetsutbildning misslyckas

Artikelns förklaring är ovanligt tydlig, och det är den del som är värd att bära med sig: det finns två felmoder, och varje attack i tabellen är ett exempel på en av dem.

Konkurrerande mål är vad man får när en modells förmågor och dess säkerhetsmål pekar i olika riktningar. Instruktionsföljning är en förmåga. När förfrågan är inramad så att ett avslag skulle bryta mot en instruktion som modellen är starkt tränad att följa, löser modellen konflikten till förmån för instruktionen. Prefixinjektion är den minimala varianten: säg till modellen att dess svar måste börja med "Absolutely! Here's", och de första tokens är redan ett åtagande som gör ett avslag osammanhängande. Undertryckning av avslag attackerar samma skarv från andra sidan, genom att lägga till formateringsregler som förbjuder den mening som ett avslag skulle behöva formuleras i.

Missmatchad generalisering är vad man får när säkerhetsträningen täcker en snäv indatafördelning som modellens allmänna förmåga inte gör. Modellen lärde sig Base64 under förträningen och kan följa en kodad instruktion alldeles utmärkt. Säkerhetsträningen, som mestadels såg förfrågningar i naturligt språk, lärde den aldrig att känna igen att en kodad förfrågan fortfarande är en förfrågan. Samma fel uppträder med vokalborttagning, ROT13, leetspeak, uppdelning av nyttolast och distraktionsuppgifter: var och en är ett format som förmågan generaliserar till men som säkerhetsbeteendet inte gör.

När du väl har de två kategorierna slutar attackerna se ut som en salig blandning av trick och börjar se ut som två familjer med en gemensam grundorsak – vilket också är anledningen till att de kombineras så väl. En prompt som undertrycker vägran och döljer sin avsikt i en kodning utnyttjar båda fellägena samtidigt, och 0.94 är hur det ser ut.

Varför det inte finns något svar per modell på frågan "går det att jailbreaka"

Den vanligaste frågeformen i detta område är ett modellnamn följt av ordet jailbreak. Det är fel analysenhet, och anledningen är tabellen ovan. Framgång beror på minst fem saker samtidigt: basmodellens förmåga, vilken säkerhetsträning den fick och på vilken distribution, promptformatet, samplingsinställningarna och hur många försök angriparen är villig att lägga.

Det där sista förtjänar en egen mening. En frekvens uppmätt med ett försök per prompt och en frekvens uppmätt som ”bäst av 28” är inte samma mätning, och artikelns adaptiva resultat – 1,00 på båda modellerna – är av det andra slaget. Den som citerar en jailbreak-frekvens utan att säga vilken de menar har inte citerat något användbart. Den realistiska försvarsfrågan är inte ”kan det knäckas” utan ”hur många försök krävs det, och upptäcker något i min stack försöken”.

Två praktiska konsekvenser följer. En modell som motstår din promptuppsättning i dag kan sluta motstå efter en versionsuppdatering, en ändring av säkerhetslagret eller en konfigurationsändring på serveringssidan – resultatet gäller bara för den build du testade, vilket är anledningen till att ett test utan version och datum inte är ett resultat. Och samma promptuppsättning körd mot två modeller säger dig vilken din stack är mjukare mot, inte vilken som är säker.

Vad ett jailbreak inte är: abliteration

Dessa två förväxlas ständigt eftersom båda slutar med att en modell producerar utdata som den har tränats att inte producera. De är inte samma ändring, och skillnaden är skillnaden mellan en kontroll du kan lägga till och en egenskap du inte kan.

• Jailbreak — en redigering i promptlagret. Vikterna är oförändrade. Vägransriktningen finns fortfarande i modellen; begäran har helt enkelt arrangerats så att andra beteenden prioriteras framför den. Återställ prompten, så återställs beteendet med den.

• Abliteration — en redigering av viktlagret. Vägransriktningen identifieras – vanligtvis som en riktning i aktiveringsrymden – och projiceras bort från modellens vikter, så att modellen inte längre producerar några vägran för den typen av begäran över huvud taget. Det är en permanent ändring av artefakten, och det är därför en abliterad checkpoint beter sig annorlunda än samma basmodell med en smart prompt. Mekaniken bakom den redigeringen beskrivs i vår guide till abliteration.

Den operativa skillnaden spelar större roll än terminologin. En jailbreak är en händelse vid körning: den kommer med en begäran och kan räknas, hastighetsbegränsas, filtreras och loggas som vilken annan begäran som helst. En abliterad modell är en händelse i leveranskedjan: kontrollen har redan tagits bort innan du får den, och ingen övervakning på promptnivå får tillbaka den. Om din hotmodell är "någon kommer att försöka övertala modellen" tillhör du den första kategorin. Om den är "någon kommer att leverera en modell till mig med vägran borttagen" tillhör du den andra, och den enda verkliga kontrollen är härkomst — att veta vilken checkpoint som endpointen faktiskt serverar.

Jailbreak är inte heller prompt injection

Den tredje termen som blandas in är prompt injection, och den avgörande frågan är vem angriparen är. En jailbreak kommer från användaren, som försöker få fram innehåll som modellen tränats att undanhålla. Prompt injection kommer från innehåll – ett hämtat dokument, en webbsida, ett verktygsresultat – som innehåller instruktioner som utvecklaren aldrig skrev, och det fungerar oavsett om användaren är fientlig eller inte. Samma modell kan vara immun mot det ena och vidöppen för det andra, eftersom de motverkas på olika ställen: jailbreaks vid modellens indata och utdata, injection vid förtroendegränsen mellan data och instruktioner.

Vad är det som faktiskt minskar frekvensen?

Inget här är en garanti, och påståenden om motsatsen är säljsnack. Det som följer är uppsättningen kontroller som förändrar siffrorna, sorterade efter hur mycket de ger för insatsen.

• Anta att promptlagret faller.Varje kontroll som bygger på att modellen vägrar är bara en adaptiv angripare från noll. Designa som om förfrågan till slut kommer att gå igenom, och placera kontrollen där skadan skulle inträffa.

• Begränsa vad ett lyckat jailbreak kan nå. Skadeomfånget för en jailbreakad assistent är allt som dess verktyg, autentiseringsuppgifter och hämtningsomfång tillåter. Minsta behörighet för verktyg och per-tenant-avgränsning vid hämtning minskar värdet av ett lyckat jailbreak mycket mer tillförlitligt än något promptfilter.

• Bedöm utdata, inte prompten. Klassificerare på utdatasidan fångar familjer som du aldrig har sett, eftersom de tittar på vad som faktiskt producerades i stället för på hur det efterfrågades. De är också det enda lager som fortfarande fungerar när indataformatet är nytt — vilket, enligt felläget med missmatchad generalisering, är större delen av tiden.

• Behandla systemprompten som ett konfigurationsvärde, inte som en säkerhetsgräns. Den är text i samma kontextfönster som attacken. Den höjer kostnaden för ett försök; den stoppar inte ett.

• Gör försöken synliga. Den enda fördel en försvarare har över den adaptiva angriparen är att attacken vanligtvis upprepas. Frekvensbegränsningar, upprepningsdetektering och loggning förvandlar en sökning på 28 försök till en händelse du kan se i stället för 28 förfrågningar som var och en såg bra ut på egen hand.

• Testa igen vid varje modellbyte. Ett versionslås plus en fast uppsättning prompts är det som förvandlar "vi testade det en gång" till en siffra du kan jämföra med. Utan versionslåset blir jämförelsen meningslös.

Så mäter du ditt eget mål

Om målet är en siffra du kan agera på, lås de tre variablerna som artikeln låste: promptuppsättningen, modellversionen och antalet försök. Använd en promptuppsättning som omfattar båda fellägena – instruktioner som gör det besvärligt att vägra, och kodningar som döljer begäran – eftersom en uppsättning som bara består av det ena kommer att smickra en modell som är svag för det andra. Poängsätt konservativt: skadliga och ämnesrelevanta, inte bara fel i tonen. Och rapportera resultatet som en frekvens mot ett angivet antal försök, aldrig som ett ja eller nej.

När flera kandidatmodeller är aktuella fungerar jämförelsen bara om samma promptuppsättning körs mot var och en av dem, och det är den enda platsen där infrastrukturen är viktigare än metodiken. Att köra en utvärdering över de modeller vi dirigerar tar bort leverantörsspecifika avtal och klientarbete från övningen; leverantörernas listpriser går igenom utan påslag, så körningen kostar vad leverantörerna tar och inget mer. Det utvärderingen mäter är modellens beteende, inte vårt — dirigeringen ändrar vilken modell som svarar, och den får inte någon av dem att vägra mer.

Där skivan tar vid

En uppmätt framgångsgrad säger hur svårt det är att knuffa omkull promptlagret. Den säger inte vad som hände när någon knuffade omkull det i produktion, och det är den andra frågan som avgör om graden spelar någon roll. En jailbreak som producerar ett oförskämt stycke är ett innehållsmodereringsproblem. En jailbreak som producerar ett verktygsanrop är en incident, och skillnaden ligger helt i vad systemet lät utdata nå.

Det arkivet är fältprotokollet: vad agenter faktiskt gjorde, med en källa för varje post och en bedömning av om någon skadades. Läst mot en jailbreak-mätning besvarar det frågan som mätningen inte kan – om gränsen som en prompt korsade är en som något nedströms är beroende av. Om den är det är jailbreaken en säkerhetsfynd och kontrollen hör hemma i verktygsbehörigheterna. Om den inte är det är jailbreaken ett innehållsresultat, och det ärliga draget är att registrera det som ett sådant i stället för att blåsa upp det till en sårbarhet.

Slutkommentaren är den som bevisen stöder. Jailbreaking kommer inte att lösas av en bättre modell, eftersom fellägena är strukturella: instruktionsföljning är en förmåga och säkerhetsträning är en snävare sådan, och gapet mellan dem är där varje attack i den här artikeln lever. Det som kan lösas är konsekvensen – genom att se till att en modell som slutar vägra fortfarande inte kan göra särskilt mycket.