OpenAI julkisti perjantaina yksityiskohtaisen kuvauksen siitä, miten se ajaa omaa Codex-koodausagenttiaan tuhansilla kehittäjien koneilla turvallisesti. Kirjoituksen mukaan luottamus syntyy kerroksista: tekninen hiekkalaatikko, hyväksyntäpolitiikka ja jatkuva valvonta tekevät yhdessä sen, mihin mikään yksittäinen mekanismi ei pysty.
Aiheen merkitys nousee siitä, että koodausagentteja käytetään yhä useammin täysin autonomisesti. Kun agentti voi muokata tiedostoja, ajaa testejä ja kutsua ulkoisia työkaluja, sen virhe voi viedä koko ympäristön. OpenAI:n viesti on suora: yksittäisellä luottamuspäätöksellä ei selvitä, vaan tarvitaan yhdistelmä.
Sama runko sopii muillekin agenttipohjaisille kehitystyökaluille. Kirjoitus on käytännössä OpenAI:n oma referenssi siitä, miltä koodausagentin sisäinen ajo näyttää, kun yritys ottaa siitä täyden vastuun. Vastaavia oppaita ovat aiemmin julkistaneet vain harvat, sillä useimmat yritykset pitävät agenttiensa sisäisen valvonnan liikesalaisuutena.
Hiekkalaatikko ja suojatut polut
Codexin paikallinen ajo tukee kolmea hiekkalaatikkotilaa. Oletustila workspace-write antaa lukuoikeudet kaikkialle, kirjoitusoikeuden vain käyttäjän työtilaan ja sulkee verkkoyhteyden. Read-only sallii vain lukemisen, kun taas danger-full-access poistaa rajoitukset — sitä OpenAI ei suosittele.
Tietyt hakemistot pysyvät kirjoitussuojattuina kaikissa tiloissa. Polut .git, .agents ja .codex on vakiona suljettu agentin kynästä, jotta sen omat asetukset tai versionhallinnan tila eivät vaaraannu.
Pilvessä Codex toimii eristetyssä OpenAI:n hallinnoimassa kontissa. Asennusvaihe saa avata verkon riippuvuuksia varten, mutta itse agenttiajo ajetaan ilman ulospäin avoimia yhteyksiä.
Hiekkalaatikko on siis enemmän kuin pelkkä verkkofiltteri. Se määrittää, mihin levy- ja tiedostorajaan agentti voi yltää ja missä sen virheelliset komennot vain epäonnistuvat hiljaa.
Hyväksyntäpolitiikka ja luvat
Hiekkalaatikko määrittää teknisen liikkumavaran, hyväksyntäpolitiikka taas ratkaisee, milloin Codex saa toimia ilman kysymistä. Vaihtoehtoja on neljä. On-request kysyy aina hiekkalaatikon ulkopuolisesta toiminnasta, never ei pyydä koskaan, untrusted antaa luvan turvallisille operaatioille mutta vaatii vahvistuksen muille.
Tarkin tila on granular, jossa pääkäyttäjä määrittää erikseen, mitkä toimet tarvitsevat hyväksynnän — esimerkiksi hiekkalaatikon ohitus, MCP-työkalun kutsu tai tilakohtainen lupahakemus. Sama logiikka koskee myös skripti- ja taitopohjaisia työkaluja, joiden lupakäytäntö voidaan rajata erillään peruskonfiguraatiosta.
Päälle voi vielä kytkeä auto-review-agentin, joka esitarkastaa pyynnöt. Agentti etsii dataa siirtäviä tai pysyvyyttä luovia toimia, kuten tunnusten haravointia tai järjestelmän heikentämistä, ja kieltäytyy korkeariskisistä operaatioista. Aikakatkaisun tai virheen sattuessa se sulkee oletuksena.
Käytännössä yhdistelmä antaa kehittäjille nopeuden matalan riskin toimenpiteissä ja pysäyttää työn ennen kuin se voi muuttaa tilaa, jolla on todellista painoa.
Tietoturvavalvoja ja telemetria
Edes kerrokset eivät riitä, jos kukaan ei katso. Codexin lokit syötetään OpenAI:n omalle tekoälypohjaiselle tietoturva-triagi-agentille, joka käy läpi alkuperäisen pyynnön, työkalukutsut, hyväksyntäpäätökset ja verkkokäytäntöjen ratkaisut.
Triagi-agentti erottelee odotetun toiminnan, hyvänlaatuiset virheet ja todelliset poikkeamat. Vain viimeiset päätyvät ihmisen tarkasteluun, jolloin tietoturvatiimin huomio kohdistuu siihen, missä riski on aito.
Telemetria toimii myös työkaluna käyttöönotolle. OpenAI seuraa, mitkä työkalut ja MCP-palvelimet ovat suosiossa, kuinka usein hiekkalaatikko estää tai pyytää lupaa ja missä kohdin politiikkaa on syytä virittää.
Mittarit eivät ole pelkkä raportti vaan palautekanava. Jos hiekkalaatikko keskeyttää tarpeettoman usein arkisen komennon, käytäntöä joko löysennetään tai pyyntöä mallinnetaan toisin.
Hallinnoidut asetukset ja yritystason valvonta
Asetukset järjestyvät selkeään hierarkiaan: yrityshallintaan, käyttäjän paikalliseen config.toml-tiedostoon ja viimeisenä komentorivin lipuihin. Yrityksen pakottamat asetukset menevät edelle, eikä käyttäjä voi ohittaa niitä.
Käytännössä OpenAI hallinnoi pohjat pilvi-, macOS- ja paikallisten konfiguraatiotiedostojen yhdistelmällä. Pääkäyttäjä määrää, ketkä saavat toimia auto-review-agentin tarkastajana, mitkä hiekkalaatikot ovat oletuksena ja miten verkko on rajattu.
Tämä tekee yrityskäytöstä mahdollista. Tiimit voivat kokeilla erilaisia kokoonpanoja yhden auditoidun perustason päällä, ilman että yksittäinen käyttäjä päätyy vahingossa avaamaan koko ympäristön.
Sama hallintamalli soveltuu myös muiden agenttipohjaisten työkalujen käyttöönottoon. Avain on, että vakiintuneet rajat asetetaan yhdellä kerralla ja kokeilu tapahtuu niiden sisällä.
Yhteenveto
Codexin sisäinen käyttö osoittaa, että aggressiivinen koodausagentti voidaan päästää tuotantoon, kun pienin oikeus, jatkuva tarkastelu ja yritystason hallinta yhdistetään. Yksittäinen suoja ei riitä, mutta toisiaan tukevat kerrokset toimivat yhdessä.
OpenAI:n virallisen blogin mukaan ratkaisu ei ole staattinen vaan päivittyy telemetrian perusteella. Saman opetuksen voi soveltaa minkä tahansa agenttisen kehitystyökalun käyttöönottoon — riippumatta siitä, kuka sen taustalla pyörittää mallia.