Docker Sandboxes gir AI-agenter frihet uten tilgang til hele maskinen

Docker Sandboxes lar AI-agenter arbeide fritt i en egen microVM uten å gi dem tilgang til hele maskinen din. Codex, Claude Code og andre kodeagenter kan installere pakker, endre konfigurasjon, kjøre tjenester og starte Docker-containere, mens operativsystemet og Docker-motoren på vertsmaskinen holdes utenfor rekkevidde.

Det treffer et problem som blir større jo mer selvstendige agentene blir. En agent som må spørre om godkjenning før hver kommando, er tryggere, men treg. Fjerner du alle spørsmålene og lar den kjøre uten tilsyn, kan en feil kommando, en skadelig pakke eller en dårlig tolket instruksjon få langt større spillerom enn du hadde tenkt.

Docker forsøker å flytte sikkerhetsgrensen ut av selve agenten og ned i infrastrukturen. Det er en fornuftig retning. Men ordet «sandbox» betyr ikke at alt er ufarlig: Prosjektmappen er som standard delt med lese- og skrivetilgang, og nettverksreglene må passe til oppgaven. Veggene er solide, men du må fortsatt velge hva som skal stå innenfor dem.

Hva er Docker Sandboxes?

Docker Sandboxes er et gratis kommandolinjeverktøy som kjører hver AI-kodeagent i en isolert microVM med eget filsystem, nettverk og egen Docker-motor. Ifølge den offisielle Docker-dokumentasjonen kan verktøyet også brukes kommersielt; sentral styring for organisasjoner krever et eget betalt abonnement.

En microVM er tyngre enn en vanlig container, men gir en tydeligere sikkerhetsgrense. Hver sandbox har sin egen kjerne og deler ikke prosesser eller minne med vertsmaskinen. Agenten får sudo og stor frihet inne i miljøet, men ingen direkte tilgang til vertens Docker-daemon eller filer utenfor områdene du uttrykkelig deler. Private nettverk og vertens localhost er blokkert som standard.

Docker støtter blant annet Codex, Claude Code, Gemini CLI, Copilot, Cursor, OpenCode, Kiro og et vanlig shell-oppsett. Det betyr at samme isolasjonslag kan brukes på tvers av agentene, i stedet for at hvert verktøy må få sine egne hjemmelagde sikkerhetsregler.

Dette gjør Docker Sandboxes nært beslektet med sikkerhetsarbeidet rundt sandboxing og guardrails i OpenAI Agents SDK, men på et annet lag. Guardrails kan styre hva agenten får lov til å be om. MicroVM-en begrenser hva den faktisk kan nå hvis noe likevel går galt.

Hvorfor er en microVM bedre enn en vanlig container?

En vanlig container deler kjernen med vertsmaskinen. Docker Sandboxes bruker i stedet hypervisor-isolasjon og gir hver agent en egen Docker-motor. Docker sammenligner selv arkitekturen med containere og Docker-in-Docker: microVM-en bruker mer ressurser, men gir den autonome agenten full Docker-funksjonalitet uten å dele vertens daemon.

Det siste er viktig. Å montere Docker-socketen inn i en vanlig container gir i praksis svært omfattende kontroll over verten. En kodeagent som skal bygge images, starte databaser og teste et helt system, trenger ofte Docker. Med Sandboxes skjer dette mot en privat daemon inne i microVM-en, ikke mot den som styrer resten av maskinen.

Agenten kan dermed få lov til å gjøre ganske mye: kjøre apt, pip og npm, endre systemkonfigurasjon, starte tjenester og opprette nye containere. Når sandboxen fjernes, forsvinner VM-en, pakkene, Docker-imagene og containerne med den. Du slipper at et eksperiment etterlater halve kjøkkenbenken inne i utviklingsmiljøet ditt.

Hva kan agenten fortsatt endre på maskinen din?

Prosjektmappen er det viktigste unntaket. I standardmodusen monteres arbeidsområdet direkte inn i microVM-en med lese- og skrivetilgang. Endrer eller sletter agenten en fil, vises det umiddelbart i arbeidskopien på vertsmaskinen. Sandboxen beskytter resten av systemet, men den gjør ikke prosjektfilene skrivebeskyttet.

Det gjelder også skjulte filer, byggeskript, Git-hooks, CI-konfigurasjon, Makefile og skript i package.json. Docker advarer spesielt om at Git-hooks ligger under .git/ og derfor ikke nødvendigvis dukker opp i en vanlig git diff. Kodegjennomgang er fortsatt en del av sikkerhetsmodellen. En hypervisor kan ikke vurdere om endringen i deploy-skriptet var klok.

Vil du beskytte den virkelige arbeidskopien mot endringer fra agenten, kan du opprette sandboxen i clone mode:

sbx run --clone codex

Da monteres vertens repository skrivebeskyttet, mens agenten arbeider i en privat klone inne i VM-en. Endringene må hentes eller pushes før sandboxen slettes. --clone må velges når miljøet opprettes, hovedområdet må være et Git-repository, og modusen kan ikke slås på i etterkant uten å fjerne og opprette sandboxen på nytt. Repositoryet på verten er fortsatt lesbart, også filer som ikke er sporet av Git eller er utelatt via .gitignore, for eksempel en .env-fil. Clone mode beskytter mot endringer, ikke innsyn.

Hvordan styres nettverk og hemmeligheter?

All HTTP- og HTTPS-trafikk går gjennom en proxy på vertsmaskinen. Utgangspunktet er deny-by-default, mens rå TCP, UDP og ICMP er blokkert. Ved første oppstart velger du mellom Open, Balanced og Locked Down. Balanced tillater vanlige utviklingstjenester og blokkerer resten; Locked Down krever at også modelltilbyderen tillates uttrykkelig.

Reglene kan inspiseres med sbx policy ls og utvides for ett konkret domene. Trenger prosjektet npm-registeret, kan det for eksempel åpnes slik:

sbx policy allow network registry.npmjs.org

Dette er mer nyttig enn et enkelt nettverk av eller på. En agent kan få tilgang til GitHub, et pakkeregister og modell-API-et uten samtidig å få fri utgang til ethvert domene en avhengighet måtte finne på å kontakte.

API-nøkler kan lagres med sbx secret. Proxyen setter dem inn i utgående HTTP-headere, mens den rå nøkkelverdien ikke legges inn i VM-en. Det reduserer risikoen for at agenten skriver nøkkelen til en logg eller leser den fra en miljøvariabel. Lokale MCP-servere er derimot et uttrykkelig tillitspunkt: De kjører på verten og bruker vertens rettigheter, selv om agenten kaller dem gjennom MCP-gatewayen.

Er miljøene virkelig disposable?

Ja, men de slettes ikke automatisk når agenten avslutter. En sandbox beholder installerte pakker, Docker-images, historikk og konfigurasjon når den stoppes. Det gjør at du kan fortsette senere uten å bygge opp hele miljøet på nytt. Først sbx rm sletter VM-en og innholdet i den.

Den grunnleggende arbeidsflyten er enkel:

sbx run codex
sbx ls
sbx stop <sandbox-navn>
sbx rm <sandbox-navn>

Ordet «disposable» beskriver altså at miljøet kan kastes samlet, ikke at det er en ny, ren VM for hver kommando. Det er en god mellomting for lange agentoppgaver: Cache, pakker og containere overlever en pause, mens hele miljøet kan fjernes når jobben er ferdig.

Hver sandbox har sin egen image-cache og deler ikke Docker-lag med andre sandboxes. Det gir ryddig isolasjon, men bruker mer diskplass hvis du kjører mange agenter parallelt. Stopp frigjør heller ikke denne plassen. Gamle miljøer må faktisk fjernes.

Hva kreves for å komme i gang?

Docker Sandboxes støtter macOS 14 eller nyere på Apple Silicon, Windows 11 på x86-64 og Ubuntu 24.04 eller nyere på x86-64 eller Arm. Windows krever Windows Hypervisor Platform, mens Linux krever KVM. Docker Desktop er ikke nødvendig.

På Ubuntu installeres docker-sbx fra Dockers repository, og brukeren må være medlem av kvm-gruppen. Dockers oppstartsveiledning viser denne sekvensen:

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm
sbx login

Hvis lsmod | grep kvm ikke gir treff, vil sbx ikke starte. Kjører du Ubuntu inne i en annen VM, må nested virtualization være aktivert. Det er en reell begrensning for enkelte skyløsninger og virtuelle arbeidsflater, ikke en detalj som kan løses med enda en sudo og godt humør.

På Windows installeres verktøyet med winget install -h Docker.sbx, mens macOS bruker Homebrew. Deretter kreves Docker-innlogging og autentisering mot agenten du vil bruke. Selve sbx-verktøyet er gratis, men modellabonnement eller API-bruk kommer i tillegg.

Hvilke sikkerhetsvalg bør du ta først?

Start med å bestemme om agenten skal endre den virkelige arbeidskopien. For en kort, overvåket oppgave kan direkte montering være praktisk. For lange oppgaver, ukjent kode eller flere agenter på samme repository er --clone et tryggere utgangspunkt.

Deretter bør nettverkspolicyen strammes inn til det agenten faktisk trenger. Standardreglene blokkerer utgående trafikk som ikke er uttrykkelig tillatt, men Balanced-profilen åpner for vanlige utviklingsdomener, og enkelte tillatelser bruker brede jokertegn. sbx policy ls er derfor verdt å kjøre før en agent får arbeide uten tilsyn.

Til slutt bør delte agent-skills vurderes. Støttede agenter monterer som standard et felles skill-lager med lese- og skrivetilgang. Dermed kan én sandbox endre instruksjoner som senere lastes i en annen. Flagget --no-share-skills holder miljøet utenfor denne delte tillitsgrensen.

Dette er ikke argumenter mot Docker Sandboxes. Tvert imot viser de at verktøyet har en mer realistisk sikkerhetsmodell enn «agenten kjører i en VM, ferdig snakka». Isolasjon består av grenser, og dokumentasjonen er uvanlig tydelig på hvilke data som faktisk krysser dem.

Hvem er Docker Sandboxes nyttig for?

Verktøyet passer best når en kodeagent trenger mer frihet enn du vil gi den direkte på maskinen: lange refaktoreringer, bygging av containere, installasjon av avhengigheter, parallelle oppgaver og arbeid som skal fortsette uten at du godkjenner hver kommando.

For små bedrifter kan dette gjøre lokale agentarbeidsflyter enklere å standardisere. Det er samme grunn til at ferdig infrastruktur for skybaserte AI-agenter er interessant: Modellen er bare én del av systemet. Miljø, tilgang, hemmeligheter, nettverk og opprydding avgjør om agenten kan få ansvar i praksis.

Docker Sandboxes fjerner ikke behovet for Git, gjennomgang og gode sikkerhetsvalg. Det gjør heller ikke en ustabil agent mer pålitelig. Men det begrenser skadeområdet og lar agenten bruke et ekte utviklingsmiljø med egen Docker-motor. Det er et konkret steg fra en chatbot som foreslår kommandoer, til en agent som kan utføre dem innenfor vegger du kontrollerer.

Det er her Docker har truffet godt. Agenten får stor frihet på innsiden, mens du beholder kontrollen over prosjektkopien, nettverket, nøklene og levetiden til miljøet. Bare husk at standardvalgene er et utgangspunkt. En sandbox er først så trygg som grensene du faktisk setter.

Ofte stilte spørsmål

Er Docker Sandboxes gratis å bruke?

Ja. sbx-verktøyet er gratis, også for kommersielt arbeid. Du må fortsatt betale for eventuell modellbruk eller abonnement hos agentleverandøren. Sentral styring av nettverk, filsystem og MCP-policyer på organisasjonsnivå krever et separat betalt Docker-abonnement.

Trenger jeg Docker Desktop for å kjøre Docker Sandboxes?

Nei. Docker Desktop er ikke nødvendig. Du trenger macOS 14 eller nyere på Apple Silicon, Windows 11 med Windows Hypervisor Platform, eller Ubuntu 24.04 eller nyere med KVM og riktig tilgang til kvm-gruppen.

Kan en agent slette filene i prosjektet mitt?

Ja, i standardmodusen har agenten lese- og skrivetilgang til arbeidsmappen og kan endre eller slette filer der. Bruk --clone når du vil at agenten skal arbeide i en privat Git-klone mens repositoryet på vertsmaskinen monteres skrivebeskyttet.

Forsvinner sandboxen når agenten stopper?

Nei. Pakker, Docker-images, konfigurasjon og historikk overlever sbx stop, slik at arbeidet kan fortsette senere. Kjør sbx rm <sandbox-navn> for å slette microVM-en og innholdet. Prosjektfiler på verten beholdes.