AI-agentti tarvitsee aidat myös paikallisella koneella
OpenAI julkaisi 13. toukokuuta 2026 teknisen katsauksen ongelmaan, joka on helppo sivuuttaa niin kauan kuin AI-agentti vain vastaa selaimessa. Mitä tapahtuu, kun sama agentti ajaa komentoja oikealla kehittäjäkoneella?
OpenAI:n David Wiesen kertoo, että kun hän liittyi Codex-tiimiin syyskuussa 2025, Windows-käyttäjillä oli käsissään tehokas mutta hankalasti rajattava työkalu. Codexille ei ollut rakennettu omaa eristettyä sandboxia. Käytännössä kehittäjän oli joko hyväksyttävä manuaalisesti lähes jokainen komento tiedostojen lukemista myöten tai kytkettävä päälle Full Access -tila. Jälkimmäinen poisti kitkan, mutta samalla agentti sai toimia käyttäjän täydillä oikeuksilla.
Codex ei ole vain selaimessa vastaava chatbotti, vaan se integroituu kehittäjän arkeen komentorivin, IDE-laajennuksen tai työpöytäsovelluksen kautta. Se voi ajaa paikallisia komentoja, lukea tiedostoja ja muokata projektia käyttäjän koneella.
OpenAI:n mukaan Codexin oletustilan tavoite on tasapainottaa hyödyllisyys ja turvallisuus. Agentin pitäisi voida lukea tiedostoja laajasti ja kirjoittaa työtilan sisällä, mutta verkkoyhteyksien pitää pysyä estettyinä, ellei käyttäjä nimenomaisesti salli niitä. Windowsissa tämän yhtälön ratkaiseminen osoittautui odotettua vaikeammaksi.
Miksi tavallinen sovellussandbox ei riittänyt?
Agenttimainen kehitystyö vaatii erilaista liikkumavaraa kuin perinteinen ohjelmisto. Agentin pitää voida käyttää samoja työkaluja ja työnkulkuja kuin oikea ohjelmoija: shelliä, Gitiä, Pythonia, paketinhallintaa, build-työkaluja ja muita projektista riippuvia komentoja. OpenAI:n mukaan Windows ei tarjonnut valmiina yhtä mekanismia, joka olisi sopinut tähän suoraan.
Yhtiö kävi läpi AppContainerin, Windows Sandboxin ja Mandatory Integrity Control -merkinnät. AppContainer oli liian kapea avoimeen kehittäjätyöhön. Windows Sandbox tarjosi kyllä vahvan eristyksen, mutta erillisenä kevytvirtuaalikoneena se ei sopinut Codexin tarpeeseen toimia käyttäjän omassa projektissa ja työkaluympäristössä. Integrity label -mallissa ongelmaksi tuli se, että merkinnät muuttavat todellisen tiedostojärjestelmän luottamusmallia.
Ensimmäinen oma prototyyppi nojasi Windowsin SID-tunnisteisiin ja write-restricted token -mekanismiin, jotta kirjoitusoikeudet voitiin rajata työtilaan. Verkkoyhteyksiä yritettiin puolestaan rajoittaa ympäristömuuttujilla, proxy-asetuksilla ja PATH-järjestelyillä. Tämä auttoi tavallisia työkaluja vastaan, mutta OpenAI:n mukaan suoja jäi liian neuvoa-antavaksi: prosessi saattoi ohittaa ympäristömuuttujat tai avata verkkoyhteyden suoraan.
Ratkaisuksi kaksi uutta käyttäjää ja palomuurisäännöt
Koska kevyt malli ei riittänyt, OpenAI rakensi järjestelmän, jota se kutsuu elevated sandboxiksi. Kuten termi viittaa, käyttöönotto vaatii korotetut oikeudet. Niiden avulla käyttöjärjestelmään luodaan kaksi paikallista käyttäjää: CodexSandboxOffline ja CodexSandboxOnline.
Offline-käyttäjään kohdistetaan palomuurisäännöt, joilla ulospäin suuntautuva verkkoliikenne voidaan estää vahvemmin kuin pelkillä ympäristöasetuksilla. Setup-vaihe luo tarvittavat käyttäjät, tallentaa niiden tunnistetiedot paikallisesti Windows Data Protection API:lla salattuna ja luo palomuurisäännöt. Lisäksi mukaan tarvittiin erillinen command runner -binääri, jonka tehtävä on käynnistää agentin pyytämät komennot rajoitetun tokenin alla.
OpenAI tiivistää lopullisen rakenteen neljään kerrokseen: codex.exe, codex-windows-sandbox-setup.exe, codex-command-runner.exe ja varsinainen lapsiprosessi. Monimutkaisuus ei ole kosmeettista, vaan seurausta siitä, että agentin pitää pystyä käyttämään oikeita kehittäjätyökaluja mutta samalla pysyä käyttöjärjestelmän valvomissa rajoissa.
Mitä kehittäjän kannattaa huomata?
Uutinen ei ole uusi malli tai hintapäivitys, mutta se kertoo paljon siitä, mihin AI-työkalut ovat menossa. Kun koodiagentti saa ajaa testejä, asentaa riippuvuuksia, muokata tiedostoja ja mahdollisesti käyttää verkkoa, turvallisuus ei voi perustua vain siihen, että malli yrittää toimia oikein.
Käytännön kysymys on sama yrityksissä ja yksittäisen kehittäjän koneella: missä rajat toteutetaan? Jos raja on vain kehotteessa, käyttöehdoissa tai sovelluksen omassa logiikassa, se ei välttämättä pidä, kun agentti käyttää oikeita komentorivityökaluja. OpenAI:n Windows-ratkaisu osoittaa, että vakavasti otettava agenttiturvallisuus siirtyy nopeasti käyttöjärjestelmän tasolle: käyttäjiin, tokeneihin, palomuuriin, tiedostojärjestelmän oikeuksiin ja prosessien käynnistykseen.
Sama tarkistus koskee myös suomalaisia organisaatioita, vaikka OpenAI:n julkaisu käsittelee Windows-toteutuksen sisäistä arkkitehtuuria. Kun tiimi ottaa käyttöön Codexin tai muun agenttityökalun, kannattaa selvittää, mitä agentti saa lukea, mihin se saa kirjoittaa, milloin verkkoyhteydet ovat sallittuja ja miten poikkeuksista jää jälki. Agentin hyöty syntyy siitä, että se pääsee työskentelemään oikeassa ympäristössä. Sama syy tekee rajauksista pakollisia.
Agenttien turvallisuus on tuotantokysymys
OpenAI:n tärkein viesti on, että koodiagentin turvallisuus on eri laji kuin tavallisen sovelluksen turvallisuus. Tavallinen sovellus voidaan rajata suhteellisen tarkkaan etukäteen. Agentti taas toimii avoimessa kehittäjäympäristössä, jossa seuraava komento voi riippua projektista, testituloksesta, paketinhallinnasta tai virheestä, jota kukaan ei osannut ennakoida.
Siksi Codexin Windows-sandbox on pieni mutta tärkeä signaali. AI-agentit eivät jää selainikkunan sisään. Ne siirtyvät yhä syvemmälle työkaluihin, tiedostoihin ja komentoriveille. Mitä hyödyllisempi agentti on, sitä enemmän se tarvitsee käyttöoikeuksia. Ja mitä enemmän käyttöoikeuksia sillä on, sitä tärkeämmäksi muuttuu se, että rajoja valvoo jokin muu kuin itse malli.
Lähteet
- OpenAI: Building a safe, effective sandbox to enable Codex on Windows - https://openai.com/index/building-codex-windows-sandbox/



