AI-sikkerhet handler om hva modellen kan nå.

Hva prompt injection er

En språkmodell tar imot én ting: tekst. Den har ingen kanal for «dette er en ordre fra eieren» og en annen for «dette er data fra en fremmed». Alt havner i det samme vinduet, og modellen gjør sitt beste for å følge det som ligner mest på en instruksjon.

Prompt injection er å utnytte nettopp det. Angriperen skriver ikke til deg. Han skriver til modellen din, gjennom en kanal du selv har åpnet, og han skriver noe som leser som en ny instruks.

Det trenger ikke å se ut som et angrep. En setning midt i en PDF, en linje i en e-postsignatur, en produktbeskrivelse fra en leverandør: alt sammen er tekst som havner i det samme vinduet som systeminstruksjonen din. Modellen leser dem i rekkefølge og vekter dem etter hvor mye de ligner på noe den skal gjøre, ikke etter hvem som skrev dem.

Dette er ikke en feil som kan lukkes med en oppdatering. Det følger av hva en språkmodell er. Derfor er svaret aldri «en bedre instruksjon», og derfor begynner enhver seriøs gjennomgang med å tegne opp hva som skriver inn i modellen og hva modellen kan skrive ut av seg.

Hvorfor en kundeportal er særlig utsatt

En chatbot på en åpen forside har lite å miste. Den vet ingenting om den som spør, og den kan ingenting utover å svare.

En assistent i en innlogget kundeportal er det motsatte, og forskjellen er ikke gradvis. Den er innenfor en økt som allerede er autentisert, den kan slå opp noe, og ofte kan den gjøre noe: hente en ordre, sende en e-post, opprette en sak. Fra modellens side er det bare verktøy den har lov til å kalle.

Den er autentisert. Alt modellen gjør, gjør den i en innlogget kontekst, og et vellykket angrep arver den innloggingen.

Den tar imot innhold utenfra. Vedlegg, e-post, kataloger og integrasjoner er kanaler der noen andre enn kunden skriver teksten modellen leser. Angriperen trenger ikke en konto for å komme inn i vinduet.

Og den har verktøy. Et oppslag er en lekkasje som venter. Et verktøy som sender noe ut av systemet er en handling, og en handling kan ikke tas tilbake. En modell uten verktøy kan si noe feil. En modell med verktøy kan gjøre noe feil, og det er en annen kategori.

Hvordan en modell lekker data fra andre brukere

Lekkasjen skjer nesten aldri ved at modellen husker forrige samtale. Den skjer gjennom oppslaget.

Har assistenten en kunnskapsbase å slå opp i, er spørsmålet ikke om databasen er sikker. Spørsmålet er om filteret som avgjør hva som hentes, hører hjemme samme sted som beslutningen om hva som vises. Ligger avgrensningen i instruksjonen til modellen, i formen «svar bare på dokumenter som tilhører denne kunden», så er den en anbefaling. Ligger den i spørringen mot databasen, er den en grense.

De vanligste veiene ut er fire. Oppslag uten eierfilter i selve spørringen, der modellen får treff fra hele indeksen og velger selv hva den viser. Sammenblanding i konteksten, der flere kunders dokumenter ligger i samme indeks, skilt bare av et metadatafelt modellen er bedt om å respektere. Feilmeldinger og oppsummeringer, der modellen forteller hva den ikke fikk lov til å hente og navngir det i samme åndedrag. Og verktøy som tar en identifikator fra samtalen, der et ordrenummer slås opp uten at noen kontrollerer at det tilhører den som spør.

Alle fire har samme rot: en grense som er formulert som språk i stedet for som kode.

Hva LLM guardrails er, og hva de ikke løser

LLM guardrails er reglene rundt modellen: hva som slipper inn i vinduet, hva modellen har lov til å kalle, hva som får lov til å forlate systemet, og hva som logges når noe stoppes.

Merk hvor de står. Rundt modellen, ikke inni den. En regel skrevet i systeminstruksjonen er en anmodning til den samme mekanismen angriperen snakker til. En regel skrevet i koden er en betingelse som må være sann før noe skjer.

Det guardrails løser er hvem verktøyet kjører som, hvilke rader spørringen kan treffe, hvilke domener en utgående forespørsel kan gå til, hva som skjer uten et menneske i sløyfa, og hvor mye en enkelt økt får lov til å hente ut.

Det de ikke løser er at modellen kan overtales. Den kan fortsatt skrive noe den ikke burde. Poenget er at den ikke skal ha noe å skrive med. Et forsvar som hviler på at modellen aldri tar feil, er ikke et forsvar. Et forsvar som antar at den kommer til å ta feil, og som sørger for at det ikke koster noe, er det.

Derfor er «vi har lagt inn en instruks om at den ikke skal gjøre det» ikke et svar på spørsmålet. Det er en beskrivelse av hva som ble prøvd først.

Hva red teaming av en språkmodell innebærer

Red teaming er ikke en samtale med chatboten for å se om den sier noe rart. Det er en strukturert gjennomgang av oppsettet ditt, og den følger fire steg.

Flatene tegnes opp først. Hva skriver inn i modellen, og hva kan modellen skrive ut av seg? Hver kanal føres opp med hvem som styrer den og hva den eksponerer. Et funn uten en flate er en anekdote.

Vektorene kjøres mot ditt oppsett, ikke mot en modell generelt. Injeksjon gjennom vedlegg, gjennom innkommende e-post, gjennom en katalogtekst du ikke skrev selv. Forsøk på å få modellen til å kalle et verktøy den ikke skulle, med en identifikator den ikke skulle hatt. Forsøk på å hente ut noe fra kunnskapsbasen som ikke var ment for den som spør.

Alt som slipper gjennom dokumenteres mens det skjer: hva som ble sendt, hva som kom tilbake, og hva det ville kostet i produksjon.

Og så gjentas det. Et funn er ikke lukket fordi noe ble endret. Det er lukket når det samme angrepet kjøres på nytt og ikke virker. Det siste steget er det som skiller en gjennomgang fra en rapport.

Seks ting du kan sjekke selv

Du trenger ikke en gjennomgang for å svare på disse. Kan du ikke svare på dem, vet du allerede hva det første steget er.

1. Hva kan modellen kalle? Skriv ned hvert verktøy. Er lista lengre enn du husket, er det svaret.

2. Hvem kjører verktøyet som? Kjører det med kundens rettigheter, eller med systemets? Det andre er den dyre varianten.

3. Hvor står avgrensningen på et oppslag? I spørringen mot databasen, eller i teksten som ber modellen oppføre seg?

4. Hvilken tekst havner i vinduet uten at et menneske har sett den? Vedlegg, e-post, leverandørdata, nettsider modellen henter selv.

5. Hva kan forlate systemet uten en bekreftelse? E-post, webhooks, API-kall utover.

6. Ser du det i loggen etterpå? Ikke bare hva modellen svarte, men hvilke verktøy den kalte og med hvilke argumenter.

Fire eller flere ubesvarte spørsmål betyr ikke at du er utsatt. Det betyr at du ikke vet, og det er den tilstanden en gjennomgang finnes for å avslutte.

Grunnlaget

Bachelorgrad i cybersikkerhet, med en bacheloroppgave skrevet for Telenor, og fire foredrag hos Telenor: AI-guardrails, red teaming, blue teaming, og hvordan språkmodeller brytes og hvorfor det virker.

Se hva en gjennomgang inneholder