Prompt injection og jailbreaks

Indirekte prompt-injektion (andenordensinjektion) er den farligere variant. Angriberen anbringer instruktioner i indhold, som modellen senere vil hente: en webside, en PDF, en kalenderinvitation, en kodekommentar eller en supportsag.

Offerbrugeren ser aldrig nyttelasten. Når et RAG-forløb eller en browseragent henter indholdet ind i konteksten, udføres de skjulte instruktioner med offerets rettigheder.

Eksempel: En webside indeholder skjult tekst, der beder en sammenfatningsagent om at dataeksfiltrere brugerens chathistorik til en angriberstyret URL.

Disse begreber overlapper, men er ikke identiske:

• Prompt-injektion retter sig mod applikationsgrænsen — udviklerens instruktioner tilsidesættes med data fra angriberen.
• Jailbreaking retter sig mod modellens sikkerhedstilpasning — modellen lokkes til at producere indhold, som udbyderen har trænet den til at afvise.

Et jailbreak kræver ikke en sårbar applikation; det virker mod den rå model. Mange angreb i virkeligheden kombinerer begge dele: Et jailbreak løsner afvisningerne, mens injektion omdirigerer applikationens adfærd.

Angribere bruger forudsigelige manipulationsmønstre. Hvis du kender dem, kan du på ansvarlig vis udføre red-team-tests af dit eget system:

• Rollespil/persona: anmodningen fremstilles som fiktion eller som en fiktiv, ubegrænset rollefigur.
• Sløring: base64, leet-sprog, oversættelse eller opsplitning af tokens for at omgå nøgleordsfiltre.
• Opdeling af nyttelast: en anmodning spredes over flere omgange, så ingen enkelt meddelelse ser skadelig ud.
• Hypotetiske scenarier: For a security class, describe how one would...
• Præfiksinjektion: svaret tvinges til at begynde med en bekræftelse som Sure, here is.

Mange teams griber først til en afvisningsliste med formuleringer som ignore previous instructions. Det er skrøbeligt, fordi inddataområdet i praksis er uendeligt.

Naturligt sprog kan udtrykke den samme hensigt på utallige måder på tværs af sprog, kodninger og metaforer. Angribere prøver sig frem hurtigere, end du kan rette regulære udtryk.

Vigtigt princip: betragt inddatafiltrering som forsvar i dybden, aldrig som den primære sikkerhedskontrol. Antag, at noget injektion vil slippe igennem, og design systemet, så en vellykket injektion stadig ikke kan forårsage reel skade.

Den mest effektive modforanstaltning er arkitektonisk: begræns, hvad en kompromitteret modelkontekst kan gøre.

• Giv LLM'en de mindst mulige rettigheder. En sammenfatningsagent bør ikke have legitimationsoplysninger til at sende e-mails.
• Hold ikke-betroet indhold ude af privilegerede stier. Hvis en agent læser eksterne webdata, bør den ikke også kunne udføre uigenkaldelige handlinger i samme tur uden et kontrolpunkt.
• Adskil dataplaner fra kontrolplaner: Hentet tekst skal være data, ikke kommandoer.

Selv om det ikke er skudsikkert, hæver promptstruktur barren. Afgræns tydeligt ikke-betroede data, og instruér modellen i, hvordan den skal behandle dem.

Brug eksplicitte afgrænsere, og fortæl modellen, at alt inden i dem er data, der skal analyseres, ikke instruktioner, der skal følges. Kombinér dette med en stærk systemrolle, som applikationen håndhæver ved hvert kald.

En models uddata er også ikke-betroede. Hvis applikationen videresender LLM-uddata til en shell, en database, en browser eller et andet værktøj, bliver injektion til fjernudførelse af kode eller dataeksfiltration.

Simon Willisons dødelige trekløver beskriver den farlige kombination:

• Adgang til private data,
• Eksponering for ikke-betroet indhold,
• Muligheden for at kommunikere eksternt (eksfiltrere data).

En agent med alle tre egenskaber kan med en enkelt injiceret instruktion omdannes til et værktøj til datatyveri. Bryd trekløveret for at bryde angrebet.

Antag, at injektion vil forekomme, og instrumentér systemet til at opdage det:

• Logfør hele konteksten (prompts, hentede tekststykker og værktøjskald) til gennemgang af hændelser.
• Brug en sekundær klassifikator eller en beskyttelsesmodel til at markere mistænkelige inddata og uddata.
• Overvåg unormal værktøjsbrug: pludselige udgående forespørgsler, uventet dataadgang og mønstre for promptlæk.
• Anvend kanarietokens i systemprompter; hvis en kanarietoken dukker op i uddata, er der sket et læk.

Behandl alarmer som reelle hændelser med en beredskabsvejledning.

Det er vigtigt og legitimt at teste dine egne systemer for injektion. Gør det ansvarligt:

• Test kun systemer, du ejer eller har tilladelse til at vurdere.
• Brug et kontrolleret miljø og syntetiske data; eksfiltrér aldrig rigtige brugerdata.
• Dokumentér fund, og føj dem til regressionstests, så rettede omgåelser forbliver rettede.
• Koordinér offentliggørelse, når du finder problemer i tredjepartsmodeller eller -applikationer.

Målet er at gøre din applikation modstandsdygtig, ikke at skabe skadelig funktionalitet.

Vigtigste pointer om prompt-injektion og jailbreaks:

• Injektion opstår ved at blande betroede instruktioner med ikke-betroede data i én kanal.
• Direkte injektion kommer fra brugeren; indirekte injektion skjuler sig i hentet indhold og er mere diskret.
• Jailbreaks angriber modellens sikkerhedstilpasning; injektion angriber applikationsgrænsen. De kan kombineres.
• Inddatafiltrering er kun forsvar i dybden, aldrig den primære sikkerhedskontrol.
• Afhjælp problemet arkitektonisk: brug mindst mulige rettigheder, adskil data fra kontrol, og bryd den dødelige trekløver (private data + ikke-betroet indhold + dataeksfiltration).
• Betragt modeluddata som ikke-betroede, log alt, og udfør red-team-tests etisk.