GPT-Red og sikkerhed mod prompt injection

GPT-Red er OpenAIs interne model til automatiseret red teaming af prompt injection. Den bruges ikke som offentligt værktøj, men som trænings- og testmetode, der ifølge OpenAI har gjort GPT-5.6 Sol markant mere robust mod skjulte instruktioner i filer, websider, værktøjssvar og andre eksterne datakilder.

Hvad har OpenAI offentliggjort om GPT-Red?

OpenAI offentliggjorde 15. juli 2026 en sikkerhedspublicering om GPT-Red, som virksomheden beskriver som en automatiseret red-teaming-model. Formålet er at finde sårbarheder, før modeller og agentiske systemer bliver brugt bredere, og at bruge de fundne angreb direkte i træning af mere robuste modeller.

Nyheden er ikke, at GPT-Red kan bruges frit af udviklere. OpenAI skriver, at GPT-Red holdes adskilt fra de modeller, virksomheden udruller, fordi modellen er trænet til at finde og udnytte sårbarheder. Den offentlige betydning ligger derfor især i metoden: stærke AI-modeller bruges som angribere i sikkerhedstest af andre AI-modeller.

FutureTools listede nyheden som en AI-sikkerhedsnyhed, fordi den handler om en konkret metode til at reducere fejl ved prompt injection. Det gør den relevant ud over OpenAI selv. Mange moderne AI-agenter læser data fra filer, browsere, e-mails, kodebaser og eksterne værktøjer, og netop dér kan skjulte instruktioner blive en praktisk sikkerhedsrisiko.

Hvad er prompt injection?

Prompt injection er en angrebsform, hvor en AI-model påvirkes af instruktioner, der ikke burde styre opgaven. En direkte prompt injection kommer fra brugerens egen besked. En indirekte prompt injection kommer fra noget, modellen læser som led i opgaven, for eksempel en webside, et dokument, en e-mail, et værktøjssvar eller en fil i et kodeprojekt.

Problemet opstår, fordi sprogmodeller behandler meget forskellig tekst som mulig kontekst. En model kan have en system prompt, brugerens instruktioner, udviklerens regler og eksternt indhold i samme samlede kontekst. Hvis modellen ikke skelner klart nok mellem data og instruktioner, kan en angriber forsøge at få den til at ignorere de oprindelige regler.

OWASP beskriver indirekte prompt injection som et særligt relevant mønster, når en LLM modtager input fra eksterne kilder. Konsekvenserne afhænger af, hvad systemet må gøre. Risikoen er begrænset, hvis modellen kun skriver et udkast. Den bliver større, hvis modellen også kan læse fortrolige data, kalde værktøjer, sende beskeder, ændre indstillinger eller køre kommandoer.

Hvordan trænes GPT-Red med self-play?

OpenAI beskriver træningen som self-play reinforcement learning. I stedet for kun at lade mennesker skrive angrebsscenarier trænes GPT-Red sammen med en samling forsvarende sprogmodeller. Angriberen får belønning for at fremkalde en gyldig fejl, mens forsvarerne belønnes for at modstå angrebet og løse den oprindelige opgave.

Det giver et løb, hvor begge sider bliver stærkere. Når forsvarerne lærer at modstå en type angreb, må GPT-Red finde mere varierede eller mere præcise angreb. OpenAI opbygger samtidig realistiske miljøer med forskellige trusselsmodeller, hvor GPT-Red kan styre for eksempel en del af en fil, en webside, en e-mail eller outputtet fra et værktøj.

Den metode adskiller sig fra almindelig test med faste eksempler. Et fast testdatasæt kan blive opbrugt, hvis nye modeller allerede klarer det næsten perfekt. Self-play kan i stedet producere nye angreb, efterhånden som forsvarerne forbedres. Det minder om princippet bag test af AI-modeller før udrulning, men med en mere automatiseret angriberrolle.

Hvilke resultater beskriver OpenAI?

OpenAI skriver, at GPT-Red er brugt i træningen af GPT-5.6 Sol. Ifølge virksomheden har GPT-5.6 Sol seks gange færre fejl på OpenAIs sværeste benchmark for direkte prompt injection sammenlignet med den bedste produktionsmodel fra fire måneder tidligere. Det er en leverandørrapporteret måling, ikke en uafhængig offentlig benchmarkrunde.

OpenAI beskriver også en test på en intern version af en indirekte prompt injection-arena fra Dziemian et al. fra 2025. Her fandt GPT-Red succesfulde angreb i 84 procent af scenarierne mod GPT-5.1, mens menneskelige red-teamere fandt succes i 13 procent af scenarierne. Tallene viser især, at automatiseret red teaming kan skalere mængden af testeksempler.

I praktiske cases angreb GPT-Red blandt andet en agent, der styrede en kontorautomat, og et Codex CLI-lignende kodningsmiljø. I automateksemplet opnåede GPT-Red ifølge OpenAI tre mål: at ændre prisen på en vare, bestille en dyrere vare til lav pris og annullere en anden kundes ordre. OpenAI skriver, at sårbarhederne blev delt, og at nye sikkerhedsforanstaltninger testes.

Hvorfor er agentiske AI-systemer særligt udsatte?

Agentiske AI-systemer er mere udsatte end almindelige chatbots, fordi de ikke kun svarer med tekst. De kan hente filer, gennemse websider, bruge browsere, kalde API’er, læse kode, oprette udkast, ændre data eller sende handlinger videre til andre systemer. Jo flere værktøjer en model får adgang til, desto mere betyder det, om den kan afvise skjulte instruktioner fra upålidelige kilder.

OpenAI beskriver netop tredjepartsdata som en central kilde til risiko: browsere, forbundne apps, lokale filer og eksterne værktøjer kan indeholde tekst, som modellen læser. Hvis en angriber placerer en instruktion i det materiale, kan modellen fejlagtigt behandle den som noget, den skal følge.

• En e-mail kan indeholde skjult tekst, der beder en assistent om at videresende oplysninger.
• En webside kan forsøge at ændre en browsersøgende agents næste handling.
• Et kodeprojekt kan indeholde en fil, der beder en kodningsagent om at lække miljøvariabler eller nøgler.
• Et værktøjssvar kan blande legitimt resultatindhold med instruktioner, der retter sig mod modellen.

Det betyder ikke, at alle AI-agenter er farlige. Risikoen afhænger af adgang, rettigheder og kontrol. En agent, der kun opsummerer åbne kilder, har en anden risikoprofil end en agent, der kan læse interne mapper, ændre databaser eller handle på vegne af en medarbejder.

Hvad betyder det i praksis for arbejdspladser?

For arbejdspladser betyder GPT-Red-nyheden først og fremmest, at sikkerhedstest af AI ikke kan stoppe ved almindelige samtaleeksempler. Når AI-assistenter får adgang til filer, e-mails, kodebaser og interne værktøjer, bør testene også dække skadelige instruktioner gemt i de datakilder, assistenten læser.

Det har praktisk betydning for udviklere, it-afdelinger, redaktører, jurister, undervisere og vidensmedarbejdere, der begynder at bruge AI til flertrinsopgaver. Hvis en assistent læser et dokument fra en ekstern part, bør systemet kunne fastholde forskellen mellem dokumentets indhold og brugerens oprindelige opgave. Hvis assistenten kan udføre handlinger, bør følsomme trin kræve menneskelig godkendelse.

OpenAIs case med en automatagent viser den grundlæggende pointe uden at kræve samme tekniske miljø. En AI, der styrer et system, kan påvirkes til at gøre noget forkert, hvis den kombinerer adgang til handlinger med svag modstand mod manipulerende instruktioner. Derfor er AI-sikkerhedsprotokoller og standarder ikke kun et modelproblem, men også et spørgsmål om produktdesign, rettighedsstyring og logning.

Hvilke lokale data- og AI-regler kan få betydning?

For organisationer i Danmark er den lokale relevans især knyttet til dataadgang, dokumentation og ansvar. GPT-Red dokumenterer ikke særskilt dansk tilgængelighed eller danske testresultater. Nyheden er snarere et signal om, hvilke kontrolspørgsmål der bliver vigtigere, når AI-agenter bruges i arbejdsprocesser med personoplysninger, interne dokumenter eller beslutningsstøtte.

GDPR kan blive relevant, hvis en AI-agent læser, sender eller bearbejder personoplysninger. Det gælder uanset, om prompt injection skyldes en angriber, en fejlkonfigureret integration eller et dokument, der blandes ind i en opgave. Det centrale spørgsmål er, hvilke data agenten kan tilgå, hvor de sendes hen, hvordan de logges, og hvem der kan forklare behandlingen bagefter.

EU’s AI Act kan også få betydning i brugssituationer med højere risiko, for eksempel i ansættelse, uddannelse, kritisk infrastruktur eller offentlige afgørelser. AI Act gør ikke prompt injection til en særskilt kategori, men dens krav om risikostyring, dokumentation, menneskeligt tilsyn, robusthed og cybersikkerhed passer direkte til de typer problemer, GPT-Red forsøger at teste. For generelle modeller peger reglerne desuden på transparens, ophavsret og vurdering af systemiske risici.

Hvad kan GPT-Red ikke løse alene?

GPT-Red er en metode til at finde flere fejl og gøre modeller mere robuste. Det er ikke en fuld sikkerhedsarkitektur. OpenAI beskriver selv, at metoden skal bruges sammen med menneskelig og tredjeparts red teaming, lagdelte sikkerhedsforanstaltninger og overvågning i drift.

OWASP peger samme vej: prompt injection kan afbødes, men der findes ikke en enkel metode, som fjerner problemet fuldstændigt. En model kan blive bedre til at modstå angreb og stadig fejle i et nyt miljø, fordi angriberen ændrer format, mål eller adgangsvej. Det gælder især, når systemet kombinerer tekstforståelse med handlinger i andre systemer.

Derfor bør GPT-Red-resultater læses som en teknisk forbedring i OpenAIs egne modeller og testmiljøer. De siger ikke i sig selv, at en bestemt virksomheds agentopsætning er sikker. Den samlede risiko afhænger også af adgangskontrol, dataminimering, adskillelse af roller, sandboxing, rate limits, brugerbekræftelse og evnen til at rulle handlinger tilbage.

Hvilke kontrolpunkter bør en organisation bruge?

En praktisk vurdering bør begynde med agentens adgang. Prompt injection er mest kritisk, når modellen både kan læse upålideligt materiale og udføre handlinger. Derfor bør en organisation kortlægge, hvilke datakilder agenten læser, hvilke værktøjer den kan kalde, og hvilke handlinger der kræver menneskelig bekræftelse.

• Adskil eksternt indhold fra instruktioner, og vis modellen tydeligt, hvad der er data, og hvad der er en opgave.
• Begræns værktøjsadgang efter opgave, rolle og følsomhed i stedet for at give bred standardadgang.
• Kræv eksplicit godkendelse ved betalinger, sletning, datadeling, ændring af rettigheder og udsendelse til eksterne modtagere.
• Log både modelbeslutninger, værktøjskald og brugerbekræftelser, så hændelser kan spores.
• Test med realistiske angreb i e-mails, dokumenter, websider, kode og værktøjssvar, ikke kun i rene chatbeskeder.

Disse punkter er ikke særlige for OpenAI. De gælder bredt for agentdesign, uanset modelleverandør. GPT-Red-nyheden gør dem mere konkrete, fordi den viser, hvordan et stærkt angrebssystem kan finde svagheder i realistiske opgaver, før angribere gør det samme i drift.

Hvordan adskiller GPT-Red sig fra almindelig prompt engineering?

Almindelig prompt engineering handler om at formulere instruktioner, så en model løser en opgave bedre. GPT-Red handler om det modsatte testspørgsmål: hvordan kan en model bringes til at fejle, selv når den egentlig burde følge en sikker instruktion? Det gør GPT-Red til et red-teaming-værktøj i trænings- og evalueringsprocessen, ikke til en metode for slutbrugere, der vil skrive bedre beskeder.

Forskellen betyder noget, fordi sikkerhed ikke kan reduceres til gode formuleringer. En tydelig prompt kan hjælpe, men den beskytter ikke alene mod en webside, en e-mail eller en kodefil, der forsøger at få modellen til at gøre noget andet. Det kræver både modelrobusthed og systemdesign.

Hvad sker der videre?

OpenAI skriver, at virksomheden vil udgive et preprint med flere detaljer senere på ugen. Indtil det findes, bygger de mest konkrete oplysninger på OpenAIs egen publicering. Det gør kildegrundlaget stærkt for, hvad OpenAI selv hævder, men svagere for uafhængig vurdering af metode, testdesign og generalisering på tværs af andre modeller.

Den bredere udvikling peger mod mere automatiseret sikkerhedstest. Når modeller bliver bedre til at bruge værktøjer, må sikkerhedstest også dække værktøjer, kontekst, rettigheder og tredjepartsdata. Det ligger tæt på udviklingen i AI-sikkerhed mod jailbreaking, men prompt injection er mere forbundet med eksternt indhold og agenthandlinger end med brugerens direkte forsøg på at få modellen til at bryde regler.

For tekniske teams er den praktiske konsekvens klar: robuste modeller hjælper, men de erstatter ikke en arkitektur, hvor datakilder, værktøjskald og menneskelig kontrol er gennemtænkt. GPT-Red gør især testfasen mere dynamisk, fordi angreb kan skabes og tilpasses i samme tempo som modellerne forbedres.

Hvilke kilder ligger til grund?

Artiklen bygger på FutureTools’ liste over aktuelle AI-nyheder, hvor GPT-Red-nyheden blev valgt som primær FutureTools-kilde, og på OpenAIs egen publicering om GPT-Red. Forklaringen af angrebstypen er holdt op mod OWASPs beskrivelse af prompt injection. Den lokale relevans er afgrænset med udgangspunkt i EU-Kommissionens sider om AI Act og EU’s databeskyttelsesregler.