Google Cloud sender nå AI-agenter gjennom en sikkerhetssperre bygget på gVisor, det samme brukerromskjernen Google bruker til å isolere deler av Gemini. Funksjonen heter GKE Agent Sandbox, og den kan spinne opp 300 sandkasser i sekundet per klynge med underssekunds svartid, ifølge Google selv. Bak tallet ligger et konkret problem: agent-genererte kode og verktøykall er i dag en av de raskest voksende sikkerhetsrisikoene i skyinfrastruktur, og tradisjonelle containere var aldri designet for å stoppe en AI-agent som har blitt lurt av en prompt-injeksjon.
For norske og nordiske skyteam som allerede kjører Kubernetes i produksjon, er dette ikke en abstrakt nyhet. Mange selskaper eksperimenterer nå med kodende agenter, interne co-pilot-verktøy og autonome arbeidsflyter i GKE, AKS og EKS. Spørsmålet som følger er enkelt: hvem har ansvar når en agent kjører kode den selv har skrevet, og hva skjer hvis den koden er skadelig?
Hva er GKE Agent Sandbox?
GKE Agent Sandbox ble annonsert av Google Cloud under Google Cloud Next ’26, med en mer detaljert teknisk gjennomgang publisert i mai 2026 under titlen “Bringing you Agent Sandbox on GKE and Agent Substrate”. Produktet er en Kubernetes-innfødt infrastrukturlag bygget for å kjøre ikke-tiltrodd agent-generert kode, verktøykall og hele agenter uten å gi dem samme tillitsnivå som en vanlig applikasjonscontainer.
Den tekniske kjernen er gVisor, Googles åpne kildekode-sandkasse som setter inn et brukerromskjerne (kalt Sentry) mellom arbeidsbelastningen og vertsmaskinens kjerne. Systemkall fra den sandkassede koden fanges opp og filtreres av Sentry i stedet for å gå rett til Linux-kjernen. Det gir en ekstra isolasjonsgrense utover en vanlig container, men uten den tunge operativsystem-overheaden en full virtuell maskin krever. Google beskriver arkitekturen som “bygget med gVisor-kjerneisolasjon, den samme teknologien som sikrer Gemini”, ifølge Google Clouds offisielle produktkunngjøring.
I praksis legger Google til flere isolasjonslag samtidig: standard-avslå nettverkspolicy, egne tjenestekontoer per sandkasse, og et nytt konsept kalt SandboxWarmPool. I stedet for å bygge hvert kjøremiljø fra grunnen, holder GKE en pool av ferdiginitialiserte, friske sandkasser klare til bruk. Når en agent trenger et kjøremiljø, tildeles det direkte fra poolen, noe som eliminerer mye av kaldstart-forsinkelsen som normalt oppstår når en container eller mikro-VM må bygges fra scratch.
300 sandkasser i sekundet: hva betyr tallet egentlig?
Tallet som har fått mest oppmerksomhet er at Agent Sandbox-APIets integrerte varmepool kan allokere opptil 300 sandkasser i sekundet, per klynge, med 90 prosent av allokeringene fullført innen 200 millisekunder. Det samme tallet er gjentatt i Googles kunngjøring fra Next ’26, i samarbeidsmeldingen med Arm om Axion-prosessorer, og i Googles 2026-vurdering av Gartners Magic Quadrant for containerhåndtering.
Det er viktig å lese tallet riktig. Det gjelder per klynge, ikke per node, og det beskriver en varmepool-allokeringsrate under Googles egne testforhold, ikke en garantert universell produksjonskapasitet for alle kunder. Google har ikke offentliggjort alle benchmark-detaljer, som klyngestørrelse, bildestørrelse på sandkassene, CPU- og minneallokering eller arbeidsbelastningsmiks. Det betyr at tallet bør behandles som et leverandøroppgitt toppresultat, ikke en nøytral, tredjeparts-verifisert målestokk.
Likevel er selve designvalget interessant uavhengig av eksakt tall. Kodende agenter og verktøybrukende agenter har et helt annet arbeidsmønster enn tradisjonelle mikrotjenester: de skaper ofte mange korte kjøremiljøer i rask rekkefølge, ikke noen få langlevde pods. En arkitektur bygget rundt forhåndsvarmede, gjenbrukbare sandkasser svarer direkte på det mønsteret, og det er grunnen til at Google har valgt å bygge dette som en åpen Kubernetes-primitiv i stedet for en proprietær funksjon kun tilgjengelig gjennom Vertex AI.
Hvorfor nå? Sikkerhetsproblemet med agent-generert kode
Det underliggende sikkerhetsproblemet er strukturelt, ikke hypotetisk. En AI-agent omsetter naturlig språk til handling: skallkommandoer, pakkeinstallasjon, kodekjøring, filmanipulering, API-kall, nettleseraksjoner, databasespørringer og verktøykall. Et prompt-injeksjonsangrep kan få agenten til å behandle angriperkontrollert innhold som en instruksjon fra en legitim bruker. Hvis agenten deretter kjører kode med vertens rettigheter, filtilgang, nettverkstilgang eller skytillatelser, blir en modellfeil raskt til et konvensjonelt sikkerhetsbrudd.
GKE Agent Sandbox er posisjonert spesifikt for denne typen ikke-tiltrodd kjøring. Arkitekturen skal redusere skadeomfanget hvis en agent genererer skadelig kode, følger en indirekte prompt-injeksjon, kjører en infisert avhengighet, prosesserer fiendtlig repository- eller dokumentinnhold, eller kaller et verktøy med utrygge parametere. Men sandkassing løser ikke alt. Google Clouds eget materiale er tydelig på at teknologien må kombineres med strengt avgrensede tjenestekontoer, utgående trafikkontroll, hemmelighetsisolasjon, kortlevd lagring, kontroll av avhengigheter og bildekilder, revisjonslogging og utgangsvalidering. En sandkasse stopper ikke en agent fra å følge en skadelig instruks i utgangspunktet. Den begrenser hva agenten kan gjøre etter at den allerede har blitt lurt.
Dette skillet er kritisk for norske sikkerhetsteam som evaluerer agentinfrastruktur. Prompt-injeksjon er et instruksjons- og autorisasjonsproblem. gVisor-isolasjon er et skadeomfangsproblem. De to løser forskjellige deler av kjeden, og et selskap som kun investerer i sandkassing uten å også låse ned tjenestekontoer og utgående nettverkstrafikk, har fortsatt et åpent hull.
Historisk kontekst: gVisor er ikke nytt
Det som er nytt i 2026 er ikke gVisor selv, men skaleringen og repakkingen av teknologien for agentarbeidsbelastninger. gVisor har eksistert i mange år som Googles åpne kildekode-applikasjonskjerne, og har allerede vært brukt i GKE Sandbox, Cloud Run og deler av App Engine for å isolere ordinære containerbaserte arbeidsbelastninger. Google har også bekreftet at samme teknologi sikrer deler av Gemini-infrastrukturen.
Det historiske mønsteret er altså en gradvis utvidelse: fra generell containerisolasjon, til administrerte applikasjonsplattformer, til nå en dedikert Kubernetes-primitiv bygget spesifikt for AI-agenters kjøremønster. I juli 2026 kunngjorde Google i samarbeid med Anyscale at gVisor-sandkasser nå er tilgjengelige i distribuerte Ray-klynger på GKE, noe som utvider teknologien videre inn i maskinlæringstrening og forsterkende læring (RL). En senere Google-publikasjon om kostnadsoptimalisering hevder at kombinasjonen av Agent Sandbox og GKEs pause-og-gjenoppta-funksjoner kan øke agenttettheten med opptil 3,5 ganger og redusere kostnaden per agent med opptil 75 prosent for periodisk aktive agenter, i et konkret testscenario med en OpenClaw-type agent.
Konkurrentlandskapet: hvordan ligger AWS, Azure og Cloudflare?
Isolasjon av ikke-tiltrodd kode er ikke et nytt problem, og de andre store skyleverandørene har egne tilnærminger, selv om ingen av dem er en direkte funksjon-for-funksjon-kopi av Agent Sandbox.
AWS Firecracker bruker mikro-VM-er med en minimal gjestekjerne og en tynn virtuell maskinmonitor (VMM), i stedet for et brukerromskjerne lagt over en container. En mikro-VM har sin egen gjestekjerne og benytter maskinvarevirtualisering, designet for å redusere angrepsflaten og oppstartstiden. Avveiningen er tydelig: Firecracker gir en sterkere, mer VM-lik separasjon med en distinkt gjestekjerne, noe som kan være attraktivt når koden som kjøres er svært utiltrodd. gVisor gir lavere overhead og tettere integrasjon med Kubernetes og containermiljøer, noe som er mer attraktivt når arbeidsbelastningene er mange, korte og krever høy tetthet per node.
Azure har flere isolasjonsprimitiver, inkludert konfidensiell databehandling, sandkassede containertjenester og VM-baserte isolasjonsmodeller via AKS, Container Apps og Container Instances. Det finnes imidlertid ikke et enkelt Azure-produkt som er en direkte, publisert motpart til GKE Agent Sandbox. Sammenligninger bør derfor være tjenestespesifikke snarere enn en generell “Azure vs Google”-påstand.
Cloudflare har en annerledes, men relevant tilnærming. Workers isolerer JavaScript og WebAssembly i en isolate-basert kjøretid på kanten av nettet, mens Cloudflare Containers gir fullere containersemantikk og bredere kjøretidsstøtte. Cloudflare har i tillegg nylig oppgradert Containers-plattformen slik at den starter seks ganger raskere enn tidligere, og lagt til kjøretidsvalg av sandkassebilde og instanstype for agenter, samt filsystem-snapshots i offentlig betaversjon, alt styrt gjennom en Durable Object. Dette er optimalisert for raske, distribuerte forespørsler på kanten, et annet bruksmønster enn en Kubernetes-administrert agentklynge.
Google selv hevder, i materiale knyttet til lanseringen, at Agent Sandbox er den eneste administrerte sandkasseteknologien tilgjengelig blant de ledende hyperskala-skyene. Det er en markedsføringspåstand fra Google, ikke en uavhengig bekreftet vurdering, og den bør leses med det i bakhodet.
Sammenligningstabell: isolasjonsteknologier for AI-agenter
| Plattform | Primær isolasjonsmodell | Relevans for agent-kjøring | Status/tilgjengelighet |
|---|---|---|---|
| GKE Agent Sandbox | gVisor brukerromskjerne + Kubernetes-primitiv | Lett sandkassing for utiltrodd kode og verktøy, varmepool for høy allokeringsrate | Generelt tilgjengelig siden Next ’26, utvides gjennom 2026 |
| AWS Firecracker | Hardware-virtualiserte mikro-VM-er med minimal gjestekjerne | Sterkere VM-lik separasjon, nyttig for svært utiltrodde arbeidsbelastninger | Etablert, brukes i Lambda og Fargate |
| Azure (AKS/Container Apps) | Konfidensiell databehandling, sandkassede containere, VM-isolasjon | Tjenestespesifikk, ingen enkelt direkte motpart til Agent Sandbox | Varierer per tjeneste |
| Cloudflare Workers/Containers | Isolate-basert kjøretid (Workers) + containere med 6x raskere oppstart | Optimalisert for kortlevd, distribuert kjøring på kanten av nettet | Containers-oppgradering lansert i oktober 2026 |
| Cloud Run / App Engine | Administrert applikasjonssandkasse, delvis gVisor-relatert | Mer fullstendig administrert, mindre tilpassbar enn en Kubernetes-primitiv | Etablert siden tidligere generasjoner |
Hva kostnader og prisstruktur faktisk betyr
Google har ikke publisert en separat pris per sandkasse for Agent Sandbox. Kundene betaler i stedet for den underliggende GKE- og databehandlingsressursen: GKEs klyngehåndteringsavgift ligger på 0,10 dollar per klynge per time, og Autopilot-kunder betaler for CPU, minne og andre ressurser som er tildelt podene, mens Standard- eller nodepool-distribusjoner belastes for de underliggende Compute Engine-instansene så lenge nodene eksisterer.
Google har i tillegg publisert egne effektivitetspåstander. Selskapet hevder Agent Sandbox kan gi opptil 30 prosent bedre pris-ytelse på Axion-prosessorer enn sammenlignbare hyperskala-alternativer. I et senere kostnadsinnlegg hevder Google at kombinasjonen av Agent Sandbox og GKEs pause-og-gjenoppta-funksjoner kan øke agenttettheten med opptil 3,5 ganger og redusere kostnaden per agent med opptil 75 prosent for periodisk aktive agenter, i et spesifikt testscenario. Samme materiale hevder at gVisor kan øke antall agenter per vCPU med over 40 prosent og redusere kostnaden per agent med over 30 prosent i det siterte testscenarioet.
Disse tallene er leverandørpåstander knyttet til spesifikke konfigurasjoner og arbeidsbelastninger, ikke universelle prisgarantier. Et redaksjonelt poeng verdt å gjøre klart: norske skyteam bør kreve egne benchmarks på sin egen arbeidsbelastning før de legger kostnadsbesparelser inn i et budsjett, særlig siden FinOps-rapporter i 2026 allerede har vist at en betydelig andel av skyforbruket generelt sløses bort uten riktig overvåking.
Sitater og offisielle uttalelser fra Google Cloud
Google Cloud har i sin offisielle produktkommunikasjon brukt flere direkte formuleringer som er verdt å sitere ordrett, siden de definerer hvordan selskapet selv rammer inn teknologien og ambisjonsnivået:
I kunngjøringen av Agent Sandbox skriver Google Cloud: “Built with gVisor kernel isolation – the same technology securing Gemini – Agent Sandbox allows you to safely execute untrusted code, tools, and entire agents without sacrificing performance” (Google Cloud, kunngjøring under Next ’26). Oversatt til norsk er poenget at samme isolasjonsteknologi som sikrer Googles egen Gemini-modell, nå gjøres tilgjengelig som en generell Kubernetes-byggekloss for alle GKE-kunder.
I den mer tekniske oppfølgingen i mai 2026 beskriver Google Cloud produktet som: “Agent Sandbox is an open-source, cloud-native execution environment built on Kubernetes, designed specifically for the unique demands of AI agents” (Google Cloud, Agent Sandbox-innlegg). Formuleringen er viktig fordi den plasserer produktet som en åpen Kubernetes-standard (under Kubernetes SIG Apps), ikke bare en proprietær Google-funksjon låst til Vertex AI.
I kostnadsinnlegget fra juli 2026 skriver Google Cloud konkret om funksjonaliteten: “Secure code execution: We now provide a managed, sandboxed environment to run agent-generated code” (Google Cloud, kostnadsoptimalisering for agenter). Dette knytter sikkerhetsfunksjonen direkte til et kostnadsargument, noe som er en vanlig salgsvinkel for infrastrukturprodukter rettet mot plattformteam som må forsvare budsjetter internt.
Markedspåvirkning: hva betyr dette for GKE, EKS og AKS-konkurransen?
GKE Agent Sandbox kommer i en periode der alle tre store skyleverandører konkurrerer hardt om å eie infrastrukturlaget for agentisk AI, ikke bare modellaget. Google har tidligere markedsført GKE hypercluster, som skal kunne håndtere opptil en million akseleratorbrikker fra en enkelt kontrollplan, og Agent Sandbox ble lansert samtidig som en del av samme strategiske pakke.
For norske virksomheter som velger mellom EKS, AKS og GKE, endrer dette beslutningsbildet marginalt, men ikke dramatisk. EKS og AKS har begge egne sikkerhetsprimitiver for isolasjon, men ingen av dem har i skrivende stund publisert en direkte, navngitt motpart til Agent Sandbox med samme kombinasjon av Kubernetes-nativ integrasjon, varmepool-arkitektur og offentlig gjennomsiktig ytelsestall. Det gir Google et konkret differensieringspunkt i anbudsprosesser der agentsikkerhet er et eksplisitt krav, særlig i offentlig sektor og finanssektoren der norske tilsyn stiller stadig strengere krav til hvordan automatiserte systemer skal kunne revideres og begrenses.
Samtidig bør man være forsiktig med å overdrive effekten på kort sikt. De fleste norske skyteam har i dag ikke produksjonskritiske AI-agenter som kjører utiltrodd, agent-generert kode i stort volum. Lanseringen er mer en forberedelse for et marked som vokser raskt enn en respons på en akutt krise i dag. Det endrer seg trolig i løpet av 2027, i takt med at flere virksomheter flytter fra pilotprosjekter til produksjonsdrift av autonome agenter.
Hvem bør bry seg: praktiske bruksmønstre
- Plattformteam som allerede driver interne kodeassistenter eller AI-drevne CI/CD-pipeliner i GKE, og som trenger å isolere agentgenerert kode fra resten av klyngen.
- Selskaper som bygger kundevendte chatbot- eller agentprodukter der brukerinput kan inneholde skjulte instruksjoner (indirekte prompt-injeksjon) via dokumenter, nettsider eller API-svar.
- Forskningsteam som trener forsterkende læring (RL)-agenter og trenger mange korte, isolerte kjøremiljøer i rask rekkefølge, et scenario Google selv nevner i sin RL-spesifikke oppfølging fra september 2026.
- Sikkerhetsteam som allerede har definert policy for hvor agenter får lov til å kjøre kode, og som nå ser etter en teknisk mekanisme som matcher den policyen.
- FinOps-ansvarlige som ser på agentkostnader som en ny budsjettpost og vurderer om tetthetsgevinster fra sandkassing faktisk realiseres i egen arbeidsbelastning.
Begrensninger og det Google ikke sier
Det er flere ting i Googles kommunikasjon som bør leses med et kritisk blikk. Selskapet har ikke publisert et uavhengig revidert sikkerhetstestresultat som sammenligner gVisor-sandkassing direkte med Firecracker-mikro-VM-er under identiske arbeidsbelastninger. Påstanden om “opptil 30 prosent bedre pris-ytelse” refererer bredt til “andre hyperskala-skyer” uten å identifisere hvilke tjenester som faktisk ble sammenlignet.
Det finnes heller ingen offentlig dokumentert sikkerhetshendelse eller konkret innbrudd som direkte utløste lanseringen av produktet. Det er altså en forebyggende, markedsdrevet lansering snarere enn en respons på et kjent, navngitt angrep. Det betyr ikke at behovet er oppkonstruert, men det betyr at risikoen Google beskriver fortsatt i stor grad er fremtidsorientert for de fleste kunder, ikke en akutt brann som allerede brenner.
Til sist: markedsstørrelsen for agentisk AI i produksjon er fortsatt uklar. Det finnes ikke et pålitelig, uavhengig verifisert tall for hvor mange virksomheter som faktisk kjører AI-agenter med ekte produksjonsansvar i dag, og denne artikkelen vil derfor ikke gjette på et slikt tall. Enhver markedsstørrelse som oppgis for “agentisk AI” varierer kraftig avhengig av om man inkluderer enkle kopiloter, arbeidsflytautomatisering eller fullt autonome programvareagenter.
Teknisk oppsett: hvordan Agent Sandbox passer inn i en eksisterende GKE-klynge
For team som allerede kjører Kubernetes-overvåking med verktøy som Prometheus og Grafana, eller som bruker KEDA for autoskalering, introduserer Agent Sandbox et nytt lag å overvåke: sandkasse-allokering, varmepool-forbruk og nettverkspolicy-overtredelser. Fordi Agent Sandbox er bygget som en åpen Kubernetes-primitiv under SIG Apps, kan den i prinsippet integreres med eksisterende observerbarhetsstabel uten en full plattformmigrering.
Et typisk oppsett innebærer tre lag: selve sandkasseressursen definert som en Kubernetes-ressurstype, en varmepool-konfigurasjon som bestemmer hvor mange forhåndsinitialiserte miljøer som holdes klare, og en nettverkspolicy som som standard avslår all utgående trafikk med mindre den er eksplisitt tillatt. Det siste punktet er i praksis det mest kritiske for sikkerheten, siden en agent som ikke kan nå internett eller interne tjenester, har begrenset verdi som angrepsvektor selv om koden den kjører er skadelig.
Hva skjer med Kubernetes 1.34 og eksisterende klynger?
Agent Sandbox lanseres i en periode der Kubernetes-plattformen generelt gjennomgår rask endring, med Kubernetes 1.34 som nylig fikk oppdaterte sikkerhetspatcher og nærmer seg slutten av sin støtteperiode. Selv om disse to hendelsene ikke er direkte koblet, illustrerer de en bredere trend: Kubernetes-økosystemet beveger seg fra å være en generell orkestreringsplattform til å bli en sikkerhetskritisk kjøretid for AI-arbeidsbelastninger, der både versjonsoppgraderinger og agentisolasjon krever kontinuerlig oppmerksomhet fra plattformteam.
Det praktiske rådet til norske plattformteam er å behandle Agent Sandbox-evaluering som en del av den vanlige Kubernetes-oppgraderingssyklusen, ikke som et separat sikkerhetsprosjekt. Siden teknologien er bygget som en åpen primitiv, bør den i teorien følge samme oppgraderings- og støttesyklus som resten av GKE-kontrollplanet.
Fem prediksjoner for agentisolasjon i skyen fremover
- AWS og Microsoft vil trolig annonsere egne, mer eksplisitt navngitte agentsandkasse-produkter i løpet av 2027, i respons på Googles differensieringspunkt. Firecracker er allerede teknisk godt posisjonert for dette, så det mest sannsynlige scenarioet er en produktpakking rundt eksisterende mikro-VM-teknologi snarere enn en helt ny isolasjonsmekanisme.
- Uavhengige sikkerhetsforskere vil sannsynligvis publisere de første offentlige sandkasse-escape-funnene mot gVisor-baserte agentmiljøer innen 12-18 måneder, ettersom angrepsflaten vokser i takt med adopsjonen.
- Prissetting for agentinfrastruktur vil bevege seg mot tetthetsbaserte modeller (pris per aktiv agent eller per vCPU-tetthet) i stedet for ren ressursfakturering, drevet av konkurransetrykk på kostnad per agent.
- Norske og nordiske finans- og offentlige sektorer vil kreve dokumentert agentisolasjon som en del av leverandørvurderinger innen 2027, i tråd med den generelle trenden mot strengere krav til automatiserte beslutningssystemer.
- Kubernetes SIG Apps vil trolig standardisere en agentsandkasse-API på tvers av skyleverandører innen utgangen av 2027, slik at samme Kubernetes-manifest kan kjøre på GKE, EKS og AKS uten leverandørspesifikke tillegg, dersom nok leverandører går inn i samme SIG-samarbeid som Google allerede har startet.
Tabell: tidslinje for GKE Agent Sandbox i 2026
| Dato | Hendelse |
|---|---|
| 22. april 2026 | Google Cloud kunngjør GKE Agent Sandbox under Google Cloud Next ’26, sammen med GKE hypercluster |
| 22. april 2026 | Arm og Google Cloud kunngjør partnerskap med Axion-prosessorer og Kata Containers-støtte for Agent Sandbox |
| 20. mai 2026 | Google Cloud publiserer teknisk detaljinnlegg: “Bringing you Agent Sandbox on GKE and Agent Substrate” |
| Juli 2026 | Google og Anyscale introduserer gVisor-sandkasser i distribuerte Ray-klynger på GKE |
| Juli-august 2026 | Google publiserer kostnadsoptimaliseringsinnlegg: opptil 75 prosent lavere kostnad per agent i testscenario |
| September 2026 | Google publiserer oppfølging om bruk av Agent Sandbox for forsterkende læring (RL)-arbeidsbelastninger |
| September 2026 | Agent Sandbox nevnes i Googles vurdering av 2026 Gartner Magic Quadrant for containerhåndtering |
Hva norske skyteam bør gjøre nå
For team som allerede kjører GKE og eksperimenterer med agentisk AI, er det tre konkrete, lavkostnads første steg. Først: kartlegg hvilke eksisterende arbeidsbelastninger som faktisk kjører ikke-tiltrodd, agent-generert kode i dag, selv i pilotform, siden mange team underestimerer hvor mye kode som allerede genereres av interne kodeassistenter uten formell sikkerhetsgjennomgang. Andre: test Agent Sandbox i et ikke-produksjonsmiljø mot egen arbeidsbelastning for å verifisere om Googles tetthets- og kostnadspåstander faktisk holder, i stedet for å ta leverandørtallene for gitt. Tredje: sørg for at nettverkspolicy for standard-avslag er på plass uavhengig av om sandkasseteknologien tas i bruk, siden det alene lukker en stor del av risikoen ved utgående dataeksfiltrering fra en kompromittert agent.
For team som ikke bruker GKE, er hovedpoenget fortsatt relevant: still samme spørsmål til AWS- og Azure-representanter om hvordan de planlegger å isolere agentgenerert kode, og krev konkrete, navngitte produktsvar i stedet for generelle forsikringer om at “sikkerhet er en prioritet”. Markedet beveger seg raskt nok at et klart svar fra en leverandør i dag kan bli en reell differensiator i anbudsrunder neste år.
Ofte stilte spørsmål om GKE Agent Sandbox
Er GKE Agent Sandbox tilgjengelig i dag?
Ja, funksjonen ble kunngjort under Google Cloud Next ’26 i april 2026 og har siden blitt utvidet med flere funksjoner, inkludert støtte for distribuerte Ray-klynger og forsterkende læring-arbeidsbelastninger gjennom 2026.
Er gVisor det samme som en virtuell maskin?
Nei. gVisor setter inn et brukerromskjerne mellom arbeidsbelastningen og vertsmaskinens kjerne, men bruker ikke en full gjestekjerne eller maskinvarevirtualisering som en tradisjonell VM eller AWS Firecracker-mikro-VM gjør.
Betyr “300 sandkasser i sekundet” at min klynge automatisk kan kjøre dette?
Nei. Tallet er Googles egen oppgitte varmepool-allokeringsrate under selskapets testforhold, per klynge. Faktisk ytelse avhenger av klyngestørrelse, nodekonfigurasjon og arbeidsbelastning, og bør testes i eget miljø før det legges inn i kapasitetsplanlegging.
Løser Agent Sandbox prompt-injeksjon?
Nei. Prompt-injeksjon er et instruksjons- og autorisasjonsproblem, ikke et isolasjonsproblem. Agent Sandbox begrenser skadeomfanget etter at en agent allerede har blitt lurt, men forhindrer ikke selve lureriet.
Hva kreves for å bruke funksjonen?
Agent Sandbox er bygget som en Kubernetes-ressurstype under GKE og krever ikke et separat produktabonnement utover vanlig GKE- og Compute Engine-fakturering, samt klyngehåndteringsavgiften på 0,10 dollar per time.
Har AWS og Azure et direkte konkurrerende produkt?
Ikke med samme navn eller eksakt arkitektur. AWS har Firecracker-mikro-VM-er som kan brukes til lignende isolasjonsformål, og Azure har flere isolasjonsprimitiver via AKS og Container Apps, men ingen av dem har i skrivende stund publisert en direkte, navngitt Agent Sandbox-motpart med samme offentlige ytelsesdokumentasjon.
Er dette relevant for selskaper som ikke driver med AI-utvikling selv?
Ja, i økende grad. Mange selskaper bruker i dag kodeassistenter og interne automatiseringsverktøy som genererer og kjører kode uten at det alltid er tydelig definert som et “AI-agent-prosjekt”. Samme sikkerhetslogikk gjelder uavhengig av om det kalles agent, kopilot eller automatiseringsskript.
Hvor kan jeg lese Googles offisielle dokumentasjon?
Googles kunngjøring finnes på cloud.google.com, med tekniske detaljer i oppfølgingsinnlegget om Agent Sandbox på GKE og produktsiden for Google Kubernetes Engine.
