AI-sikkerhed mod jailbreaking handler om at gøre sprogmodeller og AI-applikationer robuste mod instruktioner, der forsøger at få modellen til at bryde sine sikkerhedsregler. Beskyttelsen består ikke af én filterregel, men af lag: modeltræning, systemdesign, adgangskontrol, overvågning og test af konkrete misbrugsscenarier.
AI-sikkerhed mod jailbreaking er en lagdelt beskyttelse af sprogmodeller mod forsøg på at omgå sikkerhedsregler. Overblikket samler forskellen mellem modelværn, applikationskontroller, adgangsstyring, test og menneskelig godkendelse, så risikoen kan vurderes mere konkret før brug i organisationer.
Hvad betyder jailbreaking i AI-sikkerhed?
Jailbreaking er forsøg på at få en AI-model til at tilsidesætte de regler, begrænsninger eller sikkerhedsinstruktioner, den normalt skal følge. I praksis kan det være formuleringer, rollespil, skjulte instruktioner, kodede beskeder eller lange dialoger, der presser modellen væk fra den tilsigtede adfærd.
I en simpel chatbot kan konsekvensen være, at modellen giver et svar, den burde afvise. I en AI-applikation med adgang til filer, e-mails, databaser, værktøjer eller API’er kan konsekvensen være mere alvorlig, fordi modellen ikke kun skriver tekst, men påvirker handlinger i et system.
Derfor bør jailbreaking ikke kun ses som et indholdsproblem. Det er også et applikationssikkerhedsproblem, hvor modellen indgår i en større kæde af brugerinput, systeminstruktioner, hentede data, værktøjskald og menneskelige beslutninger.
Hvorfor opstår risikoen i sprogmodeller?
Store sprogmodeller behandler tekst, instruktioner og kontekst i samme samlede inputvindue. Modellen kan trænes til at prioritere visse instruktioner over andre, men den arbejder stadig med sandsynligheder og mønstre i tekst. Det gør grænsen mellem legitim opgavebeskrivelse, data og manipulerende instruktion mere skrøbelig end i klassisk software.
En traditionel applikation kan ofte skelne teknisk mellem kode, data og rettigheder. En sprogmodel møder derimod instruktioner i naturligt sprog. Hvis en bruger eller et eksternt dokument formulerer sig som en overordnet instruktion, skal modellen og applikationen have mekanismer, der fastholder den oprindelige prioritet.
NCSC har beskrevet, at denne vanskelighed kan være en iboende udfordring ved LLM-teknologi. Det betyder ikke, at beskyttelse er nyttesløs. Det betyder, at sikkerhed mod jailbreaking bør bygges som skadebegrænsning, test og kontrollerede tillidsgrænser i stedet for som et løfte om fuld immunitet.
Hvordan adskiller jailbreaking sig fra instruktionsinjektion?
Jailbreaking og instruktionsinjektion overlapper, men de beskriver ikke altid det samme. Jailbreaking handler især om at omgå en models sikkerhedsregler eller indholdsbegrænsninger. Instruktionsinjektion handler bredere om at få modellen til at følge en uønsket instruktion, som ikke burde have autoritet i den aktuelle opgave.
En direkte instruktionsinjektion kommer fra den bruger, der skriver til modellen. En indirekte instruktionsinjektion kan komme fra data, som modellen henter eller får vist, for eksempel en webside, et dokument, en e-mail eller et søgeresultat. Forskningen i indirekte angreb viser, at risikoen vokser, når modellen kobles til eksterne datakilder og værktøjer.
Skellet er praktisk, fordi modtrækkene er forskellige. Mod jailbreaking skal modellen og sikkerhedslaget kunne genkende forsøg på at omgå regler. Mod indirekte instruktionsangreb skal applikationen også markere eksternt indhold som upålideligt, begrænse værktøjsrettigheder og validere handlinger uden at stole blindt på modellens tekst.
Hvilke konsekvenser kan et vellykket angreb få?
Konsekvensen afhænger af, hvad AI-systemet har adgang til. En isoleret skriveassistent uden værktøjer kan give upassende, forkert eller fortroligt klingende indhold. En integreret assistent kan derimod påvirke arbejdsgange, hvis den har adgang til interne data, dokumenter, bilag, kundesager eller automatiserede handlinger.
OWASP fremhæver blandt andet risiko for følsom informationsdeling, manipulation af svar, uautoriseret brug af funktioner og påvirkning af beslutningsprocesser. NIST placerer jailbreaking og beslægtede angreb i et bredere risikobillede, der også omfatter informationssikkerhed, databeskyttelse og skadeligt indhold.
For en organisation er det afgørende spørgsmål derfor ikke kun, om modellen kan overtales til et forkert svar. Spørgsmålet er, hvad det forkerte svar kan ændre i den virkelige proces. Jo mere selvstændighed systemet har, desto stærkere skal adgangsstyring, godkendelse og logning være.
Hvilke lag indgår i et robust forsvar?
Et robust forsvar kombinerer flere lag, fordi ingen enkelt kontrol kan stoppe alle varianter. Modellen kan være bedre trænet til at afvise uønskede instruktioner, men applikationen skal stadig styre dataadgang, værktøjsrettigheder, outputformater og menneskelig godkendelse.
| Lag | Formål | Kontrolspørgsmål |
|---|---|---|
| Modelværn | Reducerer sandsynligheden for, at modellen følger uønskede instruktioner. | Er modellen testet mod kendte omgåelsesforsøg i den konkrete brugssituation? |
| Systeminstruktioner | Definerer rolle, grænser, kilder og afvisningsadfærd. | Er instruktionerne korte, entydige og prioriteret over brugerinput og eksternt indhold? |
| Adgangsstyring | Begrænser, hvilke data og værktøjer AI-systemet kan nå. | Kan modellen kun tilgå det, der er nødvendigt for den aktuelle opgave? |
| Outputvalidering | Kontrollerer svar og handlinger, før de bruges videre. | Bliver kritiske output tjekket af kode, regler eller mennesker? |
| Overvågning | Finder mønstre, fejl og misbrug efter ibrugtagning. | Er der logning, hændelseshåndtering og løbende forbedring? |
AI Mentor har også en bredere gennemgang af AI-sikkerhedsprotokoller og standarder, som placerer denne type kontrol i en mere generel sikkerhedsramme.
Hvordan bruges instruktioners rangorden som teknisk kontrol?
En vigtig sikkerhedstanke er, at ikke alle instruktioner bør have samme vægt. En systeminstruktion fra applikationens ejer bør have højere autoritet end en brugerbesked. En brugerbesked bør have højere autoritet end tekst, der tilfældigt hentes fra en webside eller et dokument.
OpenAI har beskrevet en instruktionshierarkisk tilgang, hvor modeller trænes til at prioritere privilegerede instruktioner over lavere prioriterede instruktioner, når de kommer i konflikt. Det er relevant mod jailbreaking, fordi mange angreb forsøger at få modellen til at behandle angriberens tekst som om den var mere autoritativ end den egentlig er.
Instruktionshierarki er dog ikke nok alene. Hvis applikationen giver modellen adgang til en farlig handling, kan en enkelt fejl stadig få konsekvenser. Rangorden i instruktioner bør derfor kombineres med tekniske grænser, så modellen ikke kan gøre mere, end systemet trygt kan tillade.
Hvorfor er adgangskontrol vigtigere end formuleringer alene?
Formuleringer i systeminstruktioner kan hjælpe modellen med at afvise uønskede anmodninger, men de bør ikke være den eneste sikkerhedsgrænse. Hvis en model har adgang til et værktøj, der kan sende e-mails, hente fortrolige dokumenter eller ændre data, skal applikationen styre rettighederne uden at overlade beslutningen til modellens fritekstsvar.
Adgangskontrol betyder blandt andet, at hvert værktøj kun får de nødvendige rettigheder, at følsomme handlinger kræver godkendelse, og at modellen ikke modtager hemmeligheder, den ikke behøver. Det samme princip gælder ved brug af AI-API’er, hvor dataminimering og klare tilladelser er centrale for beskyttelse af data ved brug af AI-API’er.
Et praktisk sikkerhedsspørgsmål er: Hvad kan systemet gøre, hvis modellen følger den værst tænkelige instruktion i den aktuelle kontekst? Hvis svaret er at afsløre data, ændre kundesager eller foretage irreversible handlinger, bør rettighederne reduceres eller suppleres med en manuel godkendelse.
Hvordan bør eksternt indhold håndteres i AI-agenter og RAG?
Eksternt indhold er en særlig risiko, fordi det ofte ligner almindelige data for brugeren, men kan indeholde instruktioner rettet mod modellen. Det gælder blandt andet websider, supportmails, kalenderinvitationer, PDF-filer, kodekommentarer, vidensbaser og dokumenter i retrieval-augmented generation.
En AI-agent med værktøjer har en større angrebsflade end en ren chatbot, fordi den kan planlægge trin og kalde funktioner. Hvis du arbejder med agentbaserede systemer, er forskellen mellem en samtaleflade og en handlende agent derfor central. Den forskel er uddybet i AI Mentors forklaring af hvad en AI-agent er.
Eksternt indhold bør behandles som upålidelige data. Det kan markeres tydeligt for modellen, isoleres i separate felter, begrænses til læsning og valideres, før det påvirker handlinger. Hvis en hentet tekst siger, at modellen skal ændre regler, afsløre instruktioner eller kalde et værktøj, bør applikationen afvise den handling uafhængigt af modellens formulering.
Hvordan tester man mod jailbreaking i praksis?
Test bør tage udgangspunkt i den konkrete anvendelse, ikke kun i generelle eksempler. En intern skriveassistent, en kundeservicebot, et RAG-system og en agent med API-adgang har forskellige risici. Derfor bør testcases beskrive de data, værktøjer, brugerroller og handlinger, systemet faktisk møder.
NIST anbefaler blandt andet AI red-teaming mod misbrug, skadelige output, instruktionsangreb, adversarial examples, data poisoning og model extraction. I en praktisk organisation betyder det, at testholdet bør forsøge at få systemet til at bryde sine regler, men også måle om kontroller uden for modellen stopper skaden.
- Test direkte forsøg på at få modellen til at ignorere sine regler.
- Test indirekte forsøg via dokumenter, mails, websider og vidensbaser.
- Test om systemet nægter uautoriserede værktøjskald og datakilder.
- Test om følsomme handlinger kræver menneskelig godkendelse.
- Test om logs gør det muligt at forstå og rette et misbrugsforsøg.
Resultatet bør ikke kun være en ja-nej-vurdering. Det bør give en prioriteret liste over svage punkter, for eksempel for brede rettigheder, manglende outputvalidering, for uklare systeminstruktioner eller utilstrækkelig adskillelse mellem eksterne data og brugerens egentlige opgave.
Hvilke fejl svækker ofte beskyttelsen?
En almindelig fejl er at tro, at en længere systeminstruktion i sig selv løser problemet. Lange instruktioner kan være svære at vedligeholde, og de kan stadig komme i konflikt med brugerinput eller hentet indhold. Kortere, tydeligere instruktioner kombineret med tekniske kontroller er normalt lettere at teste.
En anden fejl er at give modellen bred adgang for at gøre løsningen mere fleksibel. Fleksibilitet øger nytten, men også konsekvensen af et misbrugsforsøg. Derfor bør funktioner som filadgang, e-mail, databaseopslag og eksterne API-kald opdeles i små, kontrollerede handlinger.
En tredje fejl er at teste én gang før lancering og derefter antage, at sikkerheden holder. Modeller, datakilder, brugeradfærd og angrebsteknikker ændrer sig. NIST fremhæver løbende monitorering, hændelsesgennemgang og revurdering efter ændringer som en del af risikostyringen for generativ AI.
Hvad betyder AI-sikkerhed mod jailbreaking for organisationer?
For organisationer handler AI-sikkerhed mod jailbreaking om at placere modellen rigtigt i arbejdsgangen. En model, der kun foreslår tekst til en medarbejder, kræver en anden sikkerhedsmodel end en model, der automatisk sender svar, åbner sager, opdaterer registre eller træffer beslutninger.
Den mest nyttige tilgang er at klassificere brugsscenarier efter konsekvens. Lavrisikoopgaver kan ofte håndteres med modelværn, almindelig kontrol og efterfølgende stikprøver. Opgaver med følsomme data, økonomiske konsekvenser eller myndighedslignende beslutninger kræver stærkere adgangsstyring, dokumentation og menneskelig godkendelse.
Dette hænger tæt sammen med generel beskyttelse mod AI-system-hacking, fordi jailbreaking ofte er ét led i et bredere forsøg på at påvirke et AI-system. Et godt design begrænser både uønskede svar og uønskede handlinger.
Hvordan vurderer du restrisiko før ibrugtagning?
Restrisiko er den risiko, der er tilbage, efter kontrollerne er lagt på. Den kan ikke vurderes abstrakt. Den afhænger af data, brugergruppe, værktøjsadgang, automatiseringsgrad og konsekvensen af fejl. Derfor bør vurderingen ske tæt på den faktiske proces, hvor AI-systemet skal bruges.
En enkel beslutningsrækkefølge kan gøre vurderingen mere konkret:
- Beskriv hvilke handlinger AI-systemet kan udføre uden menneskelig godkendelse.
- Fjern adgang til data og værktøjer, der ikke er nødvendige for opgaven.
- Definer hvilke output der skal valideres af kode, regler eller mennesker.
- Test direkte og indirekte omgåelsesforsøg i realistiske datasæt.
- Fastlæg hvornår systemet skal stoppe, logge, eskalere eller kræve manuel vurdering.
Hvis systemet stadig kan skabe uacceptable konsekvenser efter disse trin, bør opgaven ændres, automatiseringen begrænses eller kontrollen flyttes til et menneske. Sikkerhed mod jailbreaking er dermed ikke kun et teknisk filter, men en beslutning om, hvor meget handlekraft en AI må have.
Hvordan hænger jailbreaking sammen med modelmisbrug?
Jailbreaking er en metode til at forsøge at fremkalde uønsket modeladfærd. Modelmisbrug er den bredere kategori, hvor en AI-model bruges til formål, som systemet ikke er tiltænkt eller ikke bør understøtte. Det kan være produktion af skadeligt indhold, udtræk af fortrolig information, manipulation af beslutninger eller misbrug af integrerede værktøjer.
Derfor bør kontroller mod jailbreaking indgå i en bredere misbrugsstrategi. Det omfatter acceptable use-regler, begrænsede værktøjsrettigheder, sikker håndtering af data, overvågning af afvigelser og en proces for at reagere på nye angrebsmønstre. AI Mentor beskriver denne bredere vinkel i gennemgangen af kontrol af AI-modeller mod misbrug.
En moden tilgang måler ikke kun, om modellen afviser bestemte ord. Den vurderer, om hele systemet kan modstå manipulation, når angriberen ændrer sprog, opdeler instruktioner, skjuler indhold i data eller forsøger at få en legitim bruger til at udløse handlingen.
Menneskelig godkendelse er især nødvendig, når en AI-handling kan få juridiske, økonomiske, sikkerhedsmæssige eller personlige konsekvenser. Det gælder ikke, fordi mennesker altid opdager alle fejl, men fordi en godkendelsesgrænse begrænser, hvad et vellykket omgåelsesforsøg kan udløse automatisk.
Godkendelsen skal være konkret. En medarbejder bør kunne se den foreslåede handling, relevante kilder, datagrundlag og begrundelse uden at skulle stole på modellens egen forsikring om, at alt er sikkert. I højrisikoopgaver bør systemet også vise, hvilke rettigheder der bruges, og hvilke data der sendes videre.
Hvis menneskelig godkendelse bliver en rutinemæssig klikhandling uden reel information, mister den værdi. Den bør derfor placeres ved de få handlinger, hvor konsekvensen er høj, og hvor automatisering uden kontrol ville gøre jailbreaking til en direkte driftsrisiko.
Hvilke kilder ligger til grund?
Artiklen bygger på OWASPs oversigt over LLM Top 10-risici, NISTs Generative AI Profile, NCSCs vejledning om at bygge forsigtigt oven på LLM’er, OpenAIs forskning i instruktionshierarki og Greshake m.fl.s paper om indirekte instruktionsangreb.