- Suoritushiekkalaatikot määrittelevät tiukat rajat tiedostoille, prosesseille, verkolle ja salaisuuksille, jotta koodausagentit voivat suorittaa tehokkaita toimintoja vaarantamatta isäntiä tai tuotantojärjestelmiä.
- Nykyaikaiset alustat yhdistävät käyttöjärjestelmän primitiivit (Seatbelt, Landlock, gVisor, microVM) korkeamman tason abstraktioihin, kuten tilannekuviin, lämpimiin pooleihin, taltioihin ja PTY:ihin, pitääkseen hiekkalaatikot sekä turvallisina että nopeina.
- Salaisuudet, verkkokäytännöt, työtilan luottamus ja kehotteiden injektioiden puolustusmekanismit muodostavat todellisen ohjaustason; pelkkä isännän eristäminen ei riitä agentin turvalliseen suorittamiseen.
- Pilvi- ja paikalliset ekosysteemit (Cloudflare, GKE, Heroku, Docker, Freestyle, E2B, Daytona, Cursor, LangChain) ovat siirtymässä hiekkalaatikkoympäristöihin oletusarvoisena tapana suorittaa epäluotettavan agentin luomaa koodia.
Tekoälyagenttien antaminen koodin suorittamiseen, tiedostoihin koskettamiseen, selainten avaamiseen ja API-rajapintoihin painamiseen muuttaa heidät hienosta automaattisesta täydennyksestä paljon lähemmäksi koneen pääkäyttäjänä toimivaa nuorempaa insinööriä. Juuri tuo ylimääräinen teho on syy siihen, miksi ne tuntuvat maagisilta – ja juuri siksi ne voivat olla vaarallisia. Väärin kohdistettu tai yksinkertaisesti buginen agentti voi tyhjentää tietokannan, vuotaa API-avaimen internetiin tai ottaa käyttöön rikkinäisen version tuotantoympäristössä todella "ymmärtämättä", mikä meni pieleen.
Todellinen kysymys ei ole enää "kuinka tarkka malli on?", vaan "mitä se voi saavuttaa, kun se on väärässä, huijattu tai liian itsevarma?". Agenttien suoritushiekkalaatikot ovat ratkaisu tähän ongelmaan: tarkasti rajatut ympäristöt, joissa agentit voivat lukea ja kirjoittaa koodia, ajaa komentotulkkeja, käynnistää palvelimia tai käynnistää selaimia, samalla kun sinä hallitset tiukasti tiedostojärjestelmiä, verkkoa, tunnistetietoja ja elinkaarta. Mallin luottamisen sijaan rajoitat räjäytyssädettä.
Miksi koodausagentit tarvitsevat erillisen suoritushiekkalaatikon
Nykyaikaiset koodausagentit, kuten Claude Code, LangChain Deep Agents, Dockerin koodaushiekkalaatikot ja vastaavat työkalut, eivät enää toimi kuin yksinkertaiset chatbotit, joilla on tiedostojen käyttöoikeus. Ne lukevat kokonaisia repositorioita, muokkaavat tiedostoja, suorittavat komentotulkkikomentoja, manipuloivat Gitiä, käynnistävät Docker-koontiversioita, kommunikoivat ulkoisten API-rajapintojen kanssa ja jopa käyttävät täysimittaisia työpöytämäisiä ympäristöjä selaimen kautta. Toimittajien dokumentit ovat tästä hyvin yksiselitteisiä: Claude Code esitetään ketteränä kehitysassistenttina, joka voi tarkastaa koodikantaasi, tehdä muokkauksia ja suorittaa komentoja; LangChain Deep Agents käsittelee hiekkalaatikkopohjaista taustajärjestelmää paikkana, jossa ne suorittavat komentokomentoja, hallitsevat tiedostojärjestelmiä ja delegoivat työtä aliagenteille eristämistä varten.
Juuri tämä ominaisuusjoukko tekee näistä agenteista hyödyllisiä – ja toiminnallisesti riskialttiita. Kun malli voi toimia pytest, asentaa npm-paketteja, avata haaroja tai debugata koontivirheitä, se on vain muutaman työkalukutsun päässä käyttöönottoskriptien muokkaamisesta, rikkinäisten kuvien jakamisesta, CI-konfiguraatioiden säätämisestä tai tokeneiden vuotamisesta HTTP-pyyntöjen kautta. Sekä OpenAI:n omat agenttien turvallisuusohjeet että NIST:n työ agenttien kaappaamisen parissa korostavat nopeaa injektiota: tiedostoihin, verkkosivuille tai lokeihin piilotetut haitalliset ohjeet voivat hiljaa ohjata agentin toimiin, joita et ole koskaan tarkoittanut valtuuttaa.
Monet tiimit aloittavat naiivilla ”pyydä hyväksyntää” -prosessilla jokaiselle komennolle ja huomaavat nopeasti, etteivät ne skaalaudu. Anthropic on julkisesti kertonut, että käyttäjät hyväksyivät 93 % Claude Coden lupakehotteista; Dockerin Claude-hiekkalaatikko jopa julkaisee Claude Coden --skip-permissions oletusarvoisesti nojataan ajonaikaiseen eristämiseen valintaikkunoiden tulvan sijaan. Ihmiset kyllästyvät hyväksyntään, varsinkin kun useita agentteja suoritetaan rinnakkain ja kontekstia vaihdetaan useiden kehotteiden välillä. Tässä vaiheessa vahvistusikkunoista tulee seremonia, ei luotettava kontrolli.
Suoritushiekkalaatikko muuttaa suojausmallin "luota käyttäjän lukevan jokaisen kehotteen" malliksi "oleta, että jotkin komennot ovat vääriä tai haitallisia, ja rajoita niiden aiheuttamaa vahinkoa". Hiekkalaatikosta tulee kova raja sille, mihin tiedostoihin, prosesseihin, verkkoihin ja salaisuuksiin agentti voi koskea, jopa silloin, kun sitä manipuloidaan pikainjektiolla tai se yksinkertaisesti tekee virheitä.
On myös olemassa kehittäjäkokemusta koskeva perusargumentti: agentit tarvitsevat riittävästi tilaa työskennelläkseen. Jos käytät liikaa hiekkalaatikkoympäristöä ja yksinkertaisia rajoituksia, yksinkertaiset komennot, kuten koontiversiot tai testit, epäonnistuvat jatkuvasti epäselvien käyttöoikeusvirheiden vuoksi. Parhaat järjestelmät, kuten Cursorin macOS/Linux/Windows-käyttöjärjestelmissä tai Cloudflaren, Herokun ja Google Cloudin isännöidyissä työkuormissa käyttämät, pyrkivät antamaan agenteille "oikean tietokoneen" tunteen tiukan rajan sisällä.
Miten agenttien suoritushiekkalaatikko todella eristää
Oikea agenttihiekkalaatikko ei ole vain "joku muu paikka koodin suorittamiseen" – se on joukko eksplisiittisiä rajoja, jotka määrittelevät räjähdyssäteen. Voit kuvitella viisi ensisijaista rajoitusta, jotka näkyvät yhä uudelleen johtavilla alustoilla, kuten Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B tai Daytona.
Ensinnäkin tiedostojärjestelmän raja: agentin tulisi nähdä vain se työtila, jonka jaat tarkoituksella. LangChainin dokumentaatiossa hiekkalaatikko kuvataan esteeksi, joka pitää agentit poissa isäntätiedostoista; Dockerin hiekkalaatikkomalli on kristallinkirkas siinä, että mikrovirtuaalikone näkee vain eksplisiittisesti liitetyn projektihakemiston. Kaikki puun ulkopuolella oleva on näkymätöntä tai vain luettavaa, joten agentti ei voi lukea sitä sattumalta. ~/.ssh tai kirjoittaa järjestelmän asetukset uudelleen.
Toiseksi, prosessin ja ytimen raja: agenttityökuormien ei tulisi jakaa raakaa isäntäydintä tai prosessitaulukkoa. Dockerin hiekkalaatikkoarkkitehtuuri eristää jokaisen ympäristön omaan microVM ja Linux-ydinFirecracker (jota useat tarjoajat käyttävät salaa) käsittelee virtuaalikoneen rajaa ensimmäisenä eristyskerroksena ja lisää sitten päälle seccomp-tason, nimiavaruudet, cgroup-ryhmät ja jail-tyyppiset rajoitukset. Googlen GKE Agent Sandbox saavuttaa samanlaisen vaikutuksen Kubernetesin sisällä käyttämällä gVisoria: "vartijakerros" sieppaa järjestelmäkutsuja ja välittää pääsyn alla olevaan solmuun.
Kolmanneksi, verkon raja: ilman verkkokäytäntöä hiekkalaatikossa toimiva agentti on edelleen tiedonsiirtokone. Useimmat vakavasti otettavat alustat toimittavat nyt oletusarvoisesti "estä kaikki lähtevät yhteydet". Esimerkiksi Docker Sandboxes -ympäristöt estävät HTTP/HTTPS:n, kunnes se on nimenomaisesti sallittu, katkaisevat raakat TCP/UDP/ICMP:n ja estävät liikenteen yksityisille IP-alueille ja paikalliselle koneelle, ellet määritä poikkeuksia. Cloudflare, Google ja muut suunnittelevat hiekkalaatikkonsa siten, että lähtevät puhelut kulkevat ohjelmoitavien välityspalvelimien kautta, joihin voit syöttää todennusta, suodattaa kohteita ja auditoida käyttöä.
Neljänneksi, tunnistetietojen raja: raakasalaisuuksien paljastamista hiekkalaatikossa tulisi käsitellä viimeisenä keinona, ei oletuksena. Dockerin suunnittelu reitittää HTTP-kutsuja isäntäpuolen välityspalvelimen kautta, joka voi liittää tokeneita tai API-avaimia pyyntöihin sijoittamatta näitä raaka-arvoja koskaan virtuaalikoneen sisälle. Cloudflare Sandboxes vastaavasti injektoi tunnistetiedot verkkokerrokseen, ei ympäristömuuttujien kautta. Tällä tavoin, vaikka kehote injektoisi agentin "tulostamaan kaikki ympäristömuuttujat", ei ole mitään mehukasta varastettavaa.
Viidenneksi, elinkaaren raja: agenttien työtilat harvoin elävät yhtä komentoa varten; ne tarvitsevat eksplisiittistä semantiikkaa käynnistykselle, tauolle, tilannevedokselle, haarautumiselle ja purkamiselle. E2B tarjoaa erillisiä tiedostojärjestelmiä, taustalla suoritettavia komentoja ja taltioita, jotka voivat selvitä yhden hiekkalaatikon käyttöiän yli. Freestyle keskittyy erittäin nopeaan virtuaalikoneen käynnistykseen, keskeytykseen ja palautumiseen tilannevedosten ja muistissa olevan tilan haarautumisen avulla. Daytona lisää tilannevedoksiin perustuvat hiekkalaatikot sekä automaattisen pysäytyksen, automaattisen arkistoinnin ja automaattisen poiston käytännöt, jotta voit pitää jotkut ympäristöt pitkäikäisinä ja käsitellä toisia kertakäyttöisinä.
Kun näet nämä viisi akselia – tiedostojärjestelmä, prosessi, verkko, tunnistetiedot ja elinkaari – voit tulkita minkä tahansa hiekkalaatikkotuotteen sivun kompromisseina. Jaetun ytimen kontti, jossa on suuri isäntäkokoonpano, mutta tiukat ulostulosäännöt, on hyvin erilainen kuin mikrovirtuaalikone, jossa ei ole isäntäkokoonpanoja, mutta jossa on sallivampi verkko. Koodausagenteille, joiden on asennettava riippuvuuksia, suoritettava selaimia tai rakennettava docker-kuvia, vahvemmat virtuaalikonetyyppiset rajat ovat yleensä turvallisempi oletusarvo.
Sandboxing macOS:ssä, Linuxissa ja Windowsissa paikallisille koodausagenteille
Kehittäjäkannettavilla tietokoneilla raskaita microVM-hiekkalaatikoita ei aina voi käynnistää, joten tiimien on täytynyt käyttää luovuutta käyttöjärjestelmän natiivin eristämisen kanssa. Cursorin viimeaikainen työ paikallisten hiekkalaatikoiden parissa on hyvä esimerkki räätälöinnistä macOS:n, Linuxin ja Windowsin erityispiirteisiin säilyttäen samalla yhtenäisen API:n agenttikerrokselle.
macOS:ssä arvioitiin useita vaihtoehtoja: sovellusten hiekkalaatikkoa, yleisiä säilöjä, täysiä virtuaalikoneita ja pitkäikäistä mutta "vanhentunutta" teknologiaa nimeltä Seatbelt. App Sandbox olisi edellyttänyt jokaisen agentin mahdollisesti suorittaman binääritiedoston allekirjoittamista, mikä olisi lisännyt dramaattisesti monimutkaisuutta ja jopa antanut luoduille binääreille transitiivisen luottamuksen. Linux-kontit olisivat pakottaneet macOS-käyttäjät käyttämään vain Linux-binääritiedostoja, ja täysimittaisilla virtuaalikoneilla olisi ollut kohtuuton käynnistysviive ja muistin ylimäärä interaktiivisille koodausvirroille.
Turvavyö, johon pääsee käsiksi sandbox-exec, osoittautui käytännölliseksi valinnaksi iästään huolimatta. Sen avulla voit suorittaa komennon hiekkalaatikkoprofiilin alla, joka rajoittaa koko prosessipuuta tarkkarajaisella käytäntökielellä: voit lisätä tiettyjä järjestelmäkutsuja valkoiselle listalle tai estää ne ja rajoittaa luku-/kirjoitusoikeuksia kohdennettuihin tiedostoihin tai hakemistoihin. Kohdistin luo nämä käytännöt dynaamisesti suorituksen aikana työtilan ja järjestelmänvalvojan asetusten sekä käyttäjän asetusten perusteella. .cursorignore, joten ohitetut polut muuttuvat kiellettyiksi hiekkalaatikossa.
Linuxissa ydin paljastaa oikeat primitiivit – seccompin syscall-suodatukseen ja Landlockin tiedostojärjestelmärajoituksiin – mutta jättää sommittelun käyttäjän tehtäväksi. Sen sijaan, että luotettaisiin olemassa oleviin OSS-kääreisiin, jotka eivät tukeneet repokohtaisia ignorointifunktioita, kuten .cursorignoreCursor päätti koordinoida Landlockin ja seccompin suoraan. Seccomp estää vaaralliset järjestelmäkutsuja; Landlock valvoo polkupohjaisia luku-/kirjoitussääntöjä ja antaa niiden jopa peittää käyttäjien työtiloja, jotta ohitetut tiedostot ovat täysin käyttökelvottomia tai korvataan suojatuilla kopioilla, joita hiekkalaatikkoprosessit eivät voi lukea tai muokata.
Yksi Linuxin hienovaraisuus on suorituskyky: kaikkien ohitettujen tiedostojen uudelleenasennus tai uudelleenkirjoittaminen on hiekkalaatikon asennuksen hitain osa. macOS-tyylinen viivästetty suodatus, joka näkee tarkan tiedostopolun järjestelmäkutsun aikana, yksinkertaistaisi tätä, mutta Linuxin seccomp-bpf ei tee polun tarkastusta helpoksi, joten tiukan eristämisen ja käynnistysnopeuden välillä on tehtävä todellinen suunnittelukompromissi.
Windowsissa aidosti vastaavan natiivin hiekkalaatikon rakentaminen on edelleen vaikeampaa, koska useimmat eristysprimitiivit on optimoitu selaimille eivätkä yleiskäyttöisille kehitystyökaluille. Cursor käyttää tällä hetkellä Linux-hiekkalaatikkoa WSL2:n sisällä Windows-käyttäjille, käytännössä hyödyntäen Linux-eristystä, kunnes rikkaammat primitiivit ovat saatavilla. He työskentelevät Microsoftin kanssa löytääkseen oikeat ominaisuudet, jotta Windows-agentit voivat ajan myötä nauttia ensiluokkaisesta, natiivista hiekkalaatikosta ilman WSL:ää apuvälineenä.
Näiden käyttöjärjestelmäkohtaisten lähestymistapojen yhteinen piirre on yhtenäinen hiekkalaatikko-API. Agentin näkökulmasta kyseessä on vain "komentotulkkityökalu", jolla on selkeät ominaisuudet ja säännöt. Konepellin alla Seatbelt, Landlock/seccomp tai WSL2-pohjainen eristys valvovat näitä sääntöjä eri tavoin alustasta riippuen.
Opetusagenttien ymmärtämään ja kunnioittamaan hiekkalaatikkoa
Hiekkalaatikko auttaa vain, jos agentti pystyy ennakoimaan, mikä sen sisällä toimii ja milloin sen on siirrettävä oikeuksia tai poistuttava laatikosta. Se kuulostaa itsestään selvältä, mutta käytännössä se vaati yllättävän syvällistä kehotteiden ja työkalujen suunnittelun iterointia koodausagentteja toimittavilta toimittajilta.
Ensimmäinen askel, jonka monet tiimit ottivat, oli työkalukuvausten parantaminen, erityisesti komentotulkin suorittamisen osalta. Yleisen ”run_shell_command”-työkalun sijaan kuvauksessa mainitaan nimenomaisesti, mitkä resurssit ovat käytettävissä: onko komennolla tiedostojärjestelmän käyttöoikeus, Gitin käyttöoikeus, verkkoyhteys vai täysin offline-ympäristö käyttäjän kokoonpanosta riippuen. Se dokumentoi myös, miten agentti voi pyytää tarvittaessa laajennettuja oikeuksia (esimerkiksi julkisen internetin käyttämiseen). Tämä nopea suunnittelutyö on yleensä hyvin empiiristä: tiimit suorittavat yhteisiä käyttöönottovirtoja, tarkkailevat, missä kohtaa malli ennustaa ominaisuuksia väärin, muokkaavat työkalujen kuvauksia ja toistavat.
Sisäisiä vertailuarvoja, kuten ”Cursor Bench” tai vastaavia arviointipaketteja, käytetään sitten agenttien suorituskyvyn vertailuun hiekkalaatikon kanssa ja ilman. Yksi varhainen epäonnistumistapa oli hyvin johdonmukainen: agentti yritti sokkona samaa epäonnistunutta päätekomentoa yhä uudelleen ja uudelleen sen sijaan, että olisi tajunnut törmäävänsä hiekkalaatikon rajoitukseen. Ilman selkeää signaalia komennon epäonnistumisen syystä malli ei voinut oppia kaavaa.
Korjaus oli tuoda hiekkalaatikon virheet näkyviin eksplisiittisesti työkalujen tulosteissa, usein antamalla ohjeita siitä, mitä seuraavaksi tehdään. Kun komento estettiin tiedostojärjestelmän tai verkkosäännön vuoksi, komentotulkkityökalu alkoi lisätä lyhyen selityksen, kuten "hiekkalaatikko esti: lähtevän verkon käyttöoikeus poistettu käytöstä tälle istunnolle", ja joissakin tapauksissa vihjeen, että agentti voisi pyytää laajennettuja käyttöoikeuksia. Tämän muutoksen jälkeen agenteista tuli paljon vikasietoisempia: ne lopettivat toivottomien komentojen toistamisen ja joko muuttivat suunnitelmaansa tai pyysivät tarvittavaa ominaisuutta.
Offline-arvioinnit ovat hyödyllisiä, mutta ne kertovat vain osan totuudesta. Jotta todella selviäisi, heikentääkö hiekkalaatikkoympäristö käyttökokemusta, tiimit ovat ottaneet hiekkalaatikkoympäristötuen käyttöön vähitellen tuotannossa ja seuranneet virhemääriä, valmistumisaikoja ja palautekanavia. Käytännössä toimittajat raportoivat, että huomattava osa yhteensopivien alustojen kyselyistä suoritetaan nyt kokonaan hiekkalaatikoiden sisällä – yritysasiakkaat, kuten NVIDIA, ovat ensimmäisten käyttöönottajien joukossa – ja että hiekkalaatikkoympäristössä toimivat agentit pysähtyvät hyväksyntää varten noin 40 % harvemmin todellisissa työnkuluissa, mikä säästää tuntikausia manuaalista tarkistusta ja vähentää riskejä.
Tulevaisuudessa on paljon kiinnostusta "natiiveihin hiekkalaatikkoagentteihin" – malleihin, joita koulutetaan suoraan ympäristönsä rajoitusten perusteella. Sen sijaan, että agentit käsittelisivät komentotulkkia, selainta tai tiedostojärjestelmää abstrakteina työkaluina, he ymmärtäisivät, että ne toimivat tiukasti rajatussa suoritusympäristössä, voivat kirjoittaa pitkäikäisiä skriptejä ja ohjelmia ja että niiden on noudatettava reunaehtoja, kuten "ei lähtevää verkkoa" tai "työtila on vain luku -tilassa". Tämä koulutus voisi auttaa heitä suunnittelemaan turvallisia ja tehokkaita toimintasarjoja ilman, että heidän tarvitsee painida näkymättömiä seiniä vasten.
Pilvihiekkalaatikot: Cloudflare, Google Cloud, Heroku ja muut
Kehittäjien kannettavien tietokoneiden ulkopuolella suuri aalto infrastruktuurin tarjoajia kilpailee tarjotakseen isännöityjä hiekkalaatikoita, jotka on viritetty erityisesti tekoälyagenteille. Heidän tavoitteensa ovat samat – eristäminen, hallinta ja suorituskyky – mutta kompromissit näyttävät hieman erilaisilta pilvimittakaavassa.
Cloudflare-konttien päälle rakennetut ja nyt yleisesti saatavilla olevat Cloudflare-sandboxit pyrkivät näyttämään ja tuntumaan täysivaltaisilta kehitysympäristöiltä agenteille. Jokainen hiekkalaatikko on pysyvä, erillinen työtila, jolle annetaan nimi. Jos se on lepotilassa, se käynnistyy tarvittaessa; jos se on käyttämättömänä, se keskeyttää automaattisesti laskentatehon säästämiseksi ja jatkaa toimintaansa seuraavan pyynnön yhteydessä. Kehittäjät (tai agentit) voivat olla vuorovaikutuksessa sen kanssa tyypitettyjen metodien, kuten exec, gitCheckout, writeFileja paljon muuta, käyttämällä JavaScript/TypeScript SDK:ta.
Yksi hankalimmista pilvipalveluiden ongelmista on turvallinen todennus agenttien hiekkalaatikoiden sisältä. Agenttien on usein käytettävä yksityisiä palveluita, mutta et halua raakoja tunnistetietoja lojumassa ympäristömuuttujissa. Cloudflare lisää tunnistetiedot verkon välityspalvelimelle ja yhdistää lähtevät pyynnöt isännän mukaan mukautettuun logiikkaan, joka liittää tokenit suojatusta tallennustilasta. Sandbox-prosessi ei koskaan näe todellisia salaisuuksia, mutta puhelu silti todennetaan. Tämä rakenne tukee dynaamista, identiteettitietoista tunnistetietojen injektiota ja toimii hyvin yhdessä työntekijöiden sidosten kanssa.
Päätekomponenttipainotteisia työnkulkuja varten Cloudflare lisäsi täyden PTY-kokemuksen (pseudoterminaali), joka on kytketty WebSocketsin ja xterm.js:n kautta. Agentit ja ihmiset voivat avata reaaliaikaisia shell-istuntoja, keskeyttää prosesseja, muodostaa yhteyden uudelleen myöhemmin ja toistaa aiempia tuloksia. Jokaisella PTY:llä on oma työhakemistonsa ja ympäristönsä, ja tuloste puskuroidaan palvelimelle, jotta uudelleenyhteyttävät asiakkaat voivat kuroa umpeen puuttuvia lokeja.
Raa'an shell-käytön lisäksi Cloudflare tarjoaa myös pysyviä "koodin suorituskonteksteja" kielille, kuten Python, JavaScript ja TypeScript. Toisin kuin monet koodinpätkien suorittajat, jotka suorittavat jokaisen fragmentin erikseen, nämä kontekstit säilyttävät muuttujat, tuonnit ja tilan eri kutsujen välillä, aivan kuten Jupyter-muistikirja. Agentit voivat ladata dataa yhdessä kutsussa, muuntaa sitä toisessa ja renderöidä kaavioita tai HTML-taulukoita ilman, että kaikkea tarvitsee jatkuvasti jäsentää ja tuoda uudelleen.
Verkkokehitystehtävissä Cloudflare-hiekkalaatikot tukevat taustaprosesseja, kuntotarkastuksia ja reaaliaikaisia esikatselu-URL-osoitteita. Agentti voi aloittaa npm run dev taustatyönä, tarkkaile lokeja, kunnes palvelin on valmis, ja paljasta sitten portti julkisen esikatselu-URL-osoitteen takana. Menetelmiä, kuten waitForPort() or waitForLog() anna agenttien järjestää toimia todellisten valmiussignaalien perusteella naiivin sijaan sleep(2s) arvaukset.
Tapahtumapohjaiset työnkulut saavat tehostusta tiedostojen tarkkailuprimitiiveistä, joita tukee Linuxin inotify-mekanismi. Agentti voi tilata muutokset kohdassa /workspace/src ja suorittavat testit tai koontiversiot automaattisesti uudelleen, kun TypeScript-tiedostoja muokataan. Tämä on sama palautesilmukka, johon ihmiskehittäjät luottavat, mutta se on tehty agentteihin sopivaksi API-rajapintojen, kuten sandbox.watch() ja palvelimen lähettämät tapahtumavirrat.
Elinkaaren päättämiseksi Cloudflare ottaa käyttöön todellisia tilannevedoksia – virtuaalikonetason tilakaappauksia, jotka voidaan palauttaa sekunneissa R2-tallennustilasta. Tilannevedokset säilyttävät tiedostojärjestelmän tilan, käyttöjärjestelmän kokoonpanon, asennetut riippuvuudet ja datatiedostot. Tulevat versiot palauttavat myös reaaliaikaisen muistin tilan välitöntä jatkamista varten. Agentit (tai orkestroijat) voivat käynnistää tilannevedoksia ohjelmallisesti tarkistuspisteitä tai vipuhaarukointiskenaarioita varten ja sitten haarautua useisiin erillisympäristöihin samasta tilannevedoksesta tutkiakseen rinnakkaisia hypoteeseja erikseen.
Hinnoittelun osalta Cloudflare siirtyi "vain aktiivinen suoritin" -malliin: sinua laskutetaan tosiasiallisesti käytetyistä suoritinjaksoista, ei käyttämättömyysajasta, kun agentit odottavat LLM-viestejä. Yhdessä "kevyiden" ja suurempien instanssien valtavien samanaikaisuusrajoitusten kanssa tämä mahdollistaa suuren agenttijoukon ylläpitämisen ilman, että rahaa kuluu nukkuviin kontteihin.
Google Cloudin GKE Agent Sandbox on sitä vastoin syvästi integroitu Kubernetesin ja gVisorin kanssa. Ajatuksena on antaa agenttien työkuormien ajaa erillisissä podeissa omien klusteriesi sisällä. Luot GKE-klusterin (Autopilot voi ottaa gVisorin käyttöön automaattisesti, kun taas Standard-klusterit tarvitsevat erilliset ajonaikaiset luokat ja gVisoria käyttävät solmupoolit) ja otat sitten käyttöön Agent Sandbox -ohjaimen versioitujen manifestien kautta.
Mallia ohjaavat kaksi keskeistä mukautettua resurssia: SandboxTemplate ja SandboxWarmPool. SandboxTemplate toimii uudelleenkäytettävänä suunnitelmana, joka määrittää pod-mallin (kuva, portit, resurssit, runtimeClassName: gvisor, jne.) hiekkalaatikkoympäristöissä, kuten Python-ympäristössä. SandboxWarmPool pitää määritetyn määrän esilämmitettyjä podeja valmiina lähes välitöntä käyttöönottoa varten, välttäen kylmäkäynnistyksiä, kun agentti tarvitsee raikkaan ympäristön alle sekunnissa.
A Sandbox Router Palvelu toimii sitten yhdyskäytävänä asiakkaiden ja näiden eristettyjen podien väliselle liikenteelle. Kehitysvaiheessa voit tunneloida liikennettä kubectl port-forward paljastamatta julkisia IP-osoitteita. Tuotannossa reitittimelle annetaan yleensä asianmukainen sisäänpääsy ja mTLS. Asiakaspuolella Google tarjoaa Pythonin "Agentic Sandbox" -kirjaston, joka kattaa koko elinkaaren: hiekkalaatikkovaatimuksen luominen mallipohjasta, sen odottaminen, komentokomentojen suorittaminen ja lopuksi siivoaminen.
Kaikki tämä on pinnan alla edelleen "vain Kubernetesta", mutta paketoituna yhtenäiseksi tarinaksi agenttien suoritusympäristöjä varten. gVisor tarjoaa prosessien ja järjestelmäkutsujen eristämisen, SandboxTemplate standardoi konfiguroinnit, WarmPool ratkaisee käynnistysviiveen ja reititin sekä Python-asiakasohjelma tekevät siitä kätevän LLM-keskeisille sovelluksille.
Heroku puolestaan nojaa erittäin kypsään rakennuspalikkaan: kertaluonteisiin dynamometreihin. Heroku-käyttäjät ovat vuosien ajan suorittaneet ad hoc -töitä – migraatioita, ylläpitoskriptejä ja järjestelmänvalvojan tehtäviä – lyhytaikaisissa dynamiikan yksiköissä, jotka käynnistyvät tarvittaessa ja katkaistaan valmistuttuaan. Heroku käytti tätä infrastruktuuria uudelleen koodin suorituksen hiekkalaatikoina, jotka julkaistiin Managed Inference- ja Agents-tarjontojensa rinnalla. Agentti kirjoittaa Python-, Ruby-, Node- tai Go-koodinpätkiä; Heroku suorittaa ne lyhytaikaisissa dynamiikan yksiköissä ja suoratoistaa tulokset takaisin, mikä rajoittaa räjähdyssäteen lyhytaikaiseen konttiin.
Voit käyttää näitä hiekkalaatikoita joko Herokun Agents-rajapinnan sisäänrakennettujen työkalujen kautta tai ottamalla käyttöön avoimen lähdekoodin Model Context Protocol (MCP) -palvelimia. MCP-palvelimet tarjoavat standardoituja työkalupäätepisteitä, joten asiakkaat, kuten Agentforce, Claude Desktop tai Cursor, voivat käsitellä Herokun hiekkalaatikkoa yleisenä, etäkoodin suorittamiseen tarkoitettuna taustajärjestelmänä. Jokainen palvelin tukee ajonaikaisia rajoituksia (kuten max_calls agenttisilmukkaa kohden), jotta agentit eivät pyöri tiukoissa ja kalliissa silmukoissa.
LangChainin Deep Agents -ominaisuudet lisäävät uuden ulottuvuuden integroimalla kolmannen osapuolen hiekkalaatikkopalveluntarjoajiin, kuten Runloopiin, Daytonaan ja Modaliin. Kaava on yksinkertainen: Deep Agent jatkaa toimintaansa missä tahansa (paikallisesti tai pilvessä), mutta aina kun sen on suoritettava komentoja, luotava tiedostoja tai suoritettava koodia, nämä toiminnot välitetään etähiekkalaatikkoon. Asennusskriptit voivat ladata ympäristömuuttujia etukäteen, kloonata repositorioita, asentaa työkaluja ja paljon muuta, joten jokainen agentti saa puhtaan ja hallitun ympäristön. Kontekstinhallintaohjelmat hoitavat sitten luomisen ja siivoamisen, vaikka dokumentaatio suosittelee vahvasti palveluntarjoajien kojelaudan valvontaa unohdettujen pitkään toimivien hiekkalaatikoiden varalta.
Suorituskyky, tila ja haarautuminen: miksi nopeus on agenteille tärkeää
Hidas mutta erittäin turvallinen hiekkalaatikko ohitetaan käytännössä; kehittäjätyökalut elävät tai kuolevat viiveen varassa. Koodausagentit eivät toimi kuten öiset erätyöt. Ne suorittavat vuorovaikutteisia silmukoita: lukevat koodia, ehdottavat muokkauksia, suorittavat testejä, analysoivat lokeja, kutsuvat työkaluja, odottavat ihmisiä ja toistavat sitten. Todellisissa istunnoissa ne myös tutkivat useita ongelman haaroja, hylkäävät joitakin reittejä ja palaavat toisiin myöhemmin.
Tästä syystä Freestylen kaltaiset alustat keskittyvät pakkomielteisesti alle sekunnin virtuaalikoneiden elinkaareen ja monipuoliseen tilasemantiikkaan. Heidän virtuaalikoneensa ovat täysimittaisia Linux-koneita, joissa on pääkäyttäjän oikeudet, systemd-palvelut, sisäkkäisten virtualisointien tuki ja täysi verkko. Dokumentaatiossa väitetään, että käyttöönotto kestää alle 800 ms API-kutsuista käynnissä olevaan virtuaalikoneeseen, keskeytys/jatkaminen kestää alle 100 ms ja että virtuaalikoneilla on mahdollisuus ottaa tilannevedos tai haarautua kesken suorituksen minimaalisella suorituskykytappiolla. He kutsuvat selaimen tilaa nimenomaisesti hyötyjäksi: jos agentti on ajanut selaimen mielenkiintoiseen tilaan, se voi haarata kyseisen virtuaalikoneen 20 kertaa samasta tilannevedoksesta sen sijaan, että se loisi tilan uudelleen alusta alkaen.
Googlen SandboxWarmPool for GKE ilmaisee saman ajatuksen Kubernetesin termein: pidä esilämmitettyjen podien allas, jotta agentit eivät maksa täysiä kylmäkäynnistysmaksuja jokaisesta uudesta ajosta. Daytonan tilannevedoksiin perustuvat työtilat sekä automaattisen pysäytyksen/arkistoinnin/poiston käytännöt virittävät elinkaaren erityyppisille istunnoille: aktiivisille kehitysympäristöille, lyhytaikaisille kokeiluille ja pitkäikäisille lähtötilanteille.
E2B:n painotus taustalla tehtäviin töihin, katseltaviin hakemistoihin, eristettyihin tiedostojärjestelmiin ja uudelleenkäytettäviin levyihin on saman kolikon toinen puoli. Näiden ominaisuuksien avulla agentti voi pitää kehityspalvelimen tai testijärjestelmän käynnissä samalla, kun hän tutkii koodimuutoksia, tai jakaa pysyvän taltion useiden lyhytaikaisten hiekkalaatikoiden kesken ajan kuluessa. Ilman tätä agentit päätyvät suorittamaan kertaluonteisia komentoja ja menettämään kontekstia, mikä heikentää tuottavuutta.
Hyödyllinen tapa arvioida agenttityöskentelyn hiekkalaatikkoa on esittää muutama suora kysymys. Voinko käynnistää uuden ympäristön reilusti alle sekunnissa? Voinko tallentaa ja palauttaa tilan siististi, mukaan lukien osittaiset koonnit tai selainistunnot? Voinko haarata tilan rinnakkaista tutkimista varten? Voinko säilyttää pitkäikäisiä mutta resurssitehokkaita työtiloja "palaa myöhemmin" -työnkulkuja varten? Mitä enemmän saat "kyllä"-vastauksia, sitä enemmän agenttisi voivat toimia kuin oikeita insinöörejä tilattomien komentosarjojen suorittajien sijaan.
Salaisuudet, verkkokäytäntö ja työtilan luottamus todellisena ohjaustasona
Vaikka isäntäkone olisi täysin eristyksissä, on helppo rakentaa turvaton järjestelmä, jos salaisuudet, verkkokäytäntö ja työtilan luottamus jätetään huomiotta. Dockerin hiekkalaatikkodokumentaatio on tässä asiassa virkistävän rehellinen. Mikrovirtuaalikone ja sen yksityinen Docker-daemon muodostavat pääasiallisen luottamusrajan isäntäkoneeseen. Virtuaalikoneen sisällä agentilla on kuitenkin täydet pääkäyttäjän oikeudet, ja jaettu työtila on liitetty luku- ja kirjoitusoikeuksin. Oletusarvoisesti kaikki tiedostomuokkaukset näkyvät isäntäkoneessa välittömästi. Verkon ulostulo on oletusarvoisesti estetty ja sallittu vain eksplisiittisten sääntöjen mukaisesti, ja HTTP-pyynnöt käyttävät isäntäpuolen välityspalvelinta, joka voi syöttää tunnistetiedot paljastamatta raakoja salaisuuksia virtuaalikoneen käyttöön.
Tämä tarkoittaa, että isännän eristäminen on vasta ensimmäinen vaihe; sinun on silti mietittävä, mitä agentti voi tehdä työtilalle ja ulkomaailmalle. Dockerin dokumentaatio varoittaa nimenomaisesti, että jos agentti muokkaa skriptejä, ihmiset suorittavat ne myöhemmin – Git-hookit, CI-konfiguraatiot, IDE-tehtävämääritykset, Makefile tavoitteet, package.json skriptejä – vauriot voivat "hypätä" takaisin isäntä- tai CI-järjestelmiin, kun kyseiset skriptit suoritetaan. He jopa korostavat, että Git kytkeytyy .git/ älä ilmesty paikalle git diff, mikä helpottaa haitallisen logiikan hiljaista ylläpitämistä.
Tunnistetietojen välityspalvelin on tehokas mutta hienovarainen. Dockerin lähtevä välityspalvelin varmistaa, että salaisuudet pysyvät virtuaalikoneen ulkopuolella, mutta sallii silti agentin toimia näiden identiteettien avulla sallittuja isäntiä vastaan. Jotkin työnkulut – kuten mukautettujen ympäristömuuttujien kirjoittaminen tiedostoihin, kuten /etc/sandbox-persistent.sh – riko tämä raja tallentamalla salaisuuksia tarkoituksella virtuaalikoneen sisälle, mikä on turvallista vain, jos todella luotat agenttiin ja hiekkalaatikkoon.
Konfiguraatioiden laajuus on aivan yhtä tärkeä kuin salaisuudet. Dockerin usein kysytyissä kysymyksissä todetaan, että käyttäjätason konfiguraatiot, kuten ~/.claude or ~/.codex Isäntäkoneessa olevia asetuksia ei kopioida hiekkalaatikkoon; vain jaetun työtilan projektikohtaiset määritykset ovat näkyvissä. Anthropicin määritysdokumentaatio vahvistaa, että projektitason asetukset – työkalut, käyttöoikeudet, MCP-palvelimet ja koukut – ohittavat käyttäjätason asetukset ja ne jaetaan tiimien kesken. Toisin sanoen kaikki repositorioon liitetyt käytännöt, ohjeet ja laajennukset ovat agentin pääasiallinen näkemä pinta-ala.
OpenAI:n taito-ohjeistus tuo esiin samankaltaisia kohtia hieman eri sanastoa käyttäen. Skills-työkalupaketit voivat aiheuttaa riskin tiedon nopeaan injektioon perustuvasta vuotamisesta. Dokumentit varoittavat paljastamasta kuratoimatonta, julkista Skill-markkinapaikkaa suoraan loppukäyttäjille, koska haitalliset SKILL.md-tiedostot voivat ohittaa käytäntöjä, laukaista tuhoisia toimia tai vuotaa yksityisiä tietoja. He suosittelevat kehittäjien Skills-ominaisuuksien tarkistamista, niiden rajaamista tiettyihin työnkulkuihin, vaikuttavien toimien piilottamista ylimääräisten hyväksyntöjen ja käytäntötarkistusten taakse sekä Skills-ominaisuuksien käsittelyä osana uhkamallia.
Kun palaset kootaan yhteen, agenttiympäristöjen "oikea" ohjaustaso kattaa neljä tasoa. Isännän eristäminen suojaa koneesi ja klusterisolmut. Työtilan luottamus suojaa tulevaa ihmistä tai CI:tä, joka suorittaa hiekkalaatikossa tuotettuja tiedostoja. Verkkokäytäntö suojaa ulkoisia järjestelmiä ja yksityisiä tietolähteitä. Tunnistetietojen hallinta suojaa identiteettejä, joiden kautta agentti voi toimia. Vankka suunnittelu tarjoaa vastaukset kaikkiin neljään, ei vain ensimmäiseen.
Tämän lisäksi tarvitset edelleen tervettä skeptisyyttä nopeaa injektiota ja agenttien kaappausta kohtaan. NIST, OWASP ja OpenAI kuvaavat kaikki saman mallin muunnelmia: epäluotettava syöte – README-tiedosto, verkkosivu, lokitiedosto – upottaa haitallisia ohjeita, jotka ohjaavat agentin toimintaa. Haulla täydennetty generointi ja hienosäätö eivät ratkaise tätä taianomaisesti. Hyvin välineistetty hiekkalaatikko ja hyvät käytännöt eivät voi estää mallin huijaamista, mutta ne voivat vähentää merkittävästi haittapuolia, kun niitä huijataan.
Pilvialustat ja agenttien suoritusympäristöt alkavat koodata näitä oppeja. Salaiset välityspalvelimet, sallittujen lähtevien verkkotunnusten listalla olevat asetukset, repo-laajuusrajoitetut määritykset, suppeammin ominaisuuksin varustetut aliagentit, koukkupohjaiset hyväksyntävirrat ja toistettavat hiekkalaatikot ovat kaikki saman palapelin osia: hyväksy, että mallit ovat erehtyväisiä, ja suunnittele ympäristö niin, että erehtyvyyden kustannukset pysyvät rajallisina.
Sekä paikallisissa että pilviympäristöissä agenttien suoritushiekkalaatikkoa voi parhaiten ajatella huolellisesti piirrettynä rajana: se ei tee mallista älykkäämpää, vaan tekee sen virheistä vähemmän katastrofaalisia ja helpommin havaittavia. Oikean tiedostojärjestelmän, prosessin, verkon, salaisuuden ja elinkaaren hallintajärjestelmien yhdistelmällä sekä agentin älykkäällä opettamisella ympäristöstään voit antaa tekoälyjärjestelmien kloonata repositorioita, suorittaa testejä, käynnistää selaimia ja jopa koskettaa tuotantoympäristön kaltaisia järjestelmiä – antamatta niille avaimia kaikkeen sinulle tärkeään.
Tämä tarkoittaa, että isännän eristäminen on vasta ensimmäinen vaihe; sinun on silti mietittävä, mitä agentti voi tehdä työtilalle ja ulkomaailmalle, mukaan lukien riesgos como. koodin etäsuoritus. Dockerin dokumentaatio varoittaa nimenomaisesti, että jos agentti muokkaa skriptejä, ihmiset suorittavat ne myöhemmin – Git-hookit, CI-konfiguraatiot, IDE-tehtävämääritykset, Makefile tavoitteet, package.json skriptit – vaurio voi "hypätä" takaisin isäntä- tai CI-järjestelmiin, kun kyseiset skriptit suoritetaan.
