Prompt injection: nr. 1 hos OWASP, nr. 12

Et nyt analysearbejde fra ledere bag OWASP's egen trusselsliste sammenligner ekspertvurderingen af risici mod AI-agenter med et stort datasæt af faktiske hændelser. Konklusionen er tydelig: den sammenhæng, man skulle forvente mellem "det eksperterne frygter mest" og "det der faktisk sker mest", er svag. Prompt injection topper ekspertlisten, fordi et vellykket angreb kan give total kontrol over en agents adfærd. Men i hændelsesregistreringen ligger den langt nede, fordi de færreste organisationer opdager og logfører angrebet som det, det er.

Vi ser den samme mekanisme igen og igen hos virksomheder, der har sat AI-agenter i drift uden at ændre deres detektionslag. Et succesfuldt prompt injection-angreb producerer ikke en fejlmeddelelse. Det producerer et output, der ser normalt ud, men som følger en instruks, angriberen har smuglet ind, snarere end den instruks, brugeren gav. Systemet logger en succesfuld handling, ikke et angreb.

Traditionel sikkerhedsscanning er bygget til at genkende kendte moenstre: en signatur, en anomali i netvaerkstrafik, en uventet systemkald. Prompt injection gaar uden om det hele. Angrebet foregaar inde i selve sproget, som modellen fortolker, og resultatet er en handling, agenten var autoriseret til at udfoere alligevel. Der er intet at signaturmatche. Ingen malware, ingen usaedvanlig proces, ingen afvigende trafik.

De fleste organisationer opdager foerst et angreb, naar konsekvensen bliver synlig et andet sted, for eksempel som et datalaek, en forkert transaktion eller en kunde, der reagerer paa noget agenten aldrig burde have sagt. Paa det tidspunkt bliver haendelsen typisk kategoriseret efter sin konsekvens, ikke efter sin aarsag. Det er en stor del af forklaringen paa, hvorfor prompt injection ser sjaelden ud i haendelsesstatistikken, selv om den formentlig er langt mere udbredt end tallene viser.

Analysen bruger et statistisk mål, Cohens kappa, til at kvantificere, hvor godt ekspertvurderingen matcher de faktiske hændelsesdata. Et kappa-tal på 0,20 betegnes normalt som svag til minimal enighed, langt fra den type solide overensstemmelse man ville forvente, hvis en trusselsliste skulle afspejle den virkelige verden en til en.

Det betyder ikke, at OWASP's rangering er forkert. Ekspertvurdering og hændelsesdata måler to forskellige ting. Eksperterne vurderer potentiel skade, altså hvor slemt det kan gå, hvis et angreb lykkes. Hændelsesdataene måler registreret skade, altså hvad der rent faktisk er blevet fanget og rapporteret. Når de to metoder giver vidt forskellige rangeringer, er den rigtige konklusion ikke at vælge den ene og forkaste den anden. Det er at erkende, at man har brug for begge, og at et lavt tal i hændelsesstatistikken for en trussel som prompt injection ikke er et bevis på, at truslen er lille. Det er lige så ofte et bevis på, at detektionen er svag.

Den praktiske konsekvens af analysen er en anbefaling, mange sikkerhedsfolk allerede har draget: man kan ikke løse prompt injection ved at gøre modellen "klogere" eller bedre til at genkende ondsindede instrukser. Angrebsfladen er sproget selv, og sprog er umuligt at filtrere med fuldstændig sikkerhed. Derfor anbefaler OWASP, at autorisation og handlingsbegrænsninger håndhæves uden for modellen, ikke inden i den.

Det betyder i praksis, at en agent aldrig bør have adgang til at udføre en handling, bare fordi den beder om det i naturligt sprog. Adgangsstyring, godkendelseslag og hårde grænser for, hvilke systemer en agent overhovedet kan røre ved, skal ligge i infrastrukturen omkring modellen, ikke i modellens egen fortolkning af, hvad der er en legitim instruks. Det er den samme logik, vi kender fra klassisk sikkerhed: man stoler ikke på, at brugeren altid opfører sig pænt, man bygger systemet, så det ikke kan gøre uoprettelig skade, selv når nogen forsøger at misbruge det.

For en virksomhed med agenter i produktion er den vigtigste pointe ikke, om prompt injection statistisk set rammer sjældent. Det er, at man ikke kan stole på sine eksisterende logs til at fortælle, om det er sket. Hvis en agent har adgang til at sende mails, ændre data eller udføre transaktioner, skal den grænse håndhæves af et system uden for agenten, uanset hvor godt agenten selv er instrueret i at sige nej til mistænkelige beskeder. Det er billigere at bygge de spærringer ind, før agenten går i drift, end at opdage bagefter, at man aldrig kunne have set angrebet i sine egne data.