GitHub setter Copilot-agenten i sandkasse

GitHub har åpnet en public preview for lokale og skybaserte sandkasser i GitHub Copilot. Det høres teknisk ut. Det er nettopp derfor det er viktig.

Copilot er ikke lenger bare en tekstboks i editoren. GitHub beskriver selv skiftet: Copilot utvikler seg til en agentisk kodepartner som kan kjøre verktøy, utføre kommandoer og endre filer på vegne av utvikleren. Da holder det ikke å stole på at utvikleren trykker ja og nei riktig hele dagen. Agenten trenger et avgrenset sted å jobbe.

Den nye funksjonen gir to slike steder. Lokalt kan Copilot kjøre shell-kommandoer i en sandbox med begrenset tilgang til filsystem, nettverk og systemressurser. Den aktiveres i en Copilot CLI-økt med /sandbox enable. I skyen kan brukeren starte en isolert Linux-økt hos GitHub med copilot --cloud. Cloud-sandkassen er adskilt fra lokal maskin og fra andre økter, og GitHub sier den arver organisasjonens eksisterende Copilot cloud agent policies.

Dette er en praktisk sikkerhetsmarkør for agentbruk i utviklingsmiljøer. Mange virksomheter har brukt det siste året på å skrive retningslinjer for AI-koding. Nå kommer kontrollene nærmere stedet risikoen oppstår: i terminalen, i repoet, i avhengigheter, i build-script og i nettverkstilgang.

Fra assistent til kjøremiljø

Forskjellen på vanlig Copilot og agentisk Copilot er handlingsevne. Når verktøyet bare foreslår kode, er risikoen i stor grad knyttet til kvalitet, lisens, lekkasje av kontekst og utviklerens review. Når verktøyet kan kjøre kommandoer, installere pakker, endre filer og jobbe parallelt, blir det også en runtime-risiko.

Det er denne overgangen sandkassene forsøker å adressere. GitHub skriver at agentisk utvikling er interaktiv, stateful og parallell. Det betyr at en agentøkt kan ha egen tilstand, gjøre flere steg, feile underveis, hente verktøy og bygge videre på tidligere handlinger. For CISO er det ikke lenger nok å spørre hvilken modell som brukes. Spørsmålet blir hvor agenten får lov til å kjøre, hva den får se, hva den får skrive, og hvilken nettverkstilgang den har mens den arbeider.

Lokale sandkasser bygger ifølge GitHub på Microsoft MXC-teknologi og skal fungere på macOS, Linux og Windows. Det er viktig i blandede utviklermiljøer, særlig der Mac er vanlig i produktteam og Windows er standard i resten av virksomheten. GitHub sier også at lokale sandbox-policyer kan konfigureres og håndheves sentralt via Microsoft Intune og andre MDM-plattformer. Dermed flyttes agentkontroll inn i eksisterende endpoint-styring, ikke bare inn i GitHub-administrasjonen.

Sky-sandkasser gir både kontroll og ny kost

Skyvarianten er mer enn en sikkerhetsfunksjon. Den gjør også agentarbeid mer flyttbart. GitHub-dokumentasjonen beskriver skyøktene som fullt isolerte, midlertidige Linux-miljøer som hostes av GitHub. En stoppet økt kan få lagret tilstand som snapshot, slik at arbeidet kan tas opp igjen senere. Flere oppgaver kan kjøres parallelt uten å bruke lokal maskinkraft.

Det gir utviklingsteam bedre skalerbarhet. Det gir også nye styringsspørsmål. Hvem får starte skyøkter? Hvilke repoer kan kobles til? Hvilke secrets og miljøvariabler kan følge med? Hvor lenge lagres snapshots? Hvilke logger finnes når noe går galt?

GitHub gjør det klart at sky-sandkasser må aktiveres av organisasjons- eller enterprise-eier gjennom en egen Cloud Sandbox access-policy. Det er riktig kontrollpunkt. Norske virksomheter bør likevel ikke behandle dette som en enkel toggle. Dette bør inn i samme beslutningsløp som CI/CD-runnere, utvikler-VM-er og privilegert tilgang til kildekode.

Kostnadsmodellen er også verdt å merke seg. Lokal sandboxing er inkludert i ordinær Copilot-lisens. Sky-sandkasser prises etter bruk, med egne målere for compute, minne og snapshot-lagring. Det gjør Copilot mer lik skyinfrastruktur. Bruken må budsjetteres, måles og begrenses. CFO kommer inn bakveien, som vanlig når utviklere får nye leketøy med metertakst.

Konsekvens for norske virksomheter

For norske CIO-er er dette et tegn på at AI-koding må styres som plattform, ikke som individuell produktivitetsapp. Copilot, Claude Code, Codex og andre agentverktøy flytter seg raskt fra tekstforslag til utførende arbeidsflater. Da må standardkravene oppdateres.

Et minimum bør være policy for lokale sandkasser, sentral endpoint-håndheving, klare regler for nettverkstilgang, repo-tilgang, secrets, logging og godkjenning før agenten får gjøre sensitive handlinger. Utviklere bør også vite når de jobber lokalt, når arbeidet går i GitHubs sky, og hvilke data som kan havne i en lagret økt.

For CISO er poenget enkelt: agenten skal ikke ha mer frihet enn den trenger for oppgaven. Den bør starte i et avgrenset miljø, med eksplisitt tilgang og sporbarhet. Hvis agenten må ut av sandkassen, bør det være et bevisst unntak, ikke standardmodus.

For styrer er signalet at AI-agentene nå nærmer seg reell produksjonsmakt i programvareleveransen. De kan øke tempoet. De kan også akselerere feil, avhengighetsangrep og datalekkasje. Sandkasser løser ikke hele problemet, men de viser hvor modenhetskravet er på vei: Fra 'har dere en AI-policy?' til 'hvor kjører agentene deres, og hvem kontrollerer dem?'

Dette bør inn i anskaffelser allerede nå. Spør leverandørene om isolasjon, policyhåndheving, logging, secrets-håndtering, datalagring, kosttak og eksport av revisjonsspor. Hvis svaret er uklart, er produktet ikke klart for bred utrulling i en regulert virksomhet.

Kilder og medier

Primærkilde: GitHub Changelog, 'Cloud and local sandboxes for GitHub Copilot now in public preview', publisert 2. juni 2026. https://github.blog/changelog/2026-06-02-cloud-and-local-sandboxes-for-github-copilot-now-in-public-preview

Supplerende dokumentasjon: GitHub Docs, 'About cloud and local sandboxes for GitHub Copilot'. https://docs.github.com/copilot/concepts/about-cloud-and-local-sandboxes

Thumbnail: OpenAI Image 2 / hogby.ai