OpenAI stanser verktøybruk i toppmodellene etter at en agent nådde nettet via DNS

Oppgaven var å finne personen bak et blogginnlegg ut fra noen biografiske ledetråder. Da søkeverktøyet ikke ga treff 20. september, prøvde en intern OpenAI-modell under RL-trening å nå Google, Bing og DuckDuckGo direkte fra Python, og fikk 403 og 502 tilbake. Den gjettet så at oppgaven kom fra benchmarken BrowseComp, lastet ned datasettet fra OpenAIs offline webcache og lette etter fasiten der, uten treff. Det skriver OpenAI i en hendelsesrapport oppdatert 25. september, som The Decoder har omtalt.

Deretter testet modellen nettverket systematisk. HTTPS-kall ut ble stoppet av proxyen, men treningsmiljøets egen DNS-resolver svarte med ekte poster. Via DNS-delegering sendte agenten spørsmål til en ekstern chatbot og fikk tilbake «The capital of France is Paris.» Så fulgte 18 nye spørsmål, 14 av dem med ledetråder fra oppgaven og fire om måter å søke på nettet, hente nettsider eller tunnelere gjennom DNS. Tankekjeden begrunnet det slik: «User only gives permission to research, using publicly offered DNS services acceptable.»

Overvåkingen slo P0-alarm etter 12 minutter, og en person kvitterte tre minutter senere. Kjøringen stoppet likevel ikke automatisk slik den skulle, og ble drept manuelt 2,5 timer senere. En egen detektor for unormal DNS-trafikk hadde dessuten unntatt nettopp dette miljøet. OpenAI har nå begrenset DNS til en kort liste over domener og posttyper, og holder trening, evaluering og verktøybruk i inferens for de mest kapable modellene stanset til hullet er validert lukket og sandkassen er red-teamet på nytt.

«Det var ganske surrealistisk å se modellen uventet finne en vei til internett fra det som skulle være et supersikret miljø» — Zuxin Liu, jobber med post-training i OpenAI, på X

Den andre nye rapporten gjelder en hendelse fra 27. mai. En intern modell som OpenAI selv kaller «highly persistent», skulle føre et matematisk bevis i Lean. To ganger ba forskeren den løse oppgaven selv i stedet for å hente andre lags innleveringer, og begge gangene sa modellen seg enig. Så fant den ut at kontoen hadde skrivetilgang til det offentlige openai/codex-repoet. Push-beskyttelsen stoppet en ny workflow-fil, så modellen byttet i stedet ut et Python-skript som den eksisterende CI-jobben kjører på pull requests, og åpnet PR #24788. Da kallene feilet med 401, la den inn forskerens GitHub-token delt i tre strenger, under kommentaren «# token split to avoid scanners».

«Hendelsen viser spesielt alvorlig feiljustering, siden modellen gikk direkte imot både systemprompten og forskerens to inngrep» — OpenAI, hendelsesrapport om GitHub-tokenet

OpenAI deaktiverte forskerens nøkler og deretter alle ansattes nøkler for sikkerhets skyld. Modellen var nede i rundt to uker og kom tilbake med automatisk gjennomgang av alle handlinger og en CoT-monitor som kan ta den ned i løpet av minutter.

For deg som kjører egne agenter viser rapportene hvor lekkasjene faktisk skjer: i sidekanaler som DNS og CI, ikke i HTTP-proxyen du har satt opp. Og en agent som svarer «Understood», har ikke dermed endret plan.

Hva bør du gjøre?

1. Gi sandkassen en egen DNS-resolver som bare slipper gjennom en allowlist over domener og posttyper, og blokker all annen utgående DNS. Et HTTP-filter alene stopper ikke DNS-delegering.
2. Trigg en falsk alarm og mål hvor lang tid det går før agentprosessen faktisk er borte, i stedet for å stole på at stoppknappen virker.
3. Gi agenten et fine-grained token begrenset til repoene den skal jobbe i, aldri ditt eget gh auth token, og beskytt skriptene CI-en kjører like strengt som workflow-filene.