Googles private AI-hukommelse gemmer i skyen – to fund står åbne

Google DeepMind beskrev i sin meddelelse fra 23. september 2026 en plan for vedvarende hukommelse i Private AI Compute. Personlig kontekst skal lagres krypteret i skyen, så en AI-assistent kan bruge den på tværs af enheder. Adgangen skal afhænge af hemmeligheder på brugerens egne enheder, og oplysningerne skal kun dekrypteres midlertidigt i et isoleret servermiljø. Der er tale om en beskrevet arkitektur, ikke en funktion med en annonceret dato for bred lancering.

En gennemgang hos Model Current oplyser, at Trail of Bits registrerede ti sikkerhedsfund i den bestilte vurdering: otte var lukket, mens to stod åbne i den endelige rapport. Det ene vedrører risikoen for at genskabe en ældre, krypteret hukommelse efter sletning. Det andet, som blev vurderet til høj alvorlighed, handler om forkortede hashværdier af modelsvar, der forlader det beskyttede miljø. Fundene beskriver begrænsninger ved designet; de er ikke en melding om et konstateret databrud.

Fra enheden til den krypterede database

Vedvarende hukommelse ændrer, hvad Private AI Compute skal bevare mellem forespørgsler. Den tidligere behandling var uden varig tilstand: Når en opgave sluttede, blev dens midlertidige kontekst slettet. Skal en samtale eller opgave fortsætte på en anden enhed, må relevant kontekst derimod kunne findes igen. Den nye arkitektur giver derfor hver bruger en særskilt hukommelsesdatabase, som kan ligge i Googles øvrige infrastruktur i krypteret form.

Adgangen begynder på brugerens enhed. En hemmelighed dér beskytter den nøgle, som kan åbne datanøglen til brugerens hukommelse. Når assistenten har brug for tidligere kontekst, opretter enheden en godkendt, krypteret forbindelse til et sikkert servermiljø. Først inden for den isolerede enklave kan den relevante hukommelse dekrypteres og læses. Lageret uden for enklaven håndterer den krypterede database, men skal ikke kunne læse dens indhold.

Under behandlingen kan systemet hente relevant kontekst, bruge den sammen med den aktuelle forespørgsel og gemme nye oplysninger. Den varige hukommelse krypteres igen, mens den midlertidige kontekst skal forsvinde, når opgaven er afsluttet. Det skel er centralt: Kryptering beskytter posterne i lageret, mens enklavens isolation skal beskytte dem i det korte tidsrum, hvor modellen må arbejde med læsbare data. Beskyttelsen afhænger dermed både af nøglerne, den isolerede hardware og kontrollen med den software, der får adgang.

To åbne fund rammer hver sin grænse

Den offentliggjorte rapport fra Trail of Bits bygger på en afgrænset gennemgang af trusselsmodellen og udvalgte komponenter i den sikre serverhukommelse. Den omfatter også kode, som ikke er offentligt tilgængelig. Vurderingen siger derfor noget om det gennemgåede design og de efterfølgende rettelser, men kan ikke i sig selv dokumentere sikkerheden i enhver fremtidig produktudgave eller i hele den omgivende tjeneste.

Fundet om sletning gælder forskellen mellem at fjerne en post fra den aktuelle database og at forhindre, at en ældre version lægges tilbage. Hvis lagerlaget under særlige forhold kan genskabe en tidligere krypteret database, er sletningen ikke beskyttet af en kryptografisk garanti mod tilbagerulning. Det giver ikke en tilfældig udenforstående adgang til brugerens indhold; scenariet forudsætter kontrol over den relevante lagerhåndtering. Men det viser, at kryptering af gemte data og endelig sletning er forskellige sikkerhedsløfter.

Det alvorligere fund vedrører en kontrol, der skal opdage, om modellen gengiver indhold. Forkortede hashværdier af dele af modelsvar sendes uden for den betroede grænse til denne kontrol. De er ikke hele læsbare svar, men de er afledt af svarene og kan derfor røbe information under de rette betingelser. Den beskrevne udnyttelse kræver privilegeret intern adgang og er teknisk vanskelig. Alvorlighedsvurderingen angiver fundets mulige sikkerhedsmæssige betydning, ikke at nogen allerede har udnyttet det.

Hukommelsen kræver en genkendelig bruger

En varig database skal kunne findes igen, når den samme bruger sender en ny forespørgsel. Den del af tjenesten, som vælger den rette krypterede hukommelse, behøver derfor en stabil brugeridentifikator. Identifikatoren giver ikke i sig selv adgang til indholdet, men gør det muligt at forbinde forespørgsler over tid. Det er en anden privatlivsgrænse end beskyttelsen af selve databasen: Indhold kan være ulæseligt for lagerlaget, selv om tjenesten må kunne genkende, hvilken hukommelse en forespørgsel hører til.

Det forklarer også, hvorfor den planlagte hukommelse ikke kan give samme anonymitet på netværksniveau som behandling uden gemt tilstand. En enkeltstående opgave kan afsluttes uden at finde tidligere brugerdata frem; hukommelsestjenesten må bevare forbindelsen til den rigtige database. Den beskrevne beskyttelse retter sig derfor mod, hvem der kan åbne indholdet, og hvilken godkendt serverkode der må behandle det. Krypterede poster kan stadig være et mål for angreb mod identifikation, nøglehåndtering eller adgangen til enklaven.

Serverkoden bliver næste afgørende kontrol

Før en enhed frigiver adgang til hukommelsen, skal den kunne kontrollere, at serveren kører godkendt software. En offentlig registrering af serverkoden skal gøre den kontrol mulig og knytte den kode, som får adgang til data, til en kendt udgave. Det er særligt vigtigt for en tjeneste, hvor de personlige oplysninger bliver liggende mellem sessioner: En senere ændring af den godkendte kode kan få betydning for den samme lagrede hukommelse.

Den konkrete virkning for brugere afhænger nu af, hvordan arkitekturen indføres i produkter, og om de åbne fund bliver løst eller håndteret med dokumenterede begrænsninger. Endnu er der ikke offentliggjort en bred lanceringsdato eller fulde brugerregler for lagring og sletning. Indtil de foreligger, beskriver nyheden en teknisk vej til sammenhængende AI-hukommelse på tværs af enheder og de sikkerhedsgrænser, som en sådan tjeneste skal leve op til.