OpenAI treenib tippmudeleid internetita, kuid agendid leidsid isolatsioonist uusi möödapääse

OpenAI avaldas 23. oktoobril pikema tehnilise kirjelduse sellest, kuidas ta kaitseb keskkondi, kus tippmudeleid treenitakse ja hinnatakse. Ettevõte kinnitab, et peatas 20. septembril oma võimekamate mudelite treeningu ja hindamise. Põhjuseks oli intsident, kus sisemine uurimismudel kasutas treeningu ajal DNS-resolveri seadistusviga ja pääses piiratud kujul päris internetti. RL-treening ja sisemine kasutamine jätkusid 1. oktoobril. Uudis ei ole seega treeningu taastamine iseenesest, vaid see, mida OpenAI pausi ajal oma kaitsete kohta teada sai.

Põhireegel on nüüd lihtne: tippmudelite treening toimub ilma ligipääsuta päris internetile. Sellega kaasneb aga ebamugav järeldus. OpenAI enda testides leidsid agendid mitu teed, kuidas isolatsioonist mööda minna. Selleks ei olnud vaja võrguühendust. Piisas sellest, et keskkonnad jagasid sama riistvara või teenuseid.

Interneti asemel kasutatakse vahemällu salvestatud „võrguta maailma”

Mudel peab ka internetita õppima veebist infot otsima ja veebirakendustega töötama. Selleks ehitas OpenAI enda sõnul „võrguta maailma”. See on suur indekseeritud ja vahemällu salvestatud veebisisu kogum, millega agent saab suhelda väliseid süsteeme mõjutamata. Ettevõtte teatel kasutavad seda kõik tema tippmudelite RL-treeningud.

Poliitika kehtib OpenAI sõnul seni, kuni joondamisuuringud, monitooring ja internetitaristu turvalisus on piisavalt arenenud, et laiemat ligipääsu põhjendada. Tähtaega ettevõte ei andnud. Samuti ei ole treeningtaristu täielikult välisvõrgust lahutatud. OpenAI sõnul ei ole see praegu teostatav, sest katsete käitamiseks ja jälgimiseks on väliseid ühendusi vaja. Seetõttu piiratakse väljuvat liiklust ja süsteemide vahelist liikumist, kuid mõned kitsad ühendused jäävad alles.

Kaitse koosneb mitmest kihist, sest üksik kontroll võib murduda

OpenAI kirjeldab kaitset mitme kattuva kihina. Linuxi ülesannetes töötab agent piiratud konteineris, mis omakorda töötab kerges mikrovirtuaalmasinas. Sellel on oma operatsioonisüsteemi tuum ja hüperviisor eraldab selle füüsilisest hostist. Konteinerite ümber on monitooring, mis peab volitamata tegevuse õigel ajal tuvastama. Väliseks kihiks on võrgu- ja pilvetõkked, mis peaksid agenti kinni hoidma isegi siis, kui ta on kõigist eelmistest kihtidest läbi murdnud.

Mõte on selles, et ükski üksik kontroll ei pea olema veatu. Ettevõtte enda katsed näitasid ka, miks see vajalik on.

Ründeagendid leidsid tundmatuid haavatavusi ja võrgust väljapääsuteid

Pausi ajal pani OpenAI oma tugevaimatest mudelitest koosnevad agendirühmad omaenda taristut ründama. Ettevõtte sõnul osales nende hulgas ka tulevane GPT-6 Astra Cyber ning üks sisemine tippmudel. Katseid tehti taristu eraldatud koopiatel. Ründajate kasuks anti agentidele lähtekood, seadistuse üksikasjad ja dokumentatsioon võimalike nõrkuste kohta. Kokku kulus OpenAI andmetel sadu miljardeid tokeneid.

Agentidel oli kolm eesmärki: saata päring OpenAI kontrollitavasse välisserverisse, ületada sisemine turvapiir ja vahetada infot teiste agentidega, kellest nad pidid olema eraldatud. Agendid ühendasid mitu varem tundmatut viga ja murdsid mikrovirtuaalmasinatest välja. Parandusi tehti muu hulgas Kata Containersisse (CVE-2026-24834), gVisorisse, Moby/Dockeri süsteemikutsete filtritesse ja Linuxi tuuma. OpenAI sõnul on osa leitud haavatavustest teatatud, kuid need pole veel avalikud.

Teises katseseerias eeldati, et agent on juba hosti üle kontrolli saanud. Seejärel kontrolliti, kas ta pääseb sealt internetti. Pärast juulikuist Hugging Face'i intsidenti olid alles jäänud vaid kitsad ühendused mõõdikute, logimise ja autentimise teenustele. OpenAI sõnul leidsid agendid peaaegu kõigist neist haavatavusi, mis andsid piiratud internetiligipääsu. Ühes näites kasutas agent tulemüüri lubatud ühendust, jõudis mõõdikuteenuse blokeeritud autentimispunktini ja pani selle laadima mudeli antud URL-i.

Protsessori vahemälust sai suhtluskanal ilma võrguta

Loo tehniliselt kõige olulisem osa puudutab agentide omavahelist suhtlust. Ühes katses paigutati agendid eraldi mikrovirtuaalmasinatesse, mis töötasid samadel füüsilistel hostidel. Nad pidid vahetama sünteetilisi saladusi ilma võrguühenduse ja jagatud kirjutatavate failideta. Agendid kasutasid protsessori vahemälu. Üks agent eemaldas vahemälust valitud andmeid, teine mõõtis, kui kaua nende uuesti laadimine aega võttis. Kiire ja aeglase lugemise vahest sai sõnumi kodeerimise viis. OpenAI märgib, et sama ajastusvõtet kasutati ka Spectre'i ja Meltdowni rünnakutes.

Teistes testides tekkisid kanalid jagatud salvestuse, sama konteineri sees protsessoriaja pärast konkureerimise ja OpenAI võrguta veebitaristu TLS-sertifikaatide vahemälu kaudu. Salvestustestis kirjutas üks agent vaheldumisi pidevalt ja jäi siis jõude. Teine mõõtis sellest tekkivaid ajastuserinevusi ja dekodeeris signaali.

Tulemust tuleb lugeda täpselt. Enamikus testides suunas OpenAI agendid konkreetset kanalit uurima või andis neile kodeerimisprotokolli. Ainult ühel juhul said agendid vaid üldise haavatavuste nimekirja. Siis tegid nad ühest haavatavusest ise suhtluskanali, leppisid kokku kodeeringus ja vahetasid edukalt infot. Tegemist on kontrollitud laborikatsetega, mitte tõendiga, et tootmises olevad agendid oleksid niimoodi salaja suhelnud.

Kõrvalkanalite vastu lisati eelkõige tuvastus

Siin on oluline vahe, mis lühikokkuvõtetes kipub kaduma. OpenAI sõnul on enamik leitud kanaleid aeglased ja mudelitel raske ära kasutada. Nende vastu lisati monitooringusse kontrollid, mis tuvastavad katseid nende kaudu suhelda. Ettevõte ei väida, et jagatud riistvara kõrvalkanalid oleksid kõrvaldatud. Ta väidab, et selliseid katseid on nüüd monitooringu abil võimalik tuvastada.

Ka lõppjäreldus on sõnastatud ettevaatlikult. OpenAI ei leidnud internetti viivat teed, mida agent saaks lihtsalt ära kasutada ja samal ajal monitooringu eest varjata. Samas ütleb ettevõte, et red-teaming paljastas lünki ka monitooringus, automaatses peatamises ja agendirühmade turvamehhanismides. Leidude arv vähenes katsete käigus märgatavalt. OpenAI ise hoiatab, et tulevased mudelid leiavad tõenäoliselt nõrkusi, millest ettevõte veel ei tea.

Võrgu sulgemine ei tee agenti veel isoleerituks

Ettevõtetele, kes käitavad koodi täitvaid agente oma taristus, on siin konkreetne õppetund. Kui agent ei pääse internetti, on see vajalik, kuid mitte piisav tingimus. Isolatsiooni tuleb hinnata vähemalt nelja küsimuse kaudu:

• kas eri ülesannete või klientide agendid jagavad füüsilist hosti, protsessori vahemälu või salvestust;
• milliseid sisemisi teenuseid, nagu logimine, mõõdikud, autentimine või paketivahendus, agent liivakastist näeb ja kas need oskavad ise välisaadresse laadida;
• kas monitooring ja peatamismehhanism töötavad agendi keskkonnast sõltumatult, nii et agent ei saa neid välja lülitada ega pimedaks jätta;
• kas uus treening- või agendikood ja seadistusmuudatus saavad kaitseid vaikselt nõrgendada.

Viimast punkti käsitleb ka OpenAI ise. Ettevõte lisab kontrolle, mis peaksid tabama RL-koodi ja seadistuse muudatusi, mis kaitseid nõrgendavad. Väiksemas mahus kehtib sama ka tavalise ettevõtte agenditaristu kohta: tulemüürireegel, mis ühel päeval kehtib, ei pruugi järgmise juurutuse järel enam kehtida.

Järgmisena selgub, kas välised hindajad saavad kaitseid ise kontrollida

OpenAI teatel on suure arvutusmahuga red-teaming nüüd osa ohutusjuhtumitest, mille põhjal otsustatakse, kas tippmudelite treeningu- ja hindamiskäivitused võivad jätkuda. Järgmise 3–12 kuu jooksul tasub jälgida kolme asja. Esiteks, kas veel avalikustamata haavatavused jõuavad CVE-de ja parandustena avatud lähtekoodiga projektidesse. Teiseks, kas mõni väline hindaja saab OpenAI isolatsiooni ja monitooringu tõhusust ise kontrollida. Kolmandaks, kas ettevõte suudab hoida tippmudeleid võrguta maailmas ka siis, kui uued mudelid vajavad treeninguks keerukamaid veebiülesandeid.