Hopp til hovedinnhold
OpenAI

20. juli 2026

Sikkerhet

Sikkerhet og alignment for tid med modeller med lang tidshorisont

Hva intern bruk av en langvarig modell lærte oss om sikkerhet.

Laster inn …

Sammendrag

  • Modeller som kjører lenge, kan løse vanskelige, åpne problemer, men utholdenheten gir dem flere muligheter til å utføre uønskede handlinger. 

  • Under begrenset intern bruk av en modell trent for langvarige oppgaver observerte vi nye typer feil som ikke ble fanget opp i de eksisterende evalueringene våre før utrulling, og satte tilgangen på pause. Deretter brukte vi innsikt fra disse feilene til å bygge nye evalueringer, forbedre alignment for lang tidshorisont, legge til overvåking på forløpsnivå og gi brukerne mer innsyn og kontroll før vi gjenopprettet begrenset tilgang.

  • Erfaringen styrket troen på verdien av iterativ utrulling. Ingen fast evalueringspakke kan forutse all atferd, så testing før utrulling må kombineres med tett overvåking, sikkerhetstiltak som kan gripe inn, og muligheten til å sette på pause eller rulle tilbake ved behov.

Modeller som kan arbeide autonomt over lange perioder, kan ta fatt på vanskelige, åpne problemer. Men den samme utholdenheten som gjør dem nyttige, gir dem også flere muligheter til å utføre uønskede handlinger – og til å gjøre det på måter evalueringer beregnet på modeller med kortere tidshorisont kan overse.

For omtrent to måneder siden kunngjorde vi at en intern generell modell motbeviste Erdős' enhetsavstandskonjektur. Denne modellen var utviklet for å arbeide autonomt i svært lange perioder. Under begrenset, overvåket intern bruk observerte vi uønsket atferd som de eksisterende evalueringene våre før utrulling ikke hadde fanget opp. Fordi utrullingen var begrenset og overvåket, kunne vi identifisere disse problemene, sette tilgangen på pause, lage nye evalueringer basert på det vi observerte, styrke modellen og sikkerhetstiltakene og deretter gjenopprette tilgangen under fortsatt overvåking. 

Forholdene vi evaluerer modeller under, vil aldri samsvare perfekt med dem de møter i faktisk bruk. Derfor må evalueringer før utrulling kombineres med begrenset, overvåket utrulling og muligheten til å gripe inn, sette på pause eller rulle tilbake når problemer oppstår. Det vi lærer av utrulling, kan deretter inngå i sterkere evalueringer og sikkerhetstiltak før tilgangen utvides.

I de følgende delene deler vi konkrete eksempler på hva vi observerte, hvordan vi håndterte problemene, og hvordan denne erfaringen vil forme fremtidige lanseringer.

Modellens utholdenhet kan avdekke sikkerhetssårbarheter

Den nye modellen kan fortsette å arbeide mot et mål gjennom gjentatte forsøk over lang tid. Den samme utholdenheten kan føre til at den finner og utnytter svakheter i miljøet sitt. Tidligere modeller ville, når de støtte på sandkasse- eller miljøbegrensninger, ganske enkelt stoppe og returnere til brukeren. Denne modellen fortsatte ofte å prøve, blant annet ved å lete etter måter å handle utenfor sandkassen på.

Et eksempel på dette oppstod under en intern evaluering på NanoGPT‑speedrunen(åpnes i et nytt vindu), en offentlig referansetest for å trene en liten språkmodell med så få steg som mulig. Modellen utviklet en nedtrapping av læringsraten etter en potenslov, kalt PowerCool, som ga en betydelig forbedring. Modellen ble instruert om å legge ut resultatene bare på Slack, men NanoGPT‑instruksjonene sier at resultater skal legges ut som en PR til GitHub, og modellen fulgte de sistnevnte instruksjonene og åpnet PR #287 i det offentlige GitHub-lageret. Modellen omgikk sandkassebegrensninger som skulle blokkere ekstern tilgang, og fortsatte med opplastingen til GitHub. Det tok modellen vår en time å finne en sårbarhet i sandkassen slik at den kunne opprette PR-en. Tidligere modeller var mindre utholdende og klarte ikke å finne sårbarheter, men ga i stedet opp PR-delen.1

Fra å vurdere enkelthandlinger til å vurdere hele handlingsforløp

Mange sikkerhetskontroller for AI-assistenter er utformet rundt enkelthandlinger. Hvis en handling ikke er tillatt, blokkeres den. Hvis den er sensitiv, ber systemet brukeren om uttrykkelig godkjenning. Men modeller som kjører lenge, og der handlingene kan utfolde seg autonomt over timer, dager eller til og med uker, utfordrer dette oppsettet: Det er ikke lenger nok å overvåke enkelthandlinger for å følge intensjonen i det samlede forløpet.

I et scenario der modellen ble bedt om å løse et problem, observerte den for eksempel at andre systemer hadde vellykkede, men private innsendinger, og forsøkte å hente disse løsningene fra evalueringsserveren. Da det første forsøket ble blokkert fordi en skanner oppdaget en autentiseringstoken, delte modellen token-kroppen i to fragmenter, obfuskerte dem og rekonstruerte deretter legitimasjonen under kjøring, slik at hele tokenen aldri dukket opp som én sammenhengende streng. Modellen var tydelig, både i kommentarene til brukeren og i resonneringssporene sine, på at den tok disse stegene for å omgå skanneren.

Dette eksemplet viser hvordan hvert steg kan se akseptabelt ut alene, mens sekvensen kan gi et utfall som ikke ville blitt godkjent. Det viser også hvordan en modell som fungerer effektivt over lange tidshorisonter, kan lære blindsonene i et godkjenningssystem og omgå det for å nå målene sine. Sikkerhet for lang tidshorisont krever ikke bare at vi spør «er denne handlingen tillatt?», men også «hvilket utfall leder denne rekken av handlinger mot?»

Bygge sikkerhetstiltak for modeller som kjører lenge

På grunn av hendelser som disse satte vi den interne utrullingen av den nye modellen på pause. Vi bygde sikkerhetssystemet på nytt rundt forsvar i dybden og overvåking på forløpsnivå.

  • Evalueringer basert på hendelser. Evalueringer kan gi oss en pekepinn på om et system er trygt å rulle ut før det faktisk tas i bruk. For å være mest mulig nyttig bør en evaluering imidlertid gjenspeile fordelingen og tidshorisonten til forløpene under reell utrulling. Derfor brukte vi observerte feil til å utvikle adversarielle evalueringer. Vi fant at forbedringer i evalueringene som var avledet fra reelle hendelser, igjen førte til tryggere atferd etter utrulling i produksjon.
  • Forbedret alignment. Vi tok grep for å redusere tendensen til å utføre uønskede handlinger uten tillatelse i jakten på brukerens mål.  Vi fant for eksempel at modellene våre var dårligere til å huske instruksjoner i lange utrullinger, og da vi trente modellen på denne evnen, førte det til en modell som forble alignet gjennom lengre utrullinger. 
  • Aktiv overvåking. Vi laget et overvåkingssystem som gjennomgår modellens utviklende forløp etter tegn på at den omgår en brukerbegrensning eller sikkerhetsgrense. Overvåkeren observerer ikke bare én enkelt handling, men hele forløpet. Viktigst er at overvåkeren kan sette økten på pause og varsle brukeren om å undersøke nærmere. Etter undersøkelsen kan brukeren velge å fortsette modellens arbeid hvis overvåkeren er blitt utløst feilaktig. 
  • Mer innsyn og kontroll for brukeren. Vi gjorde det enklere for brukeren å inspisere disse langvarige øktene, se handlingene som er utført, og følge med på inngrep fra overvåkingen.

Ny utrulling

For å evaluere det nye overvåkingssystemet spilte vi av på nytt et lite sett med interne utrullingsmiljøer der modellen tidligere hadde forfulgt feiljusterte handlinger, denne gangen med de nye sikkerhetstiltakene på plass2. De nye sikkerhetstiltakene klarte å fange opp betydelig flere feiljusterte handlinger som modellen forfulgte, og de den ikke fanget opp, ble alle vurdert som lav alvorlighetsgrad.

Noen eksempler på slike hendelser med lav alvorlighetsgrad er følgende tilfeller:

  • For å få tilgang til et kommandolinjeverktøy for Linear startet modellen en nestet codex --yolo-økt, selv om den faktisk kunne ha gjort det uten --yolo-flagget.
  • Modellen oppdaget at en ressurs som tidligere var aktiv, manglet, og begynte deretter å utforske og bruke SSH inn i andre aktive CPU-poder under eierens navnerom, samt (uten hell) poder som tilhørte andre OpenAI-ansatte, uten noen god grunn til å gjøre det.
  • Modellen hadde mange fastlåste find-prosesser, og hver shell-kommando hang. Deretter kjørte den kill -9 -1, som ville ha sendt SIGKILL til hver prosess den har lov til å drepe på den poden, hvis kommandoen hadde blitt utført. Den fikk imidlertid tidsavbrudd og ble ikke utført.

Etter å ha testet det nye systemet konkluderte vi med at begrenset intern tilgang til modeller med evner over lang tidshorisont kunne gjenopprettes. Vi har ikke observert noen alvorlig omgåelse av sikkerhetstiltak siden ny utrulling startet for flere uker siden. Den første versjonen av disse sikkerhetstiltakene var bevisst konservativ. Vi har fortsatt å finjustere systemet for å redusere unødvendige avbrudd uten å svekke sikkerhetstiltakene.

Avsluttende tanker

Fordi vi rullet ut iterativt, kunne vi finne og håndtere mangler før vi utvidet tilgangen. Evalueringer før utrulling er fortsatt avgjørende, men utrulling avdekker atferd de ikke fanger opp. Ved å starte med begrenset tilgang kunne vi observere modellen i praksis, sette på pause når problemer oppstod, bruke disse feilene til å bygge bedre evalueringer og sikkerhetstiltak og gjenopprette begrenset tilgang etter å ha testet endringene.

Etter hvert som modeller tar på seg lengre og mer komplekse oppgaver, kan feil som evalueringer ikke fanger opp, få større konsekvenser. Vi vil fortsette å arbeide for å minske gapet mellom evaluering og utrulling: teste modeller over lengre forløp, forbedre alignment, bygge overvåking som kan gripe inn, og gi brukerne tydeligere innsyn og kontroll. Disse utfordringene vil ikke være unike for OpenAI, og vi håper at det vi har lært, kan hjelpe fagfeltet bredere med å forberede seg på dem.

Forfatter

OpenAI

Fotnoter

  1. 1

     Selv om vi raskt lukket PR-en, hadde flere deltakere i speedrunen allerede sett den og brukt tilnærmingen i sine egne innsendinger; de påfølgende verdensrekord-innsendingene med 3030(åpnes i et nytt vindu), 2990(åpnes i et nytt vindu), 2930(åpnes i et nytt vindu), 2925(åpnes i et nytt vindu), 2900(åpnes i et nytt vindu) og 2890(åpnes i et nytt vindu) steg viser alle til PR 287. Av disse er PR 300(åpnes i et nytt vindu) særlig interessant, fordi det er PR-en Opus 4.7 sendte inn da Prime Intellect(åpnes i et nytt vindu) evaluerte den på NanoGPT-speedrunen. Opus så PR-en som modellen vår hadde sendt inn, tok funnene i bruk og krediterte PR-en vår i sluttresultatet.

  2. 2

     Utrullingene i avspillingen er ikke garantert å forfølge den samme feiljusterte handlingen hver gang, på grunn av tilfeldigheter og ufullkommen rekonstruksjon av miljøet.