Sikkerhedsforskere siger, at Google Clouds Vertex AI Agent Engine afslørede en alvorlig privilegierisiko gennem sin standardserviceagentmodel, der tillader en udrullet AI-agent at udtrække serviceagent-legitimationsoplysninger og dreje ind i følsomme ressourcer.Palo Alto Networks Unit 42 sagdeproblemet lod en ondsindet eller kompromitteret agent bevæge sig ud over sin tilsigtede opgave og læse data i kundens Google Cloud-projekt.
Forskerne beskrev problemet som en standard-tilladelsessvaghed, ikke en simpel fejl i hurtig håndtering. I deres test er en indsat agent bygget medGoogles agentudviklingssætkunne forespørge om metadatatjenesten, udtrække legitimationsoplysningerne for Vertex AI Reasoning Engine-serviceagenten og derefter bruge denne identitet til at få adgang til lagerdata inde i forbrugerprojektet.
Google indrammede ikke dette som en aktiv masseudnyttelsesbegivenhed i de materialer, jeg fandt. I stedet viser den offentlige optegnelse et sikkerhedsproblem, der er afsløret af forskeren, og som førte til, at Google opdaterede dokumentation og skubbede kunder i retning af strammere identitetskontrol såsom agentidentitet og mere eksplicit administration af servicekonti.
Hvad forskerne fandt
Enhed 42 sagde Per-projektet, Per-Product Service Agent eller P4SA, der er knyttet til en installeret Vertex AI-agent, havde som standard overdrevne tilladelser. De udtrak legitimationsoplysningerne forservice-<PROJECT-ID>@gcp-sa-aiplatform-re.iam.gserviceaccount.com, som Google dokumenterer som Vertex AI Reasoning Engine Service Agent.
Med disse legitimationsoplysninger sagde forskerne, at de kunne dreje ind ikundens eget Google Cloud-projektog få læseadgang til Google Cloud Storage buckets. Enhed 42 specifikt anførte tilladelser som f.eksstorage.buckets.get,storage.buckets.list,storage.objects.get, ogstorage.objects.listsom en del af den overdrevne adgang, de observerede.
De sagde også, at de samme legitimationsoplysninger afslørede adgang til begrænsede Google-ejede Artifact Registry-depoter knyttet til Vertex AI Reasoning Engine.Ifølge rapporten, at adgangen lader dem se og downloade interne containerbilleder forbundet med tjenesten, som de hævdede kunne afsløre proprietær kode og hjælpe med at kortlægge Googles interne softwareforsyningskæde.
Hvorfor problemet er vigtigt
Dette betyder noget, fordi AI-agenter nu fungerer som semi-autonome arbejdere i virksomhedsmiljøer. Hvis identiteten knyttet til den pågældende agent har mere adgang, end den burde, kan et ondsindet værktøj, promptmanipuleret agent eller kompromitteret implementering blive til et internt omdrejningspunkt. Det er det centrale "dobbeltagent"-scenarie, der er beskrevet i enhed 42.
Forskerne fandt også ud af, at de udtrukne legitimationsoplysninger gav adgang til et Google-administreret lejerprojekt, der blev brugt til agentforekomsten. I det miljø opdagede de filer som f.eksDockerfile.zip,code.pkl, ogrequirements.txt, sammen med referencer til interne Google Cloud Storage buckets. De sagde, at de ikke direkte kunne få adgang til mindst én begrænset intern bucket, men infrastrukturreferencerne afslørede stadig operationelle detaljer.
Nogle af de mere skræmmende downstream-scenarier i eksempelartiklen har brug for en strammere formulering. Enhed 42 diskuterede en Python pickle-fil og bemærkede, at pickle er historisk usikker, når upålidelige data bliver deserialiseret, men rapporten hævdede ikke en demonstreret produktionsbagdør gennem denne fil i Googles miljø. Den del skal forblive indrammet som et risikosignal, ikke som en bekræftet udnyttelsessti.
Hvad Google ændrede
Enhed 42 siger, at Google samarbejdedemed forskerne efter afsløring og revideret sin dokumentation for at forklare, hvordan Vertex AI bruger ressourcer, konti og agenter. Forskningssiden siger også, at Google ændrede ADK-implementeringsworkflowet efter opdagelsen og bemærkede, at den originale kodeeksempel, der blev brugt i forskningen, muligvis ikke længere virker i den aktuelle version.
Googles nuværende Vertex AI Agent Engine-dokumentation skubber nu kunderne mod stærkere identitetskontrol. Opsætningsvejledningen anbefaler, at du bruger agentidentitet til adgangsstyring, og Google siger, at agentidentitet giver organisationer mulighed for at give eller nægte adgang til førsteparts Google Cloud API'er og ressourcer pr. agent.
Google dokumenterer også, at udrullede agenter kan bruge enten agentidentitet eller tjenestekonti, og siger, at disse identiteter bestemmer, hvilke data og ressourcer agenten har adgang til. Det er den praktiske løsningsvej her: stop med at stole på brede standardtilladelser og flyt til eksplicit mindst-privilegeret identitetsdesign.
Nøglepunkter
- Enhed 42 sagde, at en indsat Vertex AI-agent kunne udtrække legitimationsoplysningerne for Vertex AI Reasoning Engine-serviceagenten.
- Forskerne sagde, at disse legitimationsoplysninger tillod læseadgang til data i kundens Google Cloud Storage buckets.
- De rapporterede også adgang til begrænsede Google-ejede Artifact Registry-depoter knyttet til Vertex AI Reasoning Engine-billeder.
- Google opdaterede dokumentation og ændrede ADK-implementeringsworkflowet efter offentliggørelse.
- Google anbefaler nu strammere identitetskontrol gennem agentidentitet og eksplicit servicekontoadministration.
Risikooversigtstabel
| Areal | Hvad forskerne rapporterede | Hvorfor det betyder noget |
|---|---|---|
| Serviceagent identitet | Vertex AI Reasoning Engine-serviceagent-legitimationsoplysninger kan udtrækkes fra det installerede miljø | Stjålne legitimationsoplysninger kan lade en agent handle uden for sin tilsigtede rolle. |
| Kundeprojektdata | Adgang til Cloud Storage-bøtte og objekttilladelser i forbrugerprojektet | Følsomme kundedata kan blive læsbare af en ondsindet agent. |
| Google-administreret infrastruktur | Adgang til begrænsede Artifact Registry-billeder og lejerprojektimplementeringsfiler | Synlighed af intern infrastruktur kan hjælpe med dybere forskning og opfølgende angreb. |
| Identitetsdesign | Overbroad standarder i stedet for mindste privilegier | AI-agenter bliver interne højrisiko-identiteter, hvis tilladelserne er for brede. |
| Afbødning | Agentidentitet og strammere servicekontokontrol | Begrænser, hvad en udstationeret agent kan nå, hvis den bliver misbrugt. |
Hvad organisationer skal gøre nu
- Gennemgå hver Vertex AI Agent Engine-implementering, og identificer, hvilken tjenesteidentitet den bruger.
- Erstat bred standardadgang med agentidentitet med mindst privilegium eller tætte servicekonti.
- Audit Cloud Storage, Artifact Registry og relaterede IAM-bindinger givet til Vertex AI-serviceagenter.
- Behandl AI-agenter som privilegerede arbejdsbelastninger, ikke kun applikationsfunktioner. Dette er den direkte lektie fra Unit 42-resultaterne.
FAQ
Hvad var Vertex AI-problemet?
Forskere sagde, at en installeret Vertex AI Agent Engine-instans kunne afsløre legitimationsoplysningerne for sin serviceagent, som derefter tillod adgang til følsomme ressourcer ud over agentens tilsigtede omfang.
Tillod dette angribere at læse kundedata?
Enhed 42 sagde ja, i deres testmiljø. De rapporterede læseadgang til alle Google Cloud Storage-bøttedata i forbrugerprojektet efter at have pivoteret med den stjålne serviceagent-identitet.
Fik forskerne direkte adgang til alle interne Google-systemer?
Nej. De rapporterede adgang til begrænsede Google-ejede Artifact Registry-depoter og lejerprojektudrulningsfiler, men de sagde også, at de manglede tilladelse til at få adgang til mindst én begrænset intern lagerplads, de identificerede.
Hvad er den anbefalede løsning?
Googles nuværende vejledning peger på stærkere identitetskontroller, især agentidentitet og snævert udvalgte tjenestekonti, snarere end brede standardtilladelser.