Agent Compute Engine: Google hevder 10x densitet, men ingen prising eller boot-tid er publisert
Google Cloud lanserte 22. oktober 2026 tjenesten Agent Compute Engine, som gir hver AI-agent sin egen maskinvareisolerte mikro-VM uten standard nettverksgrensesnitt og uten én eneste backend-legitimasjon inni sandkassen. Tjenesten kjører allerede internt for Googles egne Gemini-agenter — men alle ytelsestall sirkulert så langt gjelder motparten Agent Substrate, som er åpent tilgjengelig på GKE, ikke selve ACE, og ingen boot-tid, densitet eller prising er publisert for tjenesten kundene faktisk får.
Nyhetsdelen
På konferansene AGNTCon + MCPCon 22. oktober 2026 lanserte Google Cloud Agent Compute Engine (ACE), en compute-tjeneste som ifølge selskapet gir hver AI-agent sin egen maskinvareisolerte mikro-VM med «containerhastighet og null legitimasjoner holdt inni sandkassen» (Google Cloud-bloggen). Innlegget er forfattet av Google Distinguished Engineers Ramanathan Venkatapathy og Rohit Jnagal.
To ting skiller lanseringen fra en ren annonse: Tjenesten kjører allerede i produksjon internt i Google, der den ifølge selskapet driver Gemini som agent for arbeidsoppgaver, og en kundepreview er annonsert «i de kommende månedene» — uten fast dato.
Motparten Agent Substrate har dessuten vært tilgjengelig på GKE siden 15. september 2026. Det er hit alle tallene Google har offentliggjort hører hjemme — et skille som er lett å miste i dekningsflommen, men som er avgjørende for hva som faktisk er uavhengig etterprøvd.
Hvorfor Google hevder et nytt formaat er nødvendig
Googles motivasjon, som så langt kun er fremsatt i selskapets egne ord, bygger på to påstander om at verken VM-er eller containere passer agenttrafikk:
- VM-er er for trege. «Hver VM starter og konfigurerer en hel maskin, så å starte, suspendere og gjenoppta en tar sekunder til minutter. Agenter starter, pauser og gjenopptar konstant, så overheaden hoper seg opp», skriver Google i blogginnlegget. Agenter skifter konstant mellom aktivitet og hvile, og oppstartskostnaden multipliseres.
- Containere er for utette. Containere mangler ifølge Google full isolasjon og kontroll på kernel- og root-nivå — et problem når sandkassens oppgave er å kjøre kode, shell-kommandoer og nettlesere som modellen ber om.
Den ytre rammen er ifølge Google at «agentic-arbeidsbelastninger har vokst til å bli en av de raskest ekspanderende forbrukerne av compute og lagring i flåten vår», og at tradisjonelle compute-primitiver ikke kan kjøre hundrevis av millioner agenter med nødvendig kostnad og latens. Dette er selskapsutsagn om egen flåte, ikke målinger uavhengige parter kan etterprøve.
«Hjernen» utenfor, «hendene» inni
Googles deling av hver agent i to deler er kjernen i sikkerhetsmodellen. «Harnessen, eller 'hjernen', kaller modellen og bestemmer hva som skal gjøres neste. Sandkassen, eller 'hendene', kjører koden, shell-kommandoene og nettleseren som modellen ber om», forklarer blogginnlegget. Avgjørende er at hjernen ligger utenfor sandkassen — det er derfor hendene kan holdes helt uten legitimasjoner.
Nettverket der det ikke finnes noe nettverk
ACE-mikro-VM-ene har ifølge den tekniske gjennomgangen ingen standard nettverkskort, ingen default gateway og ingen direkte VPC-tilgang. All trafikk krysser i stedet en virtio-vsock-grense — en host-lokal kanal — til en lokal proxy og deretter til en ekstern gateway (MarkTechPost).
Der skjer det sentrale: Gjesten holder bare et session-scoped SPIFFE-sertifikat og en kortlivd identitetstoken. Agent Gateway bytter inn de reelle backend-credentials in flight, etter at policiesjekker er utført. Med andre ord: Selv om en agent eksfiltrerer alt den kan se innvendig, får angriperen ifølge designet kun en identitet som gjelder én enkelt sesjon i én enkelt sandkasse — ikke en nøkkel inn i backendsystemene.
Fire identiteter per agent
Identitetsmodellen har fire nivåer per agent-arbeidsbelastning: brukerens identitet, en delegert on-behalf-of-identitet, en kortlevd Agent Workload Identity som brukes til sandkasstrafikk, og en Agent Workforce Identity. Formuleringen i gjennomgangen er konkret: «Workload-identiteten er verdiløs for direkte API-kall hvis den eksfiltreres. Den identifiserer bare hvilken sandkasse som sendte en pakke.» Dette er Googles egen designpremiss — og nettopp derfor er det et utsagn som bør testes, ikke bare troes.
Tallene — og hva de faktisk gjelder
Google har offentliggjort benchmark-tall, men de gjelder Agent Substrate på GKE, ikke selve ACE:
- Opptil 10 ganger høyere compute-densitet enn tradisjonell compute
- 500 aktiveringer per sekund med under 500 ms suspend/resume, målt i et benchmark med 200 000 agenter
- Over 1 000 sovende agenter per host
Alle disse tallene er Googles egne, ikke-uavhengig verifiserte, og de to sekundære kildene sporer tilbake til samme annonsering. For selve Agent Compute Engine er ingen boot-tid, densitet eller prising publisert — MarkTechPost oppsummerer gapet direkte: «Ingen publisert boot-tid, densitet, prising eller preview-dato for selve Agent Compute Engine.»
Teknologien som posisjoneres som grunnlaget for densitets- og sikkerhetspåstandene, er copy-on-write minnedeling (sovende agenter deler minne i stedet for å holde egne kopier) og Titanium IPU-teknologi for sikkerhet (Crypto Briefing). Google hevder blant annet at copy-on-write-tilnærmingen har levert 10x-densitetsbenchmarkene — men også dette er selskapets egne utsagn. I Agent Substrate på GKE er isolasjonsalternativene Cloud Hypervisor-mikro-VM-er eller gVisor-sandboxes.
Hva som gjenstår før tallene kan tas som fasit
Flere sentrale spørsmål står åpne:
- Ingen uavhengige benchmarks. Alle ytelsestall kommer fra Google selv, om et produkt (Agent Substrate) som er beslektet med, men ikke identisk med, det kundene får tilgang til.
- Ingen kundestemmer. ACE kjører hos Google selv, men ingen eksterne kunder har beskrevet erfaringer.
- Vag preview-tidslinje. «Kommende måneder» er den presisjonen som finnes.
- Ukjent prising. Uten pristall er densitetspåstandene vanskelige å omsette til kostnadsbesparelser.
- Utestående mekanikk. Detaljene i checkpointing av sovende agenter og de fullstendige nettverksinternene er foreløpig kjent primært gjennom sekundære oppsummeringer av Googles tekniske innlegg.
Det konkrete å holde utkikk etter: kundepreviewen (som gjør egne målinger mulig), publiserte ACE-spesifikke tall for boot-tid og densitet, og en prismodell. Før det er Googles null-credentials-arkitektur en veldokumentert design — og påstandene om fart og densitet fortsatt selskapets ord mot egen sak.