AWS gir AI-kode egne MicroVM-sandkasser

AWS gjør et sikkerhetsproblem i AI-hverdagen til en egen skytjeneste. Lambda MicroVMs er en ny serverless byggestein i AWS Lambda som lar utviklere kjøre kode fra brukere eller AI i isolerte, stateful miljøer med virtuell maskin-nivå isolasjon.

Det høres teknisk ut. Det er også teknisk. Men for CISO-er og plattformeiere er nyheten konkret: AI-kode, kodeassistenter, sårbarhetsskannere, dataanalyseverktøy og interaktive utviklingsmiljøer trenger et sted å kjøre arbeid som virksomheten ikke fullt ut stoler på. AWS prøver å gjøre den sandkassen til en standardtjeneste.

Lambda MicroVMs bygger på Firecracker, den lette virtualiseringsteknologien AWS allerede bruker under Lambda. AWS oppgir at Firecracker har drevet over 15 billioner Lambda-kall per måned. Nyheten er at kundene nå får direkte kontroll over mer langlevde, isolerte miljøer, ikke bare funksjonskall.

Hvorfor dette treffer AI-agenter

De fleste virksomheter som tester kodeagenter møter samme problem. Agenten kan skrive kode, kjøre tester, hente pakker, analysere filer og foreslå endringer. Før eller siden må noe kjøres. Det kan være kode modellen selv skrev, kode fra en bruker, et avhengighetsbibliotek eller et testskript fra internett. Da er spørsmålet enkelt: Hvor skal dette skje?

Vanlige containere er raske, men deler kernel og krever hard sikkerhetsarbeid hvis koden er ubetrodd. Tradisjonelle virtuelle maskiner gir sterkere isolasjon, men er tyngre å starte og drifte. Funksjonstjenester er gode for korte hendelser, men ikke for interaktive økter som skal beholde minne, filer og prosesser over tid.

AWS posisjonerer Lambda MicroVMs midt i dette gapet. Hver bruker eller sesjon får sitt eget isolerte miljø. Miljøet kan starte raskt fra snapshot, beholde minne og disk mens økten lever, og pauses ved inaktivitet slik at kostnaden faller uten at tilstanden forsvinner.

For AI-agenter er dette ikke pynt. Det er grunnmur. En agent som skal løse reelle oppgaver trenger en write-run-verify-sløyfe. Den må kunne prøve, feile, lese resultatet og korrigere seg selv. Uten isolert kjøring blir valget ofte enten for lite autonomi eller for høy risiko.

Stateful sandkasser endrer plattformdesignet

AWS beskriver tre hovedegenskaper. Den første er virtuell maskin-nivå isolasjon gjennom Firecracker. Hver sesjon kjører i sin egen MicroVM uten delt kernel og uten delte ressurser mellom brukere. Det reduserer risikoen for at ubetrodd kode får tilgang til andre miljøer eller underliggende systemer.

Den andre er rask start og gjenopptakelse. Utvikleren lager et MicroVM Image ved å levere Dockerfile og kode som zip-artefakt i S3. Lambda bygger miljøet, initialiserer applikasjonen og tar et snapshot av minne og disk. Nye MicroVM-er kan deretter starte fra dette pre-initialiserte snapshotet, ikke fra kald boot.

Den tredje er tilstand over tid. En MicroVM kan holde prosesser, installerte pakker, filer og lastede modeller tilgjengelige gjennom økten. Den kan også suspenderes etter en idle-policy og vekkes igjen når trafikk kommer. AWS oppgir støtte for opptil åtte timer total runtime, opptil 16 vCPU, 32 GB minne og 32 GB disk per MicroVM.

Dette gjør tjenesten mer relevant for agentarbeid enn vanlig funksjonskjøring. Agenten kan ha et arbeidsområde som ligner en liten maskin, men med serverless livssyklus. Det passer for kodeassistenter, interaktive notebooks, sårbarhetsskanning, analysejobber og verktøy der brukeren kommer tilbake til samme kontekst.

Styringsverdien ligger i standardisering

Mange virksomheter bygger allerede egne sandkasser for AI-arbeid. Noen bruker Kubernetes, noen bruker isolerte containere, noen bruker kortlivede virtuelle maskiner, og noen lar dessverre agentene kjøre for nær utviklerens egen maskin. Fellesnevneren er at sikkerheten ofte blir et internt plattformprosjekt.

Lambda MicroVMs kan gjøre deler av dette mer standardisert. Det betyr ikke at AWS løser hele sikkerhetsmodellen. Kunden må fortsatt styre identitet, nettverk, datatilgang, logging, pakker, artefakter og hva agenten faktisk får gjøre. Men isolasjon og livssyklus blir en mer definert byggestein.

For CISO-er er det særlig viktig å skille mellom sandkasse og tillatelse. En MicroVM kan begrense skade, men den bør ikke få ubegrenset nettverkstilgang, produksjonsnøkler eller fri vei til interne datakilder. Den bør behandles som et kontrollert arbeidsrom for ubetrodd kode, ikke som en trygg sone der alt er lov.

Hva ledelsen bør spørre om

Virksomheter som innfører kodeagenter bør nå stille mer presise krav til plattformen. Hvor kjøres agentgenerert kode? Er miljøet isolert på VM-nivå eller container-nivå? Hvor lenge lever filer og minne? Hvem kan hente artefakter ut? Blir nettverkstrafikk logget? Kan man reprodusere hva agenten kjørte hvis noe går galt?

Det bør også settes grenser for kost. Stateful økter er nyttige, men kan bli dyre dersom mange agenter holder miljøer varme eller kjører lange analyser. Idle-policy, automatisk suspendering og maksimal runtime bør inn i standardoppsettet fra dag én.

AWS Lambda MicroVMs er derfor ikke bare en ny Lambda-variant. Det er et tegn på at skyplattformene begynner å bygge infrastruktur for agentalderen. Når AI går fra tekstforslag til faktisk kjøring av kode, blir isolasjon, logging og livssyklus like viktig som modellvalg.

Kilder og medier

Primærkilde: AWS News Blog, “Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs”, https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/

Kildekreditering: AWS News Blog.

Thumbnail: OpenAI Image 2 / hogby.ai