Misbruik van logit bias
Hoe de logit-bias-parameters van API's misbruikt kunnen worden om de generatie van specifieke tokens af te dwingen, veiligheids-alignment te omzeilen, weigeringstokens te onderdrukken en modelgedrag te extraheren via systematische probing.
Overzicht
De meeste LLM-API-providers stellen een logit_bias-parameter beschikbaar waarmee aanroepers de log-kans van specifieke tokens kunnen aanpassen vóór de samplingstap. Oorspronkelijk ontworpen voor legitieme toepassingen zoals het afdwingen van JSON-uitvoer, het vermijden van specifieke woorden of het sturen van gestructureerde generatie, biedt deze parameter directe toegang tot de uitvoerverdeling van het model op een manier die veiligheids-alignment fundamenteel kan ondermijnen.
Veiligheids-alignment in grote taalmodellen werkt voornamelijk op het niveau van geleerde tokenverdelingen. Wanneer een model een schadelijk verzoek weigert, doet het dat omdat de post-training de kans op weigeringstokens (zoals "I", "cannot", "sorry", "inappropriate") heeft verhoogd en de kans op meewerktokens heeft verlaagd. De logit-bias-parameter werkt nadat het model zijn logits heeft berekend maar vóór het samplen, wat betekent dat die deze geleerde veiligheidsverdelingen kan overrulen zonder dat het model enige gelegenheid heeft om "bezwaar te maken".
Dit maakt misbruik van logit bias categorisch anders dan op prompts gebaseerde aanvallen. Prompt injection en jailbreaken proberen de interne berekening van het model te manipuleren om de uitvoerverdeling te veranderen. Manipulatie van logit bias omzeilt de interne berekening volledig en wijzigt rechtstreeks de verdeling waaruit tokens worden gesampled. De veiligheidstraining van het model is intact — ze wordt simpelweg nooit geraadpleegd op het punt waar de wijziging plaatsvindt.
Het aanvalsoppervlak reikt verder dan eenvoudige veiligheidsomzeiling. Systematische logit-probing — het model bevragen met zorgvuldig opgebouwde logit-bias-configuraties en observeren hoe de uitvoer verandert — kan informatie onthullen over de woordenschat van het model, de veiligheidsgrenzen, de interne vertrouwensniveaus en het gedrag op tokenniveau. Deze informatie kan vervolgens worden gebruikt om effectievere aanvallen te vervaardigen of om aspecten van de training van het model te reverse-engineeren.
Hoe het werkt
Identificeer de token-ID's van weigeringen
De aanvaller bepaalt eerst welke token-ID's overeenkomen met veelvoorkomende weigeringspatronen. Dit wordt gedaan door het model te prompten met schadelijke verzoeken zonder logit bias en te observeren welke tokens in weigeringen voorkomen. Tokenizer-bibliotheken of API-tokenisatie-endpoints zetten deze tokens weer om in hun gehele ID's.
import tiktoken enc = tiktoken.encoding_for_model("gpt-4o") # Veelvoorkomende tokens waarmee weigeringen beginnen refusal_tokens = [ "I", " cannot", " sorry", "Sorry", " apolog", " inappropriate", " unable", " refuse", " harmful", " unethical", "As", " As", " I'm" ] refusal_ids = {} for token_text in refusal_tokens: ids = enc.encode(token_text) for token_id in ids: refusal_ids[token_id] = token_text print(f"Identified {len(refusal_ids)} refusal token IDs")Onderdruk weigeringstokens via negatieve bias
De aanvaller past een sterke negatieve logit bias toe (doorgaans -100, het maximum dat de meeste API's toestaan) op alle geïdentificeerde token-ID's van weigeringen. Dit verwijdert weigeringstokens effectief uit de samplingverdeling, waardoor het model alternatieve tokens moet selecteren.
# Bouw de logit_bias-dictionary om weigeringen te onderdrukken logit_bias = {str(token_id): -100 for token_id in refusal_ids} response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": harmful_prompt}], logit_bias=logit_bias, max_tokens=500, )Wanneer het model normaal gesproken een weigering zou beginnen met "I cannot assist with...", maakt de bias van -100 die tokens vrijwel onmogelijk om te samplen. Het model moet kiezen uit de overgebleven tokens, die mogelijk meewerktokens omvatten.
Versterk meewerktokens voor sterker forceren
Naast het onderdrukken van weigeringen kan de aanvaller positief bias toepassen op tokens waarmee meewerkende antwoorden beginnen. Het versterken van tokens als "Sure", "Here", "Step" of "First" duwt het model vanaf het eerste token richting een meewerkkader.
compliance_tokens = ["Sure", " Here", "Step", " First", " The", " To"] compliance_ids = {} for token_text in compliance_tokens: ids = enc.encode(token_text) for token_id in ids: compliance_ids[token_id] = token_text # Combineer: onderdruk weigeringen, versterk meewerken combined_bias = {str(k): -100 for k in refusal_ids} combined_bias.update({str(k): 5 for k in compliance_ids})De combinatie van negatieve bias op weigeringstokens en positieve bias op meewerktokens creëert een tweezijdige druk die aanzienlijk effectiever is dan beide technieken afzonderlijk.
Iteratieve probing voor het in kaart brengen van woordenschat en veiligheid
Systematische logit-probing gebruikt logit bias als meetinstrument. Door het model te dwingen specifieke tokens te genereren als reactie op veiligheidsrelevante prompts, kan een aanvaller de veiligheidsgrenzen van het model op tokenniveau in kaart brengen.
def probe_token_safety(client, prompt, token_id, bias_strength=10): """Measure how a specific token responds to bias on a given prompt.""" # Baseline: geen bias baseline = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], max_tokens=1, logprobs=True, top_logprobs=20, ) # Met bias: forceer richting een specifiek token biased = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], logit_bias={str(token_id): bias_strength}, max_tokens=1, logprobs=True, top_logprobs=20, ) return { "baseline_top": baseline.choices[0].logprobs, "biased_top": biased.choices[0].logprobs, "shift": True # Vergelijk de verdelingen }Extraheer de vertrouwens- en veiligheidsmarges van het model
Door logit-bias-waarden van -100 tot +100 door te lopen voor veiligheidskritieke tokens en de drempel te observeren waarbij het gedrag van het model verandert, kan een aanvaller de vertrouwensmarge van het model bij veiligheidsbeslissingen schatten. Een smalle marge geeft aan dat de veiligheids-alignment van het model op dat onderwerp zwak is en mogelijk kwetsbaar voor andere aanvalsmethoden.
def measure_safety_margin(client, prompt, refusal_token_id): """Find the bias threshold at which behavior flips.""" for bias in range(-100, 101, 5): response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": prompt}], logit_bias={str(refusal_token_id): bias}, max_tokens=50, ) output = response.choices[0].message.content is_refusal = any( phrase in output.lower() for phrase in ["i cannot", "i'm sorry", "i apologize"] ) if not is_refusal: return bias # Drempel waarbij de veiligheid het begeeft return None # Veiligheid hield stand over het volledige bereik
Aanvalsvoorbeelden
Voorbeeld 1: weigeringsonderdrukking op veiligheidskritieke onderwerpen
Een aanvaller die zich richt op een schending van het inhoudsbeleid identificeert de top 50 aan weigeringen gerelateerde tokens voor het doelmodel. Door op alle tegelijk een bias van -100 toe te passen, is het model niet in staat zijn getrainde weigeringsantwoord te produceren. Bij tests tegen verschillende commerciële API's in 2024 ontdekten onderzoekers dat naïeve weigeringsonderdrukking alleen al voldoende was om beleidsschendende inhoud uit te lokken in 15-30% van de gevallen, afhankelijk van het onderwerp en het model.
Het slagingspercentage stijgt aanzienlijk in combinatie met het versterken van meewerktokens. Het model, niet in staat om te weigeren en geduwd richting een bevestigende framing, vervalt vaak in een patroonaanvullingsmodus waarin het inhoud genereert die consistent is met de meewerk-framing, ongeacht het onderliggende onderwerp.
Voorbeeld 2: systematisch in kaart brengen van veiligheidsgrenzen
Een red-teamopdracht gebruikt logit-probing om in kaart te brengen welke onderwerpen een sterke versus zwakke veiligheids-alignment hebben. Voor elke onderwerpcategorie meet het team de bias-drempel die nodig is om weigeringen te onderdrukken. Onderwerpen die bias-waarden in de buurt van -100 vereisen om te overwinnen wijzen op sterke alignment; onderwerpen die bij -20 of -30 omslaan wijzen op zwakke alignment die mogelijk te misbruiken is via alleen op prompts gebaseerde aanvallen.
Deze informatie wordt vervolgens gebruikt om de inspanningen rond prompt injection te prioriteren. In plaats van alle onderwerpen even uitgebreid te testen, richt het team zich op onderwerpen met zwakke alignment, waar op prompts gebaseerde aanvallen het meest waarschijnlijk slagen, wat de efficiëntie van de opdracht dramatisch verbetert.
Voorbeeld 3: informatie-extractie op tokenniveau
Door het model te dwingen zijn antwoord te beginnen met specifieke tokens ("The password is", "The system prompt says") kan een aanvaller informatie extraheren die het model normaal gesproken zou weigeren prijs te geven. De logit bias forceert de openingstokens, en de autoregressieve aard van het model genereert vervolgens vervolgteksten die consistent zijn met die opening, waarmee mogelijk systeemprompts, configuratiedetails of andere beschermde informatie worden onthuld.
Detectie & mitigatie
| Strategie | Implementatie | Effectiviteit |
|---|---|---|
| Beperking van het logit-bias-bereik | Beperk logit-bias-waarden tot een smal bereik (bijv. -10 tot +10) in plaats van -100 tot +100 toe te staan | Hoog — elimineert harde onderdrukking/forcering maar behoudt legitieme toepassingen |
| Bescherming van weigeringstokens | Voorkom dat logit bias wordt toegepast op een samengestelde set veiligheidskritieke tokens | Gemiddeld — vereist het onderhouden van een tokenblokkeerlijst, kan worden omzeild via synoniemtokens |
| Veiligheidscontrole na het samplen | Pas een secundaire veiligheidsclassificator toe op de gegenereerde uitvoer, ongeacht de logit-bias-instellingen | Hoog — vangt onveilige inhoud op die de interne veiligheid van het model omzeilt |
| Anomaliedetectie van logit bias | Markeer API-aanroepen met extreme bias-waarden of grote aantallen tokens met bias | Gemiddeld — effectief tegen ongesofisticeerde aanvallen maar te ontwijken met subtielere bias-configuraties |
| Rate limiting op variatie in logit bias | Beperk het aantal verschillende logit-bias-configuraties van één API-sleutel binnen een tijdvenster | Gemiddeld — vertraagt systematische probing maar voorkomt individueel misbruik niet |
| Monitoring van uitvoer-coherentie | Detecteer uitvoer die tekenen vertoont van geforceerde tokengeneratie (ongebruikelijke tokensequenties, grammaticale onregelmatigheden) | Laag-gemiddeld — geforceerde generatie produceert vaak detecteerbare sporen, maar vaardige aanvallers kunnen die omzeilen |
Belangrijke overwegingen
API-ontwerp is een security-oppervlak. De logit-bias-parameter is ontworpen voor bruikbaarheid, niet voor security. De positie ervan in de inferentiepijplijn — nadat het model veiligheidsbewuste logits heeft berekend maar vóór het samplen — creëert een inherente spanning tussen flexibiliteit en veiligheid. API-providers moeten erkennen dat elke generatieparameter die de uitvoerverdeling wijzigt een potentiële veiligheidsomzeilingsvector is.
Defense in depth is essentieel. Geen enkele mitigatie pakt misbruik van logit bias volledig aan. De meest robuuste aanpak combineert beperkingen aan de invoerzijde (bias-bereiklimieten, tokenbescherming), verificatie aan de uitvoerzijde (veiligheidsclassificatoren na het samplen) en monitoring (anomaliedetectie, rate limiting). Elke laag vangt aanvallen op die door andere lagen glippen.
Logit-probing onthult meer dan bedoeld. Zelfs als een API-provider directe veiligheidsomzeiling via logit bias voorkomt, lekt de mogelijkheid om de reactie van het model op bias-variaties systematisch te onderzoeken informatie over de interne veiligheidsgrenzen van het model. Deze informatie heeft zelfstandige waarde voor het vervaardigen van andere aanvallen. Providers zouden moeten overwegen of toegang tot logit bias nodig is voor hun toepassing en die standaard moeten uitschakelen.
Het logprobs-endpoint vergroot het risico. Wanneer logit bias wordt gecombineerd met de logprobs-parameter (die de log-kansen van de beste kandidaattokens teruggeeft), verkrijgt de aanvaller nog preciezere informatie over de verdeling van het model. De combinatie van logit bias om de verdeling te verstoren en logprobs om de resultaten te observeren creëert een krachtig orakel om de interne werking van het model te onderzoeken.
Referenties
- Wei et al., "Jailbroken: How Does LLM Safety Training Fail?" (NeurIPS 2023) — Taxonomie van faalwijzen van veiligheidstraining, inclusief aanvallen op parameterniveau
- Zou et al., "Universal and Transferable Adversarial Attacks on Aligned Language Models" (2023) — GCG-aanval die veiligheidsomzeiling op tokenniveau demonstreert
- OpenAI, "API Reference: Chat Completions" — Documentatie van de logit_bias-parameter en het gedrag ervan
Waarom is misbruik van logit bias fundamenteel anders dan prompt-injection-aanvallen?