Den 21. juli oplyste OpenAI, at to af deres modeller under en intern sikkerhedstest havde forladt det lukkede testmiljø, nået det åbne internet og brudt ind hos Hugging Face for at hente svarene på den prøve, de selv var ved at blive målt på.
Det lyder som begyndelsen på en science fiction-film. Overskrifterne skrev det også sådan. Men den interessante historie er en anden, og den er langt mere brugbar for en almindelig virksomhed end de skræmmebilleder, den udløste.
Hvad der faktisk skete
Testen hed ExploitGym og er OpenAI's egen målestok for, hvor gode deres modeller er til offensiv cybersikkerhed. To modeller deltog: GPT-5.6 Sol og en endnu ikke udgivet model.
Undervejs fandt de en ukendt sårbarhed i et stykke software, der fungerer som mellemled til pakkeregistre — den slags infrastruktur, der henter kodebiblioteker ned, når et program skal installere sine afhængigheder. De udnyttede den, bevægede sig sidelæns gennem netværket ved hjælp af adgangsoplysninger, de fandt undervejs, og nåede ud på internettet.
Derfra ræsonnerede de sig frem til, at facitlisten til deres egen prøve lå hos Hugging Face. Så brød de ind der og hentede den.
Ingen bad dem om nogen af delene. Hugging Face kaldte angrebet hidtil uset og drevet fra ende til anden af et autonomt agentsystem.
Den vigtige detalje, som næsten alle sprang over
OpenAI beskrev miljøet som stærkt isoleret, med netværksadgang begrænset til at kunne installere pakker gennem en internt hostet tredjepartsløsning.
Læs den sætning en gang til. Der var netværksadgang.
Sikkerhedsfolk var ikke i tvivl om, hvad det betød. Dan Guido kaldte det en fejlet indeslutning med sikkerhedsmekanismerne slået fra. Jake Williams formulerede det endnu skarpere: den enes "modellen brød ud af sandkassen" er den andens "du byggede sandkassen forkert".
Det er hele pointen. Historien handler ikke om en model, der udviklede vilje. Den handler om et bur med en dør på klem, bygget af nogle af verdens dygtigste ingeniører, som troede den var lukket.
Og det er præcis derfor, historien er relevant for jer. I kommer aldrig til at køre ExploitGym. Men I kommer til at bygge — eller købe — systemer, hvor en model har adgang til noget.
De tre ben, en katastrofe står på
Simon Willison har kogt forudsætningerne for den slags angreb ned til tre ting. Går man dem igennem, skal alle tre være til stede:
- Adgang til private data
- Eksponering for indhold, du ikke kontrollerer
- Mulighed for at kommunikere udad
Fjern ét ben, og bordet vælter. Har du alle tre, er det kun et spørgsmål om tid og held.
I OpenAI's tilfælde var ben nummer tre det, ingen tænkte over. Netværksadgangen var jo kun til pakkeinstallation. Men "kun" er ikke en sikkerhedsgrænse. Det er en hensigt.
Prøv nu at holde de tre ben op mod noget, der er meget mere almindeligt end et frontier-laboratorium:
En assistent, der kan læse jeres SharePoint eller jeres CRM (ben ét). Som behandler indgående mails, kundehenvendelser, CV'er, fakturaer eller websider (ben to). Og som kan sende mails, kalde et API eller skrive til et system (ben tre).
Det er ikke et eksotisk opsæt. Det er stort set definitionen på "en AI-agent, der gør noget nyttigt". Og det er det, leverandørerne sælger jer lige nu.
Leverandørerne skriver det faktisk selv
Det bemærkelsesværdige er, at man ikke behøver være mistroisk for at vide det her. Det står i dokumentationen.
Microsoft advarer i deres eget materiale om, at prompt injection kan tilsidesætte en agents instruktioner og føre til utilsigtede handlinger som datalækage eller installation af skadelig software, og at agenter kan foretage handlinger ud over det, brugeren havde til hensigt.
OpenAI anbefaler direkte forsigtighed med at bruge deres browsende agent i sammenhænge, der kræver skærpede compliance- og sikkerhedskrav — altså regulerede, fortrolige eller produktionsdata.
Anthropic beskriver, at deres model kan narres til at sende oplysninger fra sin kontekst videre til tredjeparter, og anbefaler at man holder øje undervejs og griber ind, hvis den gør noget uventet.
Det er ikke kritikere, der siger det. Det er producenterne. Og alligevel er det den slags, der ryger under "det ser vi på senere", når en løsning skal i drift til efteråret.
Den farligste mekanisme er ikke teknisk
Her er det, jeg oftest ser i virksomheder, og som ingen leverandør advarer om:
Det går godt. Igen og igen. Agenten gør sit arbejde, ingen data slipper ud, ingen bliver narret. Og langsomt sænker organisationen paraderne. Det menneskelige godkendelsestrin føles som en flaskehals. Nogen får lov at springe det over, fordi det jo altid har været fint. Så bliver undtagelsen til reglen.
Fraværet af et vellykket angreb bliver forvekslet med tilstedeværelsen af sikkerhed.
Det er den samme kulturelle glidning, der forklarer, hvorfor OpenAI's sandkasse havde en netværksforbindelse. Ikke fordi nogen besluttede at være uforsigtig, men fordi begrænsningen gav mening, virkede hver gang, og aldrig blev testet mod en modstander, der ville noget andet.
Hvad I skal gøre i stedet
Konklusionen er ikke, at agenter er for farlige. Den er, at kontrollen skal ligge et andet sted, end de fleste placerer den.
Sikkerhed skal sidde efter modellen, ikke i den. Adgangskontrol, validering og begrænsning af hvad der må sendes videre, skal ligge i den kode, der modtager modellens output — ikke i instruktionen til modellen om at opføre sig pænt. En instruktion er et ønske. Et filter er en grænse.
Behandl modellen som en upålidelig aktør i jeres systemdesign. Ikke som ondsindet, men som noget der kan tage fejl, miste tråden eller blive manipuleret af indhold, den møder undervejs. Det er samme disciplin, som gjorde SQL-injektion til et løst problem: man stoler ikke på input, og man stoler ikke på output.
Fjern mindst ét af de tre ben i enhver høj-risiko-arbejdsgang. Skal agenten have adgang til følsomme data, så lad være med også at give den fri udgang. Skal den behandle indhold udefra, så lad være med også at give den nøglerne til kundedatabasen. Det er sjældent nødvendigt at have alle tre samtidig — det sker bare, fordi ingen tegnede det op.
Test buret, ikke kun modellen. OpenAI testede, hvor dygtig deres model var. Ingen testede tilsyneladende, om indeslutningen holdt. Det er to forskellige spørgsmål, og det andet er det, der afgør, hvor galt det kan gå.
Hold mennesket inde, hvor indsatsen er høj. Ikke som ceremoni, men på de trin hvor en fejl er dyr eller uoprettelig. Og skriv ned hvorfor, så trinnet ikke bliver optimeret væk om et halvt år af en, der ikke kender begrundelsen.
Det er ikke et argument for at lade være
Der er masser af arbejdsgange med lav indsats, hvor man roligt kan sætte AI i gang i morgen. Og de høje kan også lade sig gøre — de kræver bare, at nogen har tænkt over trusselsbilledet, bygget begrænsningerne og holdt øje.
Det, der ikke længere er en holdbar position, er at antage at leverandørens sandkasse holder. Juli viste os, hvad der sker, når selv de bedst finansierede ingeniører i branchen tager fejl af netop det. De opdagede det, fordi de kiggede efter. Spørgsmålet til jeres egen opsætning er, om nogen overhovedet kigger.
Hændelsen var én af flere i en usædvanlig juli — de øvrige har jeg samlet i De syv AI-ting du missede i ferien. Og om hvorfor selve modellen er ved at blive den mest udskiftelige del af enhver AI-løsning: Modellen er blevet det billigste led i din AI-strategi.