- Exekveringssandlådor definierar strikta gränser för filer, processer, nätverk och hemligheter så att kodningsagenter kan köra kraftfulla operationer utan att äventyra värdar eller produktionssystem.
- Moderna plattformar kombinerar OS-primitiver (Seatbelt, Landlock, gVisor, microVMs) med abstraktioner på högre nivå som snapshots, varma pooler, volymer och PTY:er för att hålla sandlådor både säkra och snabba.
- Hemligheter, nätverkspolicy, arbetsyteförtroende och försvar mot snabba injektioner utgör det verkliga kontrollplanet; värdisolering ensam är inte tillräckligt för säker agentkörning.
- Moln- och lokala ekosystem (Cloudflare, GKE, Heroku, Docker, Freestyle, E2B, Daytona, Cursor, LangChain) konvergerar mot sandlådebaserade körtider som standardsättet att köra opålitlig agentgenererad kod.
Att låta AI-agenter köra kod, röra filer, öppna webbläsare och klicka på API:er förvandlar dem från avancerad autokomplettering till något som mycket liknar en junioringenjör med root på en maskin. Den extra kraften är just därför de känns magiska – och just därför de kan vara farliga. En feljusterad eller helt enkelt buggig agent kan radera en databas, läcka en API-nyckel till internet eller driftsätta en trasig version i produktion utan att egentligen "förstå" vad som gick fel.
Den verkliga frågan är inte längre "hur noggrann är modellen?" utan "vad kan den komma fram till när den är fel, lurad eller övermodig?". Exekveringssandlådor för agenter är den tekniska lösningen: miljöer med begränsad omfattning där agenter kan läsa och skriva kod, köra skal, starta servrar eller starta webbläsare, medan du strikt kontrollerar filsystem, nätverk, autentiseringsuppgifter och livscykel. Istället för att lita på modellen begränsar du explosionsradien.
Varför kodningsagenter behöver en dedikerad exekveringssandlåda
Moderna kodningsagenter som Claude Code, LangChain Deep Agents, Dockers kodningssandlådor och liknande verktyg beter sig inte längre som enkla chattrobotar med filåtkomst. De läser hela repositories, redigerar filer, kör shell-kommandon, manipulerar Git, startar Docker-byggen, kommunicerar med externa API:er och driver till och med fullständiga skrivbordsliknande miljöer via en webbläsare. Leverantörsdokumentationen är mycket tydlig med detta: Claude Code presenteras som en agil utvecklingsassistent som kan inspektera din kodbas, göra redigeringar och köra kommandon; LangChain Deep Agents behandlar en sandbox-backend som den plats där de kör shell-kommandon, hanterar filsystem och delegerar arbete till underagenter för isolering.
Denna uppsättning funktioner är precis det som gör dessa agenter användbara – och operativt riskabla. När en modell kan köras pytest, installera npm-paket, öppna grenar eller felsöka byggfel, är det bara några få verktygsanrop bort från att modifiera distributionsskript, skicka trasiga avbildningar, justera CI-konfigurationer eller exfiltrera tokens via HTTP-förfrågningar. OpenAI:s egna riktlinjer för agentsäkerhet och NIST:s arbete med agentkapning betonar båda snabb injektion: skadliga instruktioner gömda i filer, webbsidor eller loggar kan i tysthet styra en agent till handlingar som du aldrig menat att auktorisera.
Många team börjar med naiva "begär godkännande"-flöden för varje kommando, och upptäcker snabbt att de inte skalar. Anthropic har offentligt delat att användare godkände 93 % av Claude Codes tillståndsfrågor; Dockers Claude-sandlåda startar till och med Claude Code med --skip-permissions som standard, och lutar sig mot runtime-isolering istället för en snöstorm av dialogrutor. Folk blir trötta på godkännande, särskilt när de kör flera agenter parallellt och växlar kontext mellan många prompter. Vid den tidpunkten blir bekräftelsedialogrutor en ceremoni, inte en pålitlig kontroll.
En exekveringssandlåda flyttar säkerhetsmodellen från "lita på att användaren läser varje prompt" till "anta att vissa kommandon kommer att vara felaktiga eller kontradiktoriska, och begränsa vilken skada de kan göra". Sandlådan blir den hårda gränsen kring vilka filer, processer, nätverk och hemligheter agenten kan vidröra, även när den manipuleras genom snabb injektion eller helt enkelt gör misstag.
Det finns också ett grundläggande argument mellan utvecklarupplevelse: agenter behöver tillräckligt med utrymme för att faktiskt arbeta. Om du överdriver med enkla begränsningar i sandlådan, misslyckas enkla kommandon som byggen eller tester ständigt på grund av obskyra behörighetsfel. De bästa systemen, som de som Cursor distribuerar på macOS/Linux/Windows eller Cloudflare, Heroku och Google Cloud för värdbaserade arbetsbelastningar, syftar till att ge agenter en känsla av en "riktig dator" inom ett begränsat område.
Vad en exekveringssandlåda för agenter verkligen isolerar
En riktig agentsandlåda är inte bara "någon annanstans att köra kod" – det är ett knippe explicita gränser som definierar explosionsradien. Du kan tänka dig fem primära begränsningar som dyker upp gång på gång på ledande plattformar som Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B eller Daytona.
Först, filsystemets gränser: agenten ska bara se den arbetsyta som du avsiktligt delar. LangChains dokumentation beskriver sandlådan som barriären som håller agenter borta från värdfiler; Dockers sandlådemodell är kristallklar att mikroVM:n bara ser en explicit monterad projektkatalog. Allt utanför det trädet är osynligt eller skrivskyddat, så agenten kan inte läsa av sig själv. ~/.ssh eller skriva om systemkonfigurationerna.
För det andra, process- och kärngränsen: agentarbetsbelastningar bör inte dela en rå värdkärna eller processtabell. Dockers sandlådearkitektur isolerar varje miljö på egen hand. microVM och LinuxkärnaFirecracker (som används under huven av flera leverantörer) behandlar den virtuella maskingränsen som det första isoleringslagret och lägger sedan till seccomp, namnrymder, cgroups och jail-liknande begränsningar ovanpå. Googles GKE Agent Sandbox uppnår en liknande effekt inuti Kubernetes med hjälp av gVisor: ett "sentry"-lager fångar upp systemanrop och förmedlar åtkomst till den underliggande noden.
För det tredje, nätverksgränsen: utan nätverkspolicy är en sandlådeagent fortfarande en dataexfiltreringsmaskin. De flesta seriösa plattformar levereras nu med "deny-all egress" som standard. Docker Sandboxes, till exempel, blockerar HTTP/HTTPS tills det uttryckligen tillåts, avbryter rå TCP/UDP/ICMP och tillåter inte trafik till privata IP-intervall och localhost om du inte konfigurerar undantag. Cloudflare, Google och andra utformar sina sandboxar så att utgående samtal går genom programmerbara proxyservrar där du kan injicera autentisering, filtrera destinationer och granska användning.
För det fjärde, gränsen för autentiseringsuppgifter: exponering av råa hemligheter i sandlådan bör behandlas som en sista utväg, inte en standardlösning. Dockers design dirigerar HTTP-anrop via en proxy på värdsidan som kan koppla tokens eller API-nycklar till förfrågningar utan att någonsin placera dessa råvärden inuti den virtuella maskinen. Cloudflare Sandboxes injicerar på liknande sätt autentiseringsuppgifter på nätverkslagret, inte via miljövariabler. På så sätt, även om snabb injicering övertygar agenten att "skriva ut alla miljövariabler", finns det inget saftigt att stjäla.
För det femte, livscykelgränsen: agentarbetsytor lever sällan för ett enda kommando; de behöver explicit semantik för start, paus, snapshot, fork och teardown. E2B exponerar isolerade filsystem, bakgrundskommandon och volymer som kan överleva längre än en enda sandlådemiljö. Freestyle fokuserar på mycket snabb uppstart, paus och återupptagning av virtuella maskiner med snapshotting och förgrening av minnesläge. Daytona lägger till snapshot-baserade sandlådor plus policyer för automatisk stopp, automatisk arkivering och automatisk borttagning så att du kan behålla vissa miljöer långlivade och behandla andra som engångsbruk.
När du väl ser dessa fem axlar – filsystem, process, nätverk, inloggningsuppgifter och livscykel – kan du tolka vilken sandbox-produktsida som helst som en serie avvägningar. En container med delad kärna och en stor värdmontering men strikta utgående regler skiljer sig mycket från en mikroVM utan värdmonteringar men ett mer tillåtande nätverk. För kodningsagenter som behöver installera beroenden, köra webbläsare eller bygga dockeravbildningar tenderar de starkare VM-liknande gränserna att vara den säkrare standarden.
Sandboxing på macOS, Linux och Windows för lokala kodningsagenter
På utvecklarbärbara datorer kan man inte alltid starta tunga microVM-sandlådor, så team har varit tvungna att vara kreativa med OS-nativ isolering. Cursors senaste arbete med lokala sandlådor är ett bra exempel på att skräddarsy till macOS-, Linux- och Windows-specifikationer samtidigt som ett enhetligt API för agentlagret bibehålls.
På macOS utvärderades flera alternativ: App Sandbox, generiska containrar, fullständiga virtuella maskiner och en långlivad men "föråldrad" teknik som kallas Seatbelt. App Sandbox skulle ha krävt att varje binärfil som en agent kunde köra signerades, vilket dramatiskt ökade komplexiteten och till och med gav genererade binärfiler transitivt förtroende. Linux-containrar skulle ha tvingat macOS-användare till Linux-bara binärfiler, och fullfjädrade virtuella maskiner hade oacceptabel startfördröjning och minnesoverhead för interaktiva kodningsflöden.
Säkerhetsbälte, åtkomligt via sandbox-exec, visade sig vara det pragmatiska valet trots sin ålder. Det låter dig köra ett kommando under en sandlådeprofil som begränsar hela processträdet med finkornigt policyspråk: du kan vitlista eller blockera specifika systemanrop och begränsa läs-/skrivbehörigheter till riktade filer eller kataloger. Cursor genererar dessa policyer dynamiskt vid körning baserat på arbetsyta och administratörsinställningar plus användarens. .cursorignore, så ignorerade sökvägar blir tabu i sandlådan.
På Linux exponerar kärnan rätt primitiv – seccomp för syscall-filtrering och Landlock för filsystembegränsningar – men låter kompositionen vara upp till användarutrymmet. Istället för att förlita sig på befintliga OSS-omslag som inte stödde repospecifika ignoreringar som .cursorignore, Markören valde att orkestrera Landlock och seccomp direkt. Seccomp förbjuder farliga systemanrop; Landlock tillämpar sökvägsbaserade läs-/skrivregler, och låter dem till och med lägga sig över användarnas arbetsytor så att ignorerade filer är helt oåtkomliga eller ersätts av skyddade kopior som sandlådeprocesser inte kan läsa eller modifiera.
En subtilitet i Linux är prestanda: att montera om eller skriva om alla ignorerade filer är den långsammaste delen av sandbox-installationen. Uppskjuten filtrering i macOS-stil som kan se den exakta filsökvägen vid syscall-tillfället skulle förenkla detta, men Linux seccomp-bpf gör inte den sökvägsinspektionen enkel, så det finns en verklig teknisk avvägning mellan snäv isolering och starthastighet.
På Windows är det fortfarande svårare att bygga en verkligt likvärdig native sandlåda eftersom de flesta isoleringsprimitiver är optimerade för webbläsare och inte för allmänna utvecklingsverktyg. Cursor kör för närvarande en Linux-sandlåda inuti WSL2 för Windows-användare, och drar i huvudsak nytta av Linux-isolering tills rikare primitiver finns tillgängliga. De samarbetar med Microsoft för att exponera rätt funktioner så att Windows-agenter med tiden kan njuta av förstklassig, nativ sandlåda utan WSL som krycka.
Den gemensamma tråden mellan dessa operativsystemspecifika metoder är ett enhetligt sandbox-API ovanpå. Ur agentens synvinkel finns det bara ett "skalverktyg" med tydliga funktioner och regler. Under huven tillämpar Seatbelt, Landlock/seccomp eller WSL2-baserad isolering dessa regler olika beroende på plattform.
Att lära agenter att förstå och respektera sandlådan
En sandlåda hjälper bara om agenten kan förutse vad som kommer att fungera inuti den och när den behöver eskalera privilegier eller lämna lådan. Det låter självklart, men i praktiken krävdes det en förvånansvärt djupgående iteration av prompter och verktygsdesign för leverantörer som levererade kodningsagenter.
Det första steget som många team tog var att förbättra verktygsbeskrivningar, särskilt för skalkörning. Istället för ett generiskt verktyg som heter ”run_shell_command” anger beskrivningen explicit vilka resurser som är tillgängliga: om kommandot har filsystemsåtkomst, Git-åtkomst, nätverksåtkomst eller en helt offline-miljö beroende på användarkonfigurationen. Den dokumenterar också hur agenten kan begära utökade rättigheter (till exempel för att nå det publika internet) vid behov. Detta snabba ingenjörsarbete tenderar att vara mycket empiriskt: team kör gemensamma distributionsflöden, observerar var modellen felaktigt förutspår funktioner, justerar verktygsbeskrivningarna och upprepar.
Interna riktmärken som ”Cursor Bench” eller liknande utvärderingssviter används sedan för att jämföra agenternas prestanda med och utan sandboxing. Ett tidigt felläge var mycket konsekvent: agenten försökte blint upprepa samma felaktiga terminalkommando om och om igen istället för att inse att det stötte på en sandbox-begränsning. Utan en tydlig signal om varför kommandot misslyckades kunde modellen inte lära sig mönstret.
Lösningen var att explicit visa sandlådefel i verktygsutdata, ofta med en knuff om vad man skulle göra härnäst. När ett kommando blockerades på grund av en filsystems- eller nätverksregel började skalverktyget inkludera en kort förklaring som "blockerad av sandlåda: utgående nätverksåtkomst inaktiverad för den här sessionen" och, i vissa fall, en ledtråd om att agenten kunde be om utökade behörigheter. Efter denna förändring blev agenterna mycket mer motståndskraftiga: de slutade loopa på hopplösa kommandon och antingen justerade sin plan eller begärde den nödvändiga funktionen.
Offline-utvärderingar är användbara, men de berättar bara en del av historien. För att verkligen veta om sandboxing försämrar användarupplevelsen har team gradvis rullat ut sandboxstöd i produktion och övervakat felfrekvenser, slutförandetider och feedbackkanaler. I praktiken rapporterar leverantörer att en betydande andel av frågor på kompatibla plattformar nu körs helt inuti sandboxar – med företagskunder som NVIDIA bland de tidiga användarna – och att sandbox-agenter faktiskt pausar för godkännande cirka 40 % mer sällan i verkliga arbetsflöden, vilket sparar timmar av manuell granskning samtidigt som risken minskar.
Framöver finns det ett stort intresse för "native sandbox-agenter" – modeller som tränas direkt på begränsningarna i sin miljö. Istället för att behandla skal, webbläsare eller filsystem som abstrakta verktyg, skulle dessa agenter förstå att de lever i en snävt begränsad runtime, kan skriva långlivade skript och program och måste respektera randvillkor som "inget utgående nätverk" eller "arbetsytan är skrivskyddad". Den träningen skulle kunna göra dem mycket bättre på att planera säkra och effektiva handlingssekvenser utan att stöta på osynliga väggar.
Molnsandlådor: Cloudflare, Google Cloud, Heroku och andra
Utanför utvecklarens bärbara dator tävlar en stor våg av infrastrukturleverantörer om att erbjuda hostade sandlådor som är specifikt anpassade för AI-agenter. Deras mål är desamma – isolering, kontroll och prestanda – men avvägningarna ser lite annorlunda ut i molnskala.
Cloudflare-sandlådor, byggda ovanpå Cloudflare-containrar och nu allmänt tillgängliga, syftar till att se ut och kännas som fullständiga utvecklingsmiljöer för agenter. Varje sandlåda är en permanent, isolerad arbetsyta som du adresserar med namn. Om den är i viloläge startar den på begäran; om den är inaktiv pausar den automatiskt för att spara beräkningsförmåga och återupptas vid nästa begäran. Utvecklare (eller agenter) kan interagera med den via typbeskrivna metoder som exec, gitCheckout, writeFileoch mer, med hjälp av ett JavaScript/TypeScript SDK.
Ett av de knepigaste molnproblemen är säker autentisering inifrån agentsandlådor. Agenter behöver ofta kontakta privata tjänster, men du vill inte ha råa autentiseringsuppgifter liggande i miljövariabler. Cloudflare injicerar autentiseringsuppgifter på nätverkets proxylager och mappar utgående förfrågningar från värden till anpassad logik som kopplar tokens från säker lagring. Sandlådeprocessen ser aldrig de verkliga hemligheterna, men anropet autentiseras fortfarande. Denna design stöder dynamisk, identitetsmedveten autentiseringsinjektion och fungerar bra med Workers-bindningar.
För terminaltunga arbetsflöden lade Cloudflare till en fullständig PTY-upplevelse (pseudoterminal) kopplad över WebSockets och xterm.js. Agenter och människor kan öppna live-shell-sessioner, avbryta processer, återansluta senare och spela upp tidigare utdata. Varje PTY har sin egen arbetskatalog och miljö, och utdata buffras på servern så att återanslutande klienter kan komma ikapp missade loggar.
Utöver rå skalåtkomst erbjuder Cloudflare även ihållande "kodkörningskontexter" för språk som Python, JavaScript och TypeScript. Till skillnad från många snippet runners som kör varje fragment isolerat, behåller dessa kontexter variabler, importer och tillstånd över anrop, ungefär som en Jupyter-anteckningsbok. Agenter kan läsa in data i ett anrop, transformera det i ett annat och rendera diagram eller HTML-tabeller utan att ständigt behöva omtolka och importera allt.
För webbutvecklingsuppgifter stöder Cloudflare-sandlådor bakgrundsprocesser, hälsokontroller och URL:er för förhandsgranskning i realtid. En agent kan börja npm run dev som ett bakgrundsjobb, övervaka loggar tills servern är redo och exponera sedan porten bakom en offentlig förhandsgransknings-URL. Metoder som waitForPort() or waitForLog() låta agenter sekvensera åtgärder baserat på verkliga beredskapssignaler istället för naiva sleep(2s) gissningar.
Händelsedrivna arbetsflöden får ett uppsving från filbevakningsprimitiver som stöds av Linux inotify-mekanism. En agent kan prenumerera på ändringar under /workspace/src och automatiskt köra om tester eller byggen när TypeScript-filer ändras. Detta är samma återkopplingsslinga som mänskliga utvecklare förlitar sig på, men gjord agent-native via API:er som sandbox.watch() och serverskickade händelseströmmar.
För att sluta livscykeln lanserar Cloudflare verkliga snapshots – tillståndsregistreringar på VM-nivå som kan återställas på några sekunder från R2-lagring. Snapshots behåller filsystemets tillstånd, operativsystemkonfiguration, installerade beroenden och datafiler; framtida versioner kommer också att återställa minnets tillstånd i realtid för omedelbar återupptagning. Agenter (eller orkestratorer) kan utlösa snapshots programmatiskt för kontrollpunkter eller utbredda scenarier, och sedan förgrena flera sandlådor från samma snapshot för att utforska parallella hypoteser isolerat.
Prismässigt har Cloudflare gått över till en modell med endast aktiv CPU: du debiteras för CPU-cykler som faktiskt används, inte för inaktiv tid medan agenter väntar på LLM:er. Kombinerat med enorma samtidighetstak för "lite" och större instanser gör detta det möjligt att köra en stor flotta av agenter utan att bränna pengar på vilande containrar.
Google Clouds GKE Agent Sandbox är däremot djupt integrerad med Kubernetes och gVisor. Tanken är att låta dig köra agentarbetsbelastningar i isolerade poddar inuti dina egna kluster. Du skapar ett GKE-kluster (Autopilot kan aktivera gVisor automatiskt, medan Standard-kluster behöver explicita runtime-klasser och gVisor-aktiverade nodpooler) och distribuerar sedan en Agent Sandbox-kontroller via versionsmanifest.
Två centrala anpassade resurser driver modellen: SandboxTemplate och SandboxWarmPool. SandboxTemplate fungerar som en återanvändbar ritning som specificerar en pod-mall (avbildning, portar, resurser, runtimeClassName: gvisor, etc.) för sandlådebaserade körningar, till exempel en Python-miljö. SandboxWarmPool håller ett konfigurerat antal förvärmda pods redo för nästan omedelbar användning, vilket undviker kallstarter när en agent behöver en fräsch miljö på under en sekund.
A Sandbox Router Tjänsten fungerar sedan som gateway för trafik mellan klienter och dessa isolerade poddar. Under utveckling kan du tunnla trafik genom kubectl port-forward utan att exponera publika IP-adresser. I produktion skulle du normalt ge routern korrekt ingress och mTLS. På klientsidan tillhandahåller Google ett Python "Agentic Sandbox"-bibliotek som täcker hela livscykeln: skapa ett sandbox-anspråk från en mall, vänta tills det är klart, kör shell-kommandon och rensa upp när det är klart.
Allt detta är fortfarande "bara Kubernetes" under huven, men förpackat i en sammanhängande berättelse för agentkörningar. gVisor ger process- och systemanropsisolering, SandboxTemplate standardiserar konfigurationer, WarmPool löser startfördröjning och routern plus Python-klienten gör det bekvämt för LLM-centrerade appar.
Heroku, å andra sidan, lutar sig mot en mycket mogen byggsten: engångsdynor. I åratal har Heroku-användare kört ad hoc-jobb – migreringar, underhållsskript, administrationsuppgifter – i kortlivade dynos som startar på begäran och stängs av när de är klara. Heroku återanvände denna infrastruktur som sandlådor för kodkörning, lanserade tillsammans med deras Managed Inference- och Agents-erbjudanden. En agent skriver Python-, Ruby-, Node- eller Go-kodsnuttar; Heroku kör dem inuti kortlivade dynos och strömmar tillbaka resultaten, vilket begränsar explosionsradien till den kortlivade containern.
Du kan komma åt dessa sandlådor antingen via inbyggda verktyg i Herokus Agents API eller genom att distribuera Model Context Protocol (MCP)-servrar med öppen källkod. MCP-servrar exponerar standardiserade verktygsslutpunkter, så klienter som Agentforce, Claude Desktop eller Cursor kan behandla Herokus sandlåda som en generisk, fjärrkodexekveringsbackend. Varje server stöder runtime-specifika gränser (som max_calls per agentloop) för att förhindra att agenter snurrar i snäva, kostsamma loopar.
LangChains Deep Agents ger ytterligare en dimension genom att integrera med tredjepartsleverantörer av sandboxar som Runloop, Daytona och Modal. Mönstret är enkelt: Deep Agent fortsätter att köras var du vill (lokalt eller i molnet), men närhelst den behöver köra kommandon, skapa filer eller exekvera kod vidarebefordras dessa operationer till en fjärransluten sandlåda. Installationsskript kan förladda miljövariabler, klona databaser, installera verktyg och mer, så att varje agent får en ren, kontrollerad miljö. Kontexthanterare hanterar sedan skapande och rensning, även om dokumentationen starkt rekommenderar att övervaka leverantörsdashboards för eventuella glömda långvariga sandlådor.
Prestanda, tillstånd och förgrening: varför hastighet är viktig för agenter
En långsam men ultrasäker sandlåda kommer i praktiken att kringgås; utvecklarverktyg lever eller dör på latens. Kodningsagenter beter sig inte som nattliga batchjobb. De kör interaktiva loopar: läser lite kod, föreslår redigeringar, kör tester, analyserar loggar, anropar verktyg, väntar på människor och upprepar sedan. I verkliga sessioner utforskar de också flera grenar av ett problem, överger vissa vägar och återgår till andra senare.
Det är därför plattformar som Freestyle är besatta av VM-livscykeltider på under en sekund och rik tillståndssemantik. Deras virtuella maskiner är kompletta Linux-maskiner med root-åtkomst, systemd-tjänster, stöd för kapslad virtualisering och fullständigt nätverk. Dokumentationen hävdar provisionering på under 800 ms från API-anrop till körande virtuell maskin, paus/återupptagning på under 100 ms och möjligheten att snapshota eller forka virtuella maskiner mitt i körning med minimal prestandaförlust. De anger explicit webbläsarens tillstånd som en förmånstagare: om en agent har drivit en webbläsare till ett intressant tillstånd kan den forka den virtuella maskinen 20 gånger från samma snapshot istället för att återskapa det tillståndet från grunden.
Googles SandboxWarmPool för GKE uttrycker samma idé i Kubernetes-termer: ha en pool av förvärmda poddar runtomkring så att agenter inte betalar fulla kallstartsavgifter för varje ny körning. Daytonas ögonblicksbildsbaserade arbetsytor plus policyer för automatisk stopp/arkivering/borttagning justerar livscykeln för olika typer av sessioner: aktiva utvecklingsmiljöer, kortlivade experiment och långlivade baslinjer.
E2B:s betoning på bakgrundsjobb, bevakningsbara kataloger, isolerade filsystem och återanvändbara volymer är en annan sida av samma mynt. Dessa funktioner låter en agent hålla en utvecklingsserver eller testharness igång medan de utforskar kodändringar, eller delar en permanent volym över flera tillfälliga sandlådor över tid. Utan detta slutar det med att agenter utlöser engångskommandon och förlorar kontext, vilket minskar produktiviteten.
Ett bra sätt att utvärdera vilken sandlåda som helst för agentarbete är att ställa några raka frågor. Kan jag starta en ny miljö på långt under en sekund? Kan jag spara och återställa tillstånd utan problem, inklusive delvisa byggen eller webbläsarsessioner? Kan jag förgrena tillstånd för parallell utforskning? Kan jag behålla långlivade men resurseffektiva arbetsytor för "kom tillbaka senare"-flöden? Ju fler "ja"-svar du får, desto mer kan dina agenter bete sig som riktiga ingenjörer istället för tillståndslösa skriptkörare.
Hemligheter, nätverkspolicy och arbetsyteförtroende som det verkliga kontrollplanet
Även med perfekt värdisolering är det lätt att bygga ett osäkert system om man ignorerar hemligheter, nätverkspolicy och arbetsyteförtroende. Dockers sandbox-dokumentation är uppfriskande uppriktig på den här fronten. Mikro-VM:n och dess privata Docker-daemon utgör den huvudsakliga förtroendegränsen mot värden. Inuti den virtuella maskinen har agenten dock fullständig kontroll på rotnivå, och den delade arbetsytan är monterad för läsning och skrivning. Som standard återspeglas alla filredigeringar omedelbart på värden. Utgående nätverk nekas som standard och tillåts endast via explicita regler, och HTTP-förfrågningar använder en proxy på värdsidan som kan injicera autentiseringsuppgifter utan att exponera råa hemligheter för den virtuella maskinen.
Det betyder att isolering av värden bara är steg ett; du måste fortfarande tänka på vad agenten kan göra med arbetsytan och omvärlden. Dockers dokumentation varnar uttryckligen för att om en agent redigerar skript som människor senare kör – Git-hooks, CI-konfigurationer, IDE-uppgiftsdefinitioner, Makefile mål, package.json skript – skadan kan "hoppa" tillbaka till värden eller CI-systemen när dessa skript körs. De framhäver till och med att Git hookar in .git/ dyk inte upp i git diff, vilket gör det enklare att tyst behålla skadlig logik.
Proxyhantering av autentiseringsuppgifter är kraftfullt men subtilt. Dockers utgående proxy säkerställer att hemligheter stannar utanför den virtuella maskinen, men tillåter fortfarande agenten att agera med dessa identiteter mot tillåtna värdar. Vissa flöden – som att skriva anpassade miljövariabler i filer som /etc/sandbox-persistent.sh – bryt denna gräns genom att avsiktligt lagra hemligheter inuti den virtuella maskinen, vilket bara är säkert om du verkligen litar på agenten och sandlådan.
Konfigurationsomfattningen är lika viktig som hemligheter. Dockers FAQ noterar att konfigurationer på användarnivå som ~/.claude or ~/.codex på värden kopieras inte till sandlådan; endast projektbaserad konfiguration i den delade arbetsytan är synlig. Anthropics konfigurationsdokumentation förstärker att inställningar på projektnivå – verktyg, behörigheter, MCP-servrar, hooks – åsidosätter inställningar på användarnivå och delas mellan team. Med andra ord, vilka policyer, instruktioner och plugins som helst som du kopplar till repot blir den huvudsakliga ytan som agenten ser.
OpenAIs vägledning om färdigheter lyfter fram liknande punkter i ett något annorlunda ordförråd. Färdigheter (verktygspaket) kan medföra risker för dataexfiltrering baserade på snabb injektion. Dokumentationen varnar för att exponera en okurerad, offentlig marknadsplats för färdigheter direkt för slutanvändare, eftersom skadliga SKILL.md-filer kan åsidosätta policyer, utlösa destruktiva åtgärder eller läcka privata data. De rekommenderar att utvecklarfärdigheter granskas, begränsas till specifika arbetsflöden, dölja åtgärder med stor inverkan bakom extra godkännanden och policykontroller, och behandlas som en del av din hotmodell.
När du sätter ihop delarna sträcker sig det "riktiga" kontrollplanet för agentsandlådor över fyra lager. Värdisolering skyddar dina maskiner och klusternoder. Arbetsyteförtroende skyddar den framtida människan eller CI som kommer att köra filer som produceras inuti sandlådan. Nätverkspolicy skyddar externa system och privata datakällor. Autentiseringsuppgifter skyddar de identiteter genom vilka agenten kan agera. En robust design har svar för alla fyra, inte bara den första.
Utöver det behöver du fortfarande en hälsosam skepsis mot snabb injektion och agentkapning. NIST, OWASP och OpenAI beskriver alla varianter av samma mönster: otillförlitlig inmatning – en README, en webbsida, en loggfil – bäddar in skadliga instruktioner som omdirigerar agentens beteende. Hämtningsförstärkt generering och finjustering löser inte detta magiskt. En välinstrumenterad sandlåda plus en bra policy kan inte förhindra att modellen luras, men de kan dramatiskt minska nackdelen när den blir det.
Molnplattformar och agentkörningar börjar koda dessa lärdomar. Hemliga proxyservrar, utgående domäner på tillåtelselistan, konfigurationer med reposcope, underagenter med snävare funktioner, hook-baserade godkännandeflöden och reproducerbara sandlådor är alla bitar i samma pussel: acceptera att modeller är felbara och konstruera miljön så att kostnaden för den felbarheten förblir begränsad.
I lokala och molnbaserade konfigurationer är en exekveringssandlåda för agenter bäst att betrakta som en noggrant dragen linje: den gör inte modellen smartare, den gör dess misstag mindre katastrofala och mer observerbara. Med rätt blandning av filsystem, process, nätverk, hemlighet och livscykelkontroller, plus smart inlärning av agenten om sin miljö, kan du låta AI-system klona repositorier, köra tester, starta webbläsare och till och med röra vid produktionsliknande system – utan att ge dem nycklarna till allt du bryr dig om.
Det betyder att isolering av värden bara är steg ett; du måste fortfarande tänka på vad agenten kan göra med arbetsytan och omvärlden, inklusive riesgos como. fjärrkörning av kod. Dockers dokumentation varnar uttryckligen för att om en agent redigerar skript som människor senare kör – Git-hooks, CI-konfigurationer, IDE-uppgiftsdefinitioner, Makefile mål, package.json skript – skadan kan "hoppa" tillbaka till värden eller CI-systemen när dessa skript körs.
