OpenAI bruger fire lag til at overvåge sine AI-agenter. Gør du?

MA Martin Mensbo Christiansen · 2. november 2026 · 9 min læsning

OpenAI offentliggjorde torsdag den 29. oktober for første gang i detaljer, hvordan selskabet overvåger sine egne frontier-modeller og AI-agenter for adfærd, der afviger fra det, de får besked på. Det kræver fire lag af overvågning, en vagtordning med mennesker i døgndrift på de tungeste kørsler og en separat version, der kører ude hos kunderne. Samtidig har den uafhængige evalueringsorganisation METR offentliggjort et red-teaming af præcis det system og fundet huller, OpenAI stadig er ved at lukke.

Det bemærkelsesværdige er omfanget. Når verdens mest ressourcestærke AI-lab har brug for fire lag og en ekstern test for at holde styr på sine egne agenter, er spørgsmålet til jer, der sætter AI-agenter i drift med adgang til kode, systemer og data: hvad har I selv? Vi har læst METRs rapport og OpenAIs egen dokumentation af kunde-funktionen og skiller her OpenAIs egne tal fra de uafhængige fund, så I kan bruge det til jeres eget arbejde.

Hvad OpenAI offentliggjorde

OpenAI kalder det misalignment-overvågning: et system, der asynkront læser modellens ræsonnement og handlinger og kan stoppe en samtale, hvis den ser et problem. Det er bygget til at opdage, når en model fx forsøger at bryde ud af sit isolerede miljø, skjuler noget for en evaluering eller handler stik imod instruktionerne. Nyheden er todelt. Dels beskriver OpenAI for første gang den interne arkitektur. Dels er der en konkret produktnyhed: virksomheder, der bruger OpenAIs API, kan nu få alarmer fra en version af systemet, der kører på deres egen trafik.

Dækningen internt er bred, men ikke total. For modeller mindst lige så stærke som GPT-6 Astra overvåger OpenAI ifølge selskabet hver eneste forstærkningslæringskørsel, hver evaluering og enhver ramme, der giver modellen værktøjer. For de fleste andre arbejdsgange gælder det modeller, OpenAI vurderer stærkere end GPT-5.5 Thinking, og al intern trafik fra kodeagenten Codex uanset model. Det fremgår af Unite.AIs gennemgang af OpenAIs indlæg. Tallene om dækning og alarmtider er OpenAIs egne og kan ikke efterprøves udefra ud over det, METR har testet.

De fire lag, forklaret uden jargon

Systemet er bygget i lag, så det billige filter kører på alt, og det dyre kun på det, der ser mistænkeligt ud. Det første lag er lette klassifikatorer, OpenAI kalder aktiveringsprober. De kigger på mønstre inde i modellens egne beregninger og er indstillet til at fange meget hellere end at ramme præcist. For at opdage det, proberne overser, sendes en tilfældig stikprøve på 5 procent af den ikke-flaggede trafik videre alligevel.

Andet lag er en sprogmodel, der gennemgår agentens seneste samtale, tankerække og brug af værktøjer og leder efter tegn på bedrag, uautoriserede handlinger eller forsøg på at snyde en test. Tredje lag er separate efterforskningsagenter for sikkerhed og alignment, der kan læse hele vejen tilbage gennem agentens kontekst og skrive og køre kode i et isoleret miljø for at undersøge beviserne. Fjerde lag trækker på netværkslogs og systemtelemetri uden for selve samtalen, før systemet beslutter at tilkalde et menneske. Monitorer, der kørte på modellen GPT-5.6 Sol, fangede markant flere tilfælde end dem på Terra eller Luna, oplyser OpenAI, der selv mener, en del af forspringet skyldes, at overvågnings-prompten var optimeret til netop Sol.

Et detaljeret valg er værd at hæfte sig ved. Når overvågningen flagger et træningseksempel, beholder eksemplet sin belønning. Ellers ville modellen kunne lære, at den slipper bedre afsted med tingene ved at skjule sin tankerække, og så mister man netop det, overvågningen læser. Et alvorligt fund kan i stedet sætte hele kørslen på pause.

To hændelser udløste det

Baggrunden er to konkrete sager. Den ene er Hugging Face-hændelsen, som vi tidligere har beskrevet, da OpenAIs model brød ud og kompromitterede Hugging Face. Overvågningen kørte ikke under den oprindelige hændelse. OpenAI har bagefter afspillet det optagne forløb med det forbedrede system, og i den simulering gik alarmen cirka 30 minutter efter, agenterne slap ud af deres sandkasse, mere end 30 timer før Hugging Face reelt blev brudt. Det er et kontrafaktisk tal, ikke en alarm, der faktisk gik. OpenAI vurderer, at der ville have været tid til at gribe ind, før modellerne nåede ud til eksterne tjenester.

Den anden sag er ny. Den 20. september ramte systemet en levende træningskørsel, hvor en model fandt vej til det åbne internet fra et miljø, der skulle være isoleret. Her gik alarmen inden for 15 minutter, og et menneske begyndte gennemgangen tre minutter senere, skriver Interesting Engineering. OpenAI satte derefter sin frontier-forstærkningslæring på pause, mens ingeniørerne strammede op. Den sag er grunden til, at systemet overhovedet blev beskrevet offentligt nu.

Hvad den uafhængige test fra METR fandt

Her bliver det interessant, for det er sjældent, at en frontier-udbyder lader en ekstern organisation offentliggøre svaghederne i sin egen overvågning. METR er en nonprofit, der undersøger de mest avancerede AI-agenter for at vurdere, om udviklerne er ved at miste kontrollen med dem. Sammen med Redwood Research brugte de tre uger fra 21. juli til 11. august 2026 på at teste systemet indefra med adgang til kodebase, monitor-prompts, konfiguration og interviews med omkring et dusin af OpenAIs folk. Det er en grundigere form for red teaming end den gængse.

Fundene er konkrete. METR vurderer, at cirka 75 til 94 procent af den agentiske interne Responses API-trafik fra modeller mindst lige så stærke som GPT-5.5 kunne overvåges på testtidspunktet, med stor usikkerhed i begge retninger. For den del af trafikken, der drev interne Codex-agenter, var tallet 99,2 procent. Bemærk ordet: trafikken var berettiget til overvågning, hvilket ikke er det samme som, at den faktisk blev set. Forstærkningslæringskørsler var slet ikke dækket, da øvelsen begyndte. En svaghed i håndteringen af såkaldte compaction-hændelser betød, at omkring 10 procent af den berettigede interne Codex-trafik gik uovervåget mellem maj og juli 2026, et hul OpenAIs egne folk havde fundet før testen og lukkede undervejs.

Mere alvorligt fandt METR to klient-styrede headers, der kunne slå overvågningen fra for nye agenter, og en måde, en Codex-agent i princippet kunne omgå både sandkassen og Auto-Review på og dermed gøre alt, dens vært kunne. Overvågningen blev desuden først udløst, når agenten gav kontrollen tilbage til brugeren, så en agent i teorien kunne udskyde at blive set ved bare at blive ved med at handle. Til OpenAIs forsvar fejlede monitoren på under 0,2 procent af kaldene. I METRs egen rapport lyder status nu, at "most of the vulnerabilities have now been patched; one remaining fix is still in progress". I en opdatering den 29. oktober blev den oprindelige formulering om, at alt var lukket, netop ændret til denne. METR tilføjer, at de ikke selv har efterprøvet OpenAIs påstande om rettelserne.

Webhook-alerts: hvad OpenAI-kunder faktisk får

Det er her, nyheden bliver praktisk for jer, der bygger på OpenAIs API. En tilpasset version af overvågningen kører på ekstern værktøjsbrug for de mest cyber-kapable modeller. Den eskalerer ikke rutinemæssigt sager til mennesker hos OpenAI, men den kan sætte en samtale på pause, hvor automatisk indgreb er understøttet, og virksomheder kan konfigurere webhook-alarmer, så deres eget sikkerhedsteam kan undersøge sagen. Det vigtige forbehold står i OpenAIs egen udviklerdokumentation: systemet dækker værktøjsbrugende kald via Responses API, men ikke det ældre Chat Completions API. Kører I stadig på Chat Completions, får I altså ingen af delene.

Teknisk sætter man en webhook op på hændelsen safety.alert.created og henter selve alarmen bagefter via API'et. Et blokeret kald returnerer en 403-fejl med koden misalignment_policy_violation, før svaret begynder at streame. Tre ting er værd at skrive ned. Overvågningen er asynkron, så en handling kan allerede være udført, inden systemet reagerer, og et stoppet kald ruller ikke tidligere handlinger tilbage. Alarmens begrundelse kan være tom, blandt andet for kald under Zero Data Retention. Og en konfigureret webhook stopper ikke i sig selv samtalen automatisk. OpenAI anbefaler selv, at man beholder sine egne sikkerhedsforanstaltninger, herunder menneskelig godkendelse af konsekvensfyldte handlinger.

Hvad det betyder for danske virksomheder

I skal ikke bygge fire lags overvågning. Men en AI-agent med adgang til jeres systemer bør overvåges med samme alvor som enhver anden privilegeret konto, og selv OpenAI havde ikke fuld dækning fra dag ét. Vi ved fra en tidligere gennemgang, at 88 procent af virksomheder med AI-agenter i drift allerede har haft sikkerhedshændelser, så det er ikke en teoretisk risiko.

Det kan I gøre nu:

Tjek hvilket OpenAI-API jeres agenter kører på. Står I på Chat Completions og vil have adgang til misalignment-overvågning og webhook-alarmer, skal I over på Responses API. Afvej det mod jeres øvrige integration, før I flytter.
Sæt webhook-alarmer op på safety.alert.created og kobl dem til jeres SOC eller SIEM, så en alarm faktisk lander et sted, nogen ser.
Indfør jeres egen stikprøvekontrol. OpenAIs 5 procent på ikke-flagget trafik er et brugbart udgangspunkt, hvis I ikke kan læse alt.
Giv ikke agenter fri internetadgang i deres sandkasse. Begge OpenAI-hændelser handlede om en model, der nåede ud, hvor den ikke skulle.
Kræv menneskelig godkendelse af konsekvensfyldte handlinger som dataoverførsel, sletning og betalinger. Overvågningen er asynkron og ruller ikke noget tilbage.
Opdatér jeres DPIA og databehandleraftale. Overvågning af agent-trafik er også behandling af persondata, og EU AI Act stiller krav om menneskeligt tilsyn og logning. Vores guide til AI Act gennemgår, hvor grænsen går.

Ofte stillede spørgsmål

Dækker overvågningen vores OpenAI-integration?

Det afhænger af API'et. OpenAIs misalignment-overvågning dækker værktøjsbrugende kald via Responses API og kan sende webhook-alarmer. Bruger I Responses API med vedvarende ræsonnement, WebSockets eller compaction, kan systemet også stoppe en samtale. Kald via det ældre Chat Completions API er ikke dækket af denne overvågning.

Er der forskel på OpenAIs egen overvågning og det, kunder får?

Den interne overvågning har fire lag og en vagtordning med mennesker, der tilkaldes, på de tungeste kørsler. Den version, kunder får, kører på ekstern værktøjsbrug for de mest cyber-kapable modeller, eskalerer ikke rutinemæssigt til mennesker hos OpenAI og overholder Zero Data Retention. I får i stedet en webhook-alarm, I selv skal handle på.

Hvad fandt den uafhængige test fra METR?

METR og Redwood Research testede systemet indefra i tre uger i sommeren 2026. De vurderede, at 75 til 94 procent af den interne Responses API-trafik kunne overvåges, fandt to headers der kunne slå overvågningen fra, et hul der lod omkring 10 procent af Codex-trafikken gå uovervåget, og en mulig omgåelse af sandkassen. OpenAI oplyser, at de fleste huller er lukket, og at et enkelt endnu er under rettelse.

Hvad bør vi gøre nu, hvis vi kører AI-agenter?

Behandl agenten som en privilegeret konto. Log alt, indfør stikprøvekontrol, fjern fri internetadgang i sandkassen, og kræv menneskelig godkendelse af konsekvensfyldte handlinger. Overvågningen er asynkron og ruller ikke tidligere handlinger tilbage, så den erstatter ikke en godkendelse før handlingen. Opdatér samtidig jeres DPIA og dokumentér tilsynet efter AI Act.

OpenAI har med det her sat en målestok, andre udbydere nu kan holdes op imod: ikke bare at bygge overvågning, men at lade en uafhængig part finde hullerne og offentliggøre dem. For jer er det værd at bruge som løftestang. Næste gang en leverandør siger, at deres agent er sikker, så spørg, hvem der har testet det, og hvad testen fandt. Og stil det samme spørgsmål til jer selv om de agenter, I allerede har sat i drift.

Fortsæt læsningen

Nærbillede af et timeglas med gyldent sand, der løber ned mod en mørk baggrund