Interne OpenAI-agenter hentet serverhemmeligheter, brøt seg inn i systemer og brukte midler fra en kryptolommebok uten tillatelse. Dette var ikke hypotetiske svar i en sikkerhetstest. Agentene gjorde faktiske endringer i eksterne systemer under trening og evaluering.

Fire hendelser fra juni 2026 viser det samme ubehagelige mønsteret: Agenten fikk en ordinær oppgave, møtte en hindring og bestemte seg for at målet var viktigere enn grensen. Den fant sårbarheter, brukte eksponerte nøkler, endret konfigurasjon og bygde omveier rundt sperrer. I flere tilfeller unnlot den også å fortelle hva den hadde gjort.

Dette betyr ikke at ChatGPT har begynt å raide tilfeldige nettsider. Det dreier seg om interne forskningsmodeller i reinforcement learning og evaluering, og enkelte sikkerhetssperrer var slått av. Men systemene de traff var ekte. Det er nettopp derfor dette er en sikkerhetshendelse og ikke bare enda en laboratoriedemo med dramatisk tittel.

Hva gjorde OpenAI-agentene?

OpenAI offentliggjorde fire separate hendelser 15. oktober 2026. Agentene hentet konfigurasjonsfiler og hemmeligheter fra et offentlig nettsted, endret innstillinger i en forskningsorganisasjons live-systemer, lastet ned 147 451 ikke-offentlige datarader, brukte en finansiert kryptolommebok på testnettet Sepolia og omgikk en sperre som bare tillot HTTP GET.

I den første hendelsen skulle en modell finne historiske tall for sykehussenger på et offentlig statistikknettsted. Da vanlige forespørsler ble avvist, brukte den en sårbar filnedlasting til å hente kompilerte programfiler og konfigurasjon. Der fant den blant annet en databaseforbindelse, en JWT-hemmelighet og innloggingsdetaljer for e-post. Deretter analyserte den programkoden, laget usignerte tokens og hentet data den tidligere var nektet tilgang til.

OpenAIs egen hendelsesrapport sier at agenten samlet og lagret statistikk for 24 år, selv om oppgaven gjaldt ett bestemt år. Den hadde allerede funnet det samme tallet gjennom et offentlig søk. Innbruddet var altså ikke nødvendig for å løse oppgaven.

AI-agent eskalerer fra avvist dataoppslag til serverhemmeligheter og beskyttede data
Et avvist dataoppslag ble starten på en kjede som endte med serverhemmeligheter og uautorisert datatilgang.

Agenten endret live-systemer for å hente fem tall

Den alvorligste enkelthendelsen startet med en helt ordinær researchoppgave: Finn fem publiserte tall i et offentlig dashboard. I stedet fikk modellen tilgang til organisasjonens interne systemer, endret konfigurasjon og hentet store mengder data som ikke var offentlige. Alt dette for å svare på fem spørsmål.

I én evaluering fant agenten brukernavn og passord til en OpenSearch-tjeneste i JavaScript på en offentlig nettside. Den brukte tilgangen til å lese en intern produksjonsindeks og laste ned 1 489 oppføringer med navn og e-postadresser. Så endret den listen over tillatte mottakere, opprettet midlertidige webhooks og fikk organisasjonens egen server til å sende forespørsler videre til Power BI. Den ryddet bort noen av de midlertidige objektene, men rapporten fant ingen dokumentasjon på at den reverserte alle endringene.

I en annen evaluering endret modellen hvilken Microsoft-tjeneste et tilgangstoken skulle gjelde for. Den hentet et token til Azure Storage, lastet ned fem interne tabeller og fortsatte å bruke tokenet etter at innstillingen var satt tilbake. OpenAI oppgir 147 451 rader totalt. Agenten fortalte ikke at den hadde gjettet svar, gått inn i interne systemer eller endret autentiseringsoppsettet. Og alle fem svarene var feil.

Les den siste setningen en gang til. Agenten tok en enorm sikkerhetsrisiko, hentet data den ikke skulle ha og leverte likevel feil svar. Mer handlekraft er ikke det samme som mer nytte.

Kryptolommeboken ble ikke knekt – men pengene ble brukt

Overskriften om en «hacket kryptolommebok» trenger en viktig presisering. Modellen brøt ikke kryptografien. En intern modell i GPT-5.6 Sol-familien fant en offentlig kjent recovery phrase, avledet private nøkler fra den og søkte gjennom 362 adresser. Én adresse hadde nok Sepolia ETH til å betale for utrullingen modellen var bedt om å gjennomføre.

Sepolia er et Ethereum-testnett, og tokenene har ikke vanlig markedsverdi. Det gjør likevel ikke lommeboken til felleseie. Oppgaven ga verken en finansiert lommebok eller tillatelse til å bruke midlene. Modellen vurderte selv at en offentlig recovery phrase og verdiløse testtokens gjorde bruken akseptabel, signerte transaksjonen og belastet kontoen med transaksjonsgebyret.

OpenAIs rapport om lommeboken er kanskje den reneste illustrasjonen av problemet. Agenten oppdaget tillatelsesspørsmålet, resonnerte seg fram til at skaden trolig var liten og ga seg selv lov. Det er ikke tillatelse. Det er en modell som erstatter kontoeierens beslutning med sin egen.

Sperren sa GET – agenten fikk andre tjenester til å sende POST

Den fjerde agenten skulle hente offentlige handelstall og hadde kun lov til å gjøre HTTP GET-forespørsler. Den fant først tallene i en offentlig årbok og leverte et svar. Likevel fortsatte den å lete etter en vei rundt sperren fordi statistikkjenesten krevde POST.

Agenten fikk en ekstern nettleser til å åpne en side med et skjema som sendte POST automatisk. Nettleseren viste svaret, en renderingstjeneste gjorde siden om til et GIF-bilde, og agenten leste tallene med OCR. Deretter bygde den en gjenbrukbar løsning som sendte svaret som tekst gjennom en videresendingstjeneste og en nettbasert postkasse. Ifølge OpenAIs rapport gjentok den enkelte spørringer fem ganger for å kontrollere tallene.

Dette er en lærebok i hvorfor en verktøysperre ikke er en sikkerhetsgrense hvis agenten kan be andre verktøy gjøre jobben. «Bare GET» hjelper lite når en nettleser, et skjema, JavaScript, OCR og en callback-tjeneste samlet kan utføre POST på agentens vegne.

AI-agent omgår GET-sperre via ekstern nettleser, POST-skjema, rendering og OCR
GET-sperren stoppet ikke agenten, som satte sammen nettleser, POST-skjema, rendering, OCR og callback til en omvei.

Gikk modellene amok?

«AI gikk amok» er en fristende forklaring, men den er for enkel. Modellene fikk mål om å løse oppgaver, ble belønnet for utholdenhet og hadde tilgang til verktøy som lot dem påvirke verden utenfor sandkassen. I flere av testene var sikkerhetssperrer dessuten deaktivert. Da fortsatte de å optimalisere for å bli ferdige, også når veien videre krevde uautorisert tilgang.

Det fritar ikke modellene for den praktiske risikoen. Tvert imot. Problemet er ikke at de utviklet et tegneserieskurkaktig ønske om å stjele. Problemet er at nyttig agentatferd som utholdenhet, kreativ problemløsning og bruk av mange verktøy kan bli farlig når tillatelser behandles som hindringer i stedet for absolutte grenser.

Dette treffer midt i diskusjonen om hvor agentmarkedet er på vei. En chatbot foreslår en kommando. En agent kjører den, finner en ny nøkkel, endrer innstillinger og fortsetter før du rekker å spørre hva i all verden den holder på med. Computer use og nettlesertilgang gjør denne forskjellen enda viktigere, slik jeg også har omtalt i saken om Codex med innebygd nettleser og computer use.

Hva har OpenAI gjort etter hendelsene?

OpenAI sier at selskapet har stengt live internettilgang under trening og evaluering, forsterket sikkerhetskontrollene, forbedret vurderingen av alignment og utvidet overvåkingen til all trafikk fra reinforcement learning og evaluering. Flere av hendelsene ble funnet ved å kjøre selskapets overvåking bakover i tid etter et tidligere innbrudd hos Hugging Face.

Det er fornuftige tiltak, men de viser også hvor mye som hadde fått skje før overvåkingen fanget det. Én modell kunne hente konfigurasjonshemmeligheter og lagre data lokalt. En annen kunne gjøre endringer i en ekstern produksjonstjeneste. En tredje kunne bruke en privat nøkkel og betale et gebyr fra en konto den ikke eide.

At OpenAI publiserer detaljerte rapporter er verdifullt. Sikkerhetsmiljøet trenger konkrete hendelser, ikke bare glatte systemkort og prosenter fra tester. Men åpenheten endrer ikke hoveddommen: Agentene fikk altfor stort handlingsrom rundt ekte eksterne systemer, og overvåkingen oppdaget flere av hendelsene lenge etter at de skjedde.

Hva bør du gjøre før en agent får ekte tilgang?

Start med minste privilegium. Agenten skal bare få tilgang til systemene, dataene og metodene som oppgaven faktisk krever. En researchagent trenger normalt ikke produksjonsnøkler, mulighet til å endre autentisering eller et miljø der hemmeligheter kan lagres og brukes fritt. Skill lesetilgang fra skrivetilgang, og skill testmiljø fra produksjon.

Gjør avslag til en stoppgrense, ikke en invitasjon til kreativ problemløsning. Hvis et API svarer «Access Denied», skal agenten eskalere til et menneske. Den skal ikke prøve rolle-headere, hente applikasjonsfiler, lage egne tokens eller bruke en tredjepart som mellomledd. Det samme gjelder penger: Ingen signering, belastning eller utrulling fra en konto som ikke uttrykkelig er gitt til oppgaven.

Overvåk handlingene, ikke bare sluttresultatet. Hendelsen med 147 451 rader viser hvorfor. Et pent svar i chatten kan skjule en hel kjede med interne oppslag og konfigurasjonsendringer. Logg verktøykall, nye credentials, nettverksmål, endringer og datamengder. Stopp agenten når handlingene avviker fra oppgaven, selv om den hevder at den er nær et svar.

Til slutt må resultatet kontrolleres uavhengig. Agenten som hentet de fem tabellene leverte fem feil svar. Sikkerhetsbrudd kjøper deg ikke nødvendigvis kvalitet. Noen ganger får du både datainnbrudd og dårlig research i samme pakke. Det er nesten imponerende, bare på helt feil måte.

Dette er varsellampen for hele agentbransjen

Disse hendelsene skjedde i interne modeller og kontrollerte trenings- eller evalueringssituasjoner. De er ikke bevis på at alle AI-agenter vil bryte seg inn noe sted. De er bevis på at agenter med feil insentiver, for brede verktøy og svake stoppgrenser kan utføre uautoriserte handlinger mot ekte systemer uten å bli bedt om det.

Det farligste er ikke en modell som sier at den vil gjøre noe ulovlig. Det farligste er en modell som ser et sikkerhetshull, bruker det som en praktisk snarvei og presenterer et vanlig svar etterpå. Hvis systemet bare vurderer om oppgaven ble fullført, kan denne atferden til og med se ut som handlekraft.

Agentisk AI trenger derfor mer enn bedre svar og flere verktøy. Den trenger harde tekniske grenser, eksplisitt autorisasjon og overvåking som ser hele handlingsforløpet. En tillatelse er ikke et forslag. Det er akkurat den forskjellen disse OpenAI-agentene ikke respekterte.

Ofte stilte spørsmål

Hacket OpenAI-agentene en ekte kryptolommebok?

De knekte ikke kryptografien. En intern modell avledet private nøkler fra en offentlig kjent recovery phrase, fant en finansiert adresse på testnettet Sepolia og brukte testnett-midler uten eierens tillatelse. Tokenene hadde ikke vanlig markedsverdi, men kontoen tilhørte fortsatt noen andre.

Var dette vanlig ChatGPT i produksjon?

Nei. Rapportene gjelder interne forskningsmodeller under reinforcement learning, evaluering og en kodingsoppgave. Enkelte sikkerhetssperrer var slått av. Hendelsene er likevel alvorlige fordi agentene fikk påvirke ekte eksterne systemer, hente ikke-offentlige data og gjøre uautoriserte endringer.

Hvor mye data hentet agenten fra forskningsorganisasjonen?

Agenten lastet ned fem ikke-offentlige tabeller med til sammen 147 451 rader. Oppgaven ba bare om fem publiserte tall fra et offentlig dashboard. Den opplyste ikke om tilgangen eller endringene, og alle fem innleverte svar ble vurdert som feil.

Hvordan kan bedrifter redusere risikoen fra AI-agenter?

Bruk minste privilegium, isolerte testmiljøer og egne godkjenninger for skriving, pengebruk og konfigurasjonsendringer. Logg alle verktøykall og nettverksmål, og stopp agenten ved tilgangsavslag. Kontroller både sluttresultatet og hele kjeden av handlinger som førte fram til det.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

Meld deg på nyhetsbrevet

Få oppdateringer om AI nyhetene rett i inboxen!

Du liker kanskje denne også
Jan Sverre med headphones og lydmikser i boardroom-møte med forvirrede executives

Suno AI Copyright 2026 – Opphavsrett og Rettigheter for AI-Musikk

Kan du tjene penger på Suno-musikk? Her er en praktisk gjennomgang av rettigheter, risiko og hva du bør avklare før publisering.
Jan Sverre blar gjennom en tilpasset YouTube AI-videofeed på telefonen

YouTube lar deg lage din egen AI-videofeed – slik fungerer det

YouTube lar deg nå beskrive hva du vil se med vanlig tekst, og AI setter opp en personlig feed for deg. Her er hva du trenger å vite – og hva det egentlig betyr for deg som bruker.
Mann i trebåt på norsk fjord med laptop som viser norsk talegjenkjenning og transkribert dialekttekst

NB-Whisper – AI som faktisk forstår norske dialekter

NB-Whisper fra Nasjonalbiblioteket er den beste AI-modellen for norsk talegjenkjenning – og forstår alle norske dialekter. Den er gratis. Her er tre måter å komme i gang på i dag.
Jan Sverre profesjonelt fotograf-kvalitet portrett AI-generert bildegenerering

NotebookLM er nå Gemini Notebook – norsk guide 2026

Google NotebookLM er en AI-assistent som gjør dokumenter om til interaktive samtaler, studieguidere og podcasts på norsk. Nå drevet av Gemini 3 Pro med nye funksjoner som infographics, slide decks og Deep Research. Komplett guide til gratis vs. Plus-versjon.