Prompt injection: Giv ikke AI-funktionen mere magt, end en fejl må få

Find forskellen på hjælp og handlekraft

Risikoen afhænger ikke kun af modellen. Den afhænger af, hvad appen sender ind, hvilke data modellen kan se, og hvad dens svar kan sætte i gang. Kortlæg derfor hvert AI-forløb fra input til mulig virkning, før medarbejdere eller kunder får adgang.

Læsning og forslag

Opsummering, kladde eller klassifikation, som en bruger efterfølgende vurderer. Fejl kan stadig afsløre data eller føre til en forkert beslutning.

Handling i andre systemer

Mail, sletning, betaling, adgangsændring eller opdatering af kundedata. Her kan ét forkert værktøjskald få direkte konsekvenser.

Skriv for hvert forløb: tilladte brugere, datakilder, modelleverandør, mulige handlinger, højeste skade, kontrol før handling, logning og nødstop. En chatbot uden værktøjer og en agent med skriveadgang skal ikke have samme sikkerhedsdesign.

Behandl tekst, filer og websider som data – ikke instruktioner

Ved direkte prompt injection forsøger brugeren at ændre AI-funktionens opgave. Ved indirekte prompt injection ligger instruktionen i eksempelvis en mail, PDF, webside, billede eller et søgeresultat, som modellen bliver bedt om at behandle. Det eksterne indhold kan derfor påvirke modellen, selv om appens bruger ikke skrev angrebet.

• Markér oprindelsen: Hold brugerens opgave, appens faste regler og hentet indhold adskilt i dataflowet.
• Læg ikke ubetroet tekst i en privilegeret instruktion: En mailtekst eller fil må ikke flettes ind i system- eller udviklerinstruktionen som betroet kode.
• Udtræk kun det nødvendige: Lad et afgrænset trin finde konkrete felter frem for at sende fri tekst videre til et trin med værktøjer.
• Bevar kilden: Vis brugeren det relevante originaludsnit, så en opsummering eller beslutning kan kontrolleres.

Gør modelsvaret lille, struktureret og kontrollerbart

Fri tekst er nyttig til en kladde, men farlig som direkte kommando. Når et svar skal bruges af kode, så bed modellen om et fast schema med kendte felter og valgmuligheder, og kontrollér resultatet deterministisk på serveren.

1. Tilladte handlinger: Brug en kort allowliste som opret_kladde eller find_sag – ikke et frit funktionsnavn eller en kommando.
2. Stramt schema: Afvis ekstra felter, forkert type, ugyldigt id, for lang tekst og værdier uden for de tilladte valg.
3. Ny rettighedskontrol: Kontrollér bruger, virksomhed, datapost og handling igen, når serveren modtager modellens forslag.
4. Forretningsregler i kode: Beregn beløb, statusskift, modtagere og grænser i betroet kode – ikke ud fra modellens fritekst.

Struktureret output reducerer frie kanaler, men beviser ikke, at værdien er sand eller tilladt. Et korrekt formateret kunde-id kan stadig tilhøre en anden virksomhed.

Giv værktøjer mindst mulig adgang

En model bør kun kunne foreslå eller kalde de få værktøjer, som den konkrete funktion kræver. Hvert værktøj skal selv håndhæve adgang, inputregler og konsekvens – præcis som et almindeligt API-endpoint.

• Brug en særskilt teknisk identitet med mindst mulige rettigheder og helst kort levetid frem for en bred administratornøgle.
• Bind tenant, bruger og tilladte objekter på serveren; lad ikke modellen vælge en anden virksomhed via et argument.
• Adskil læse- og skriveværktøjer, og gør kun de nødvendige værktøjer tilgængelige i det aktuelle trin.
• Sæt loft over antal kald, datamængde, samtidighed, køretid og omkostning for både bruger og virksomhed.
• Gør gentagne skriveforsøg sikre, så timeout eller genkørsel ikke sender samme mail, betaling eller ændring flere gange.

Den almindelige model for server-side adgang er beskrevet iguiden om roller og rettigheder.

Kræv en rigtig godkendelse før høj risiko

Menneskelig godkendelse virker kun, hvis personen kan se, hvad der faktisk sker. Vis handling, mål, modtager, ændrede felter og relevant kilde, og udfør først handlingen efter et nyt, tydeligt ja.

• Godkend konkrete data: “Send denne tekst til disse tre adresser” er bedre end “Fortsæt”.
• Genbekræft følsomme handlinger: Sletning, udbetaling, rettighedsændring og ekstern kommunikation bør ikke gemmes som et generelt forhåndssamtykke.
• Kontrollér igen ved udførelse: En gammel godkendelsesskærm må ikke kunne genbruges efter data, rolle eller modtager er ændret.
• Giv en sikker vej ud: Brugeren skal kunne afvise, redigere eller gemme som kladde uden at miste arbejdet.

Ved høj konsekvens kan den rigtige beslutning være, at AI-funktionen aldrig får lov til at udføre handlingen – kun udarbejde et forslag til et eksisterende, kontrolleret arbejdsflow.

Behandl modeloutput som ubetroet input

Et svar fra modellen kan indeholde forkerte fakta, usikre links, markup eller tekst, der bliver farlig i næste system. Vis almindelig tekst som tekst, sanitér nødvendig formatering, og brug aldrig modeloutput direkte som SQL, shell-kommando, HTML eller kode, der bliver udført.

• Kontrollér links, filnavne, id'er, formater og længder før brug eller visning.
• Kræv dokumenterbare kilder, når svaret bruges til faktuelle eller faglige beslutninger, og gør originalmaterialet let at åbne.
• Skeln tydeligt mellem AI-forslag, brugerens godkendelse og systemets bekræftede resultat.
• Send ikke hele prompten og svaret til logs som standard; de kan indeholde persondata, kundedata eller angriberens indhold.

NIST fremhæver blandt andet risikoen for overbevisende forkerte svar og overdreven tillid til automatisering. En velformuleret tekst er derfor ikke i sig selv et bevis på, at resultatet er korrekt.

Test hele kæden – også når nogen prøver at snyde

Gem et lille sæt realistiske testforløb og kør dem igen, når prompt, model, datakilde, værktøj eller rettighed ændres. Mål både svarets kvalitet og om de faste sikkerhedsgrænser holder.

1. En bruger beder direkte modellen ignorere reglerne, afsløre skjulte instruktioner eller bruge et ikke-tilladt værktøj.
2. En mail, PDF eller webside indeholder en skjult besked om at sende data, ændre mål eller hente flere oplysninger.
3. Modellen returnerer et gyldigt schema med en anden kundes id, en ikke-tilladt handling eller en ekstrem værdi.
4. En bruger afviser godkendelsen, ændrer rolle undervejs eller åbner en gammel godkendelsesadresse igen.
5. Værktøjet svarer langsomt, delvist eller uklart, og samme handling forsøges igen.
6. Modellen giver et sikkert formateret, men faktuelt forkert svar med en opdigtet eller irrelevant kilde.

Overvåg adfærd og gør funktionen mulig at stoppe

Registrér de hændelser, der gør et forløb forståeligt uden at kopiere alt indhold: bruger og tenantreference, model- og workflowversion, datakilder, foreslået værktøj, godkendelse, udført resultat, fejl, varighed og forbrug. Alarmér på afviste rettighedskald, usædvanligt mange værktøjskald og pludselige ændringer i fejl eller omkostning.

• Versionér prompts, schemas, værktøjsdefinitioner og evalueringssæt sammen med koden.
• Brug et feature flag eller nødstop, der kan slå skriveværktøjer fra uden at fjerne resten af appen.
• Bevar et manuelt alternativ, hvis AI-funktionen eller leverandøren ikke kan bruges sikkert.
• Aftal hvem der undersøger en hændelse, roterer adgang og beslutter genåbning.

Typiske fejl

• “Ignorér ondsindede instruktioner” står alene: Prompten bliver behandlet som hele sikkerhedsdesignet.
• En administratornøgle gives til alle værktøjer: En lille AI-funktion får adgang til hele systemet.
• Hentet indhold bliver betroet: Tekst fra mail, filer, søgning eller en database får lov at ændre opgaven.
• JSON bliver automatisk anset som sikkert: Formatet er gyldigt, men objekt, beløb eller handling er stadig forkert.
• Godkendelsen er uklar: Brugeren ser “Fortsæt” uden modtager, data og konsekvens.
• Modellen kan både læse og skrive alt: Ét kompromitteret dokument kan koble følsomme data med en ekstern handling.
• Kun glade forløb testes: Ny model eller prompt udgives uden faste angrebs- og fejltests.
• Hele samtalen logges: Fejlsøgning skaber et nyt lager af persondata, secrets og kundemateriale.

Tjekliste før AI-funktionen får rigtige brugere

• ☐ Hvert AI-forløbs input, datakilder, mulige handlinger og højeste konsekvens er kortlagt.
• ☐ Brugerinput, eksternt indhold og faste instruktioner holdes adskilt.
• ☐ Ubetroet tekst flettes ikke ind i system- eller udviklerinstruktioner.
• ☐ Data mellem trin er afgrænset med faste felter og tilladte værdier, hvor det er muligt.
• ☐ Serveren validerer schema, forretningsregler, bruger, tenant og objekt ved hvert værktøjskald.
• ☐ AI-funktionen har kun de nødvendige læse- og skriverettigheder.
• ☐ Sletning, betaling, adgangsændring og ekstern kommunikation kræver konkret godkendelse eller er helt udelukket.
• ☐ Modeloutput behandles som ubetroet input før visning, lagring eller brug i et andet system.
• ☐ Brugeren kan se originalkilden og forstå, hvad der er forslag, godkendt handling og bekræftet resultat.
• ☐ Direkte og indirekte prompt injection, forkert output, gentagelser og afvist godkendelse er testet.
• ☐ Logs giver et brugbart spor uden som standard at gemme hele prompts, svar eller følsomme dokumenter.
• ☐ Der findes alarmer, en ejer, et nødstop og et manuelt alternativ.

Relaterede guides

Officielle kilder

Modeller, leverandørfunktioner og angrebsmetoder ændrer sig. Brug de aktuelle kilder til den konkrete model og platform, og gentag jeres tests, når dataflow, rettigheder, værktøjer eller model ændres.

• OWASP: Prompt Injection (LLM01:2025)
• OWASP: Usikker håndtering af modeloutput (LLM05:2025)
• OWASP: For omfattende handlefrihed (LLM06:2025)
• OpenAI: Safety in building agents
• OpenAI: Safety best practices
• Microsoft: Defend against indirect prompt injection attacks
• NIST: Generative AI Profile til AI Risk Management Framework