Sicherheitsforscher sagen, dass die Vertex AI Agent Engine von Google Cloud durch ihr standardmäßiges Service-Agent-Modell ein ernsthaftes Privilegienrisiko darstellt, da ein bereitgestellter KI-Agent Service-Agent-Anmeldeinformationen extrahieren und auf sensible Ressourcen zugreifen kann.Palo Alto Networks Unit 42 sagteDas Problem ermöglichte es einem böswilligen oder kompromittierten Agenten, über seine eigentliche Aufgabe hinauszugehen und Daten im Google Cloud-Projekt des Kunden zu lesen.
Die Forscher beschrieben das Problem als eine Schwachstelle bei Standardberechtigungen und nicht als einen einfachen Fehler in der Eingabeaufforderungsverarbeitung. In ihrem Test wurde ein bereitgestellter Agent mit erstelltDas Agent Development Kit von Googlekönnte den Metadatendienst abfragen, die Anmeldeinformationen des Vertex AI Reasoning Engine-Dienstagenten extrahieren und dann diese Identität verwenden, um auf Speicherdaten innerhalb des Verbraucherprojekts zuzugreifen.
Google hat dies in den von mir gefundenen Materialien nicht als aktives Massenausbeutungsereignis dargestellt. Stattdessen zeigen die öffentlichen Aufzeichnungen ein von Forschern aufgedecktes Sicherheitsproblem, das Google dazu veranlasste, die Dokumentation zu aktualisieren und Kunden zu strengeren Identitätskontrollen wie der Agentenidentität und einer expliziteren Verwaltung von Dienstkonten zu drängen.
Was die Forscher herausgefunden haben
Einheit 42 sagte das Pro-Projekt, Per-Product Service Agent oder P4SA, der an einen bereitgestellten Vertex AI-Agenten gebunden war, verfügte standardmäßig über übermäßige Berechtigungen. Sie extrahierten die Anmeldeinformationen fürservice-<PROJECT-ID>@gcp-sa-aiplatform-re.iam.gserviceaccount.com, den Google als Vertex AI Reasoning Engine Service Agent dokumentiert.
Mit diesen Referenzen, sagten die Forscher, könnten sie in die Zukunft einsteigenKundeneigenes Google Cloud-Projektund erhalten Sie Lesezugriff auf Google Cloud Storage-Buckets. In Einheit 42 wurden speziell Berechtigungen aufgeführt, zstorage.buckets.get,storage.buckets.list,storage.objects.get, Undstorage.objects.listals Teil des von ihnen beobachteten übermäßigen Zugriffs.
Sie sagten auch, dass dieselben Anmeldeinformationen den Zugriff auf eingeschränkte Google-eigene Artifact Registry-Repositories ermöglichten, die mit der Vertex AI Reasoning Engine verknüpft seien.Dem Bericht zufolge, dieser Zugriff ermöglichte es ihnen, mit dem Dienst verbundene interne Containerbilder anzuzeigen und herunterzuladen, die ihrer Meinung nach proprietären Code offenlegen und dabei helfen könnten, die interne Software-Lieferkette von Google abzubilden.
Warum das Problem wichtig ist
Dies ist wichtig, da KI-Agenten heute als halbautonome Mitarbeiter in Unternehmensumgebungen agieren. Wenn die mit diesem Agenten verbundene Identität mehr Zugriff bietet, als sie sollte, kann ein bösartiges Tool, ein durch Eingabeaufforderungen manipulierter Agent oder eine kompromittierte Bereitstellung zu einem internen Dreh- und Angelpunkt werden. Das ist das Kernszenario des „Doppelagenten“, das in Einheit 42 beschrieben wurde.
Die Forscher fanden außerdem heraus, dass die extrahierten Anmeldeinformationen Zugriff auf ein von Google verwaltetes Mandantenprojekt gewährten, das für die Agenteninstanz verwendet wurde. In dieser Umgebung entdeckten sie Dateien wieDockerfile.zip,code.pkl, Undrequirements.txt, zusammen mit Verweisen auf interne Google Cloud Storage-Buckets. Sie sagten, sie könnten nicht direkt auf mindestens einen eingeschränkten internen Bucket zugreifen, die Infrastrukturreferenzen legten jedoch immer noch Betriebsdetails offen.
Einige der gruseligeren Downstream-Szenarien im Beispielartikel erfordern eine engere Formulierung. Einheit 42 besprach zwar eine Python-Pickle-Datei und stellte fest, dass Pickle historisch gesehen unsicher war, wenn nicht vertrauenswürdige Daten deserialisiert wurden, der Bericht behauptete jedoch nicht, dass durch diese Datei in der Google-Umgebung eine Produktions-Hintertür nachgewiesen wurde. Dieser Teil sollte als Risikosignal und nicht als bestätigter Exploit-Pfad verstanden werden.
Was Google geändert hat
Einheit 42 sagt, Google habe zusammengearbeitetnach der Offenlegung mit den Forschern zusammen und überarbeitete die Dokumentation, um zu erklären, wie Vertex AI Ressourcen, Konten und Agenten nutzt. Auf der Forschungsseite heißt es außerdem, dass Google nach der Entdeckung den ADK-Bereitstellungsworkflow geändert habe und darauf hingewiesen habe, dass das ursprüngliche Codebeispiel, das in der Forschung verwendet wurde, in der aktuellen Version möglicherweise nicht mehr funktioniert.
Die aktuelle Dokumentation zur Vertex AI Agent Engine von Google drängt Kunden nun zu strengeren Identitätskontrollen. In der Einrichtungsanleitung wird die Verwendung der Agentenidentität für die Zugriffsverwaltung empfohlen, und Google gibt an, dass die Agentenidentität es Unternehmen ermöglicht, den Zugriff auf Erstanbieter-APIs und -Ressourcen von Google Cloud für jeden einzelnen Agenten zu gewähren oder zu verweigern.
Google dokumentiert außerdem, dass bereitgestellte Agenten entweder Agentenidentitäten oder Dienstkonten verwenden können, und sagt, dass diese Identitäten bestimmen, auf welche Daten und Ressourcen der Agent zugreifen kann. Das ist hier der praktische Lösungsweg: Hören Sie auf, sich auf umfassende Standardberechtigungen zu verlassen, und wechseln Sie zu einem expliziten Identitätsdesign mit den geringsten Rechten.
Wichtige Punkte
- Einheit 42 sagte, ein eingesetzter Vertex AI-Agent könne die Anmeldeinformationen des Vertex AI Reasoning Engine-Dienstagenten extrahieren.
- Die Forscher sagten, dass diese Anmeldeinformationen den Lesezugriff auf Daten in den Google Cloud Storage-Buckets der Kunden ermöglichten.
- Sie berichteten auch über den Zugriff auf eingeschränkte Google-eigene Artifact Registry-Repositories, die mit Bildern der Vertex AI Reasoning Engine verknüpft waren.
- Nach der Offenlegung hat Google die Dokumentation aktualisiert und den ADK-Bereitstellungsworkflow geändert.
- Google empfiehlt jetzt eine strengere Identitätskontrolle durch Agentenidentität und explizite Dienstkontoverwaltung.
Risikoübersichtstabelle
| Bereich | Was Forscher berichteten | Warum es wichtig ist |
|---|---|---|
| Identität des Service-Agenten | Die Anmeldeinformationen des Vertex AI Reasoning Engine-Dienstagenten könnten aus der bereitgestellten Umgebung extrahiert werden | Gestohlene Zugangsdaten können dazu führen, dass ein Agent außerhalb seiner vorgesehenen Rolle agiert. |
| Kundenprojektdaten | Zugriff auf Cloud Storage-Bucket- und Objektberechtigungen im Verbraucherprojekt | Sensible Kundendaten könnten für einen böswilligen Agenten lesbar werden. |
| Von Google verwaltete Infrastruktur | Zugriff auf eingeschränkte Artifact Registry-Images und Bereitstellungsdateien für Mandantenprojekte | Die Transparenz der internen Infrastruktur kann bei tiefergehenden Untersuchungen und Folgeangriffen hilfreich sein. |
| Identitätsdesign | Überbreite Standardeinstellungen anstelle der geringsten Rechte | KI-Agenten werden zu risikoreichen internen Identitäten, wenn die Berechtigungen zu weit gefasst sind. |
| Schadensbegrenzung | Agentenidentität und strengere Dienstkontokontrollen | Begrenzt, was ein bereitgestellter Agent erreichen kann, wenn er missbraucht wird. |
Was Organisationen jetzt tun sollten
- Überprüfen Sie jede Bereitstellung der Vertex AI Agent Engine und ermitteln Sie, welche Dienstidentität sie verwendet.
- Ersetzen Sie den umfassenden Standardzugriff durch eine Agentenidentität mit den geringsten Rechten oder eng begrenzte Dienstkonten.
- Überwachen Sie Cloud Storage, Artifact Registry und zugehörige IAM-Bindungen, die Vertex AI-Dienstagenten gewährt werden.
- Behandeln Sie KI-Agenten als privilegierte Workloads und nicht nur als Anwendungsfunktionen. Dies ist die direkte Lehre aus den Erkenntnissen der Einheit 42.
FAQ
Was war das Vertex AI-Problem?
Forscher sagten, dass eine bereitgestellte Vertex AI Agent Engine-Instanz die Anmeldeinformationen ihres Service-Agenten offenlegen könnte, was dann den Zugriff auf sensible Ressourcen über den vorgesehenen Bereich des Agenten hinaus ermöglichen könnte.
Konnten Angreifer dadurch Kundendaten auslesen?
Einheit 42 sagte in ihrer Testumgebung „Ja“. Sie berichteten über Lesezugriff auf alle Google Cloud Storage-Bucket-Daten innerhalb des Verbraucherprojekts nach dem Pivot mit der gestohlenen Service-Agent-Identität.
Bekamen die Forscher direkten Zugriff auf alle internen Google-Systeme?
Nein. Sie meldeten Zugriff auf eingeschränkte Google-eigene Artifact Registry-Repositories und Bereitstellungsdateien von Mandantenprojekten, sagten aber auch, dass ihnen die Berechtigung für den Zugriff auf mindestens einen eingeschränkten internen Speicher-Bucket fehlte, den sie identifiziert hatten.
Was ist die empfohlene Lösung?
Die aktuellen Leitlinien von Google deuten auf strengere Identitätskontrollen hin, insbesondere auf die Agentenidentität und eng begrenzte Dienstkonten, statt auf umfassende Standardberechtigungen.