Eine von Palo Alto Networks Unit 42 publizierte Analyse legt ein kritisches Sicherheitsrisiko in Google Cloud Vertex AI offen: Autonome AI‑Agenten erhalten in der Standardkonfiguration überprivilegierte Service Accounts, die Angreifern weitreichenden Zugriff auf Kundendaten und interne Infrastruktur verschaffen können.
Wie Vertex AI Agenten und P4SA-Service-Accounts zusammenarbeiten
Vertex AI bietet Unternehmen eine Plattform, um AI‑Agenten zu entwickeln, die eigenständig Entscheidungen treffen und mit Cloud-Ressourcen interagieren. Für diese Interaktionen legt Google spezielle Dienstkonten an, sogenannte P4SA (Per‑Project, Per‑Product Service Agent). Über diese Accounts führen die Agenten alle Aktionen in Google Cloud aus.
Nach Erkenntnissen von Unit 42 erhalten diese P4SA-Accounts, die beim Deployment eines AI‑Agenten mit dem Vertex AI Agent Development Kit (ADK) und dem Agent Engine automatisch erstellt werden, standardmäßig zu weitreichende Berechtigungen. Jeder Agentenaufruf kontaktiert dabei den Metadatenservice von Google Cloud, über den Zugangstoken, Projektinformationen, die Identität des Dienstkontos und zugeordnete OAuth‑Scopes ausgelesen werden können.
Gelingt es einem Angreifer, einen AI‑Agenten zu kompromittieren – etwa über fehlerhafte Prompt-Validierung, Schwachstellen in der Anwendungslogik oder Fehlkonfigurationen –, kann sich der Agent in einen „doppelten Agenten“ verwandeln: Nach außen erfüllt er weiterhin seine Aufgaben, im Hintergrund jedoch werden Tokens exfiltriert, Kommandos im Namen des Service Accounts ausgeführt und persistente Zugriffe im Cloud‑Projekt aufgebaut.
Ausweitung des Angriffs von Vertex AI auf das gesamte Google‑Cloud‑Projekt
Anhand der erlangten P4SA-Credentials zeigten die Forscher, dass sich der Sicherheitskontext des AI‑Agenten verlassen und direkt im Kundenprojekt der Google Cloud agieren lässt. Damit wird die von vielen Unternehmen angenommene strikte Isolation zwischen dem Managed Service Vertex AI und den eigenen Ressourcen faktisch aufgehoben.
Mit den gestohlenen Tokens konnten die Experten alle Objekte in Google Cloud Storage (GCS)‑Buckets des betroffenen Projekts lesen. In der Praxis liegen hier häufig Datenbanksicherungen, Machine‑Learning‑Modelle, sensible Exporte und weitere geschützte Artefakte. Ein kompromittierter AI‑Agent entspricht somit einem Insider mit umfassenden Read‑only‑Rechten auf große Teile des Datenbestands.
Sicht auf Google‑verwalteten Tenant und interne Infrastruktur
Vertex AI Agent Engine selbst läuft in einem separaten, von Google verwalteten Tenant‑Projekt. Unit 42 konnte die gleichen P4SA‑Credentials nutzen, um auf dortige Google Cloud Storage‑Ressourcen zuzugreifen und Metadaten zur internen Plattformarchitektur einzusehen. Auch wenn kein Vollzugriff auf Inhalte möglich war, vergrößert bereits diese Sichtbarkeit die Angriffsoberfläche und liefert wertvolle Informationen für weiterführende Attacken.
Artifact Registry und Supply‑Chain‑Risiken für Vertex AI
Zugriff auf private Container-Images des Vertex AI Reasoning Engine
Besonders sicherheitsrelevant ist der von Unit 42 beschriebene Zugriff auf die Google Artifact Registry. Mit den P4SA-Berechtigungen konnten die Forscher auf interne, nicht öffentlich bestimmte Container-Images des Vertex AI Reasoning Engine zugreifen und diese herunterladen.
Ein solcher Zugriff eröffnet Einblick in proprietären Code, Konfigurationen und Abhängigkeiten. Angreifer erhalten damit detaillierte Informationen zur internen Architektur, können gezielt nach nicht gepatchten Komponenten, Konfigurationsschwächen oder möglichen Eskalationspfaden suchen und perspektivisch weitere Schwachstellen entwickeln.
Gefahr für die Software-Supply-Chain in der Cloud
Die fehlerhafte Rechtevergabe in Artifact Registry zeigt exemplarisch, wie Schwachstellen im Access Management ganze Software‑Lieferketten (Software Supply Chain) gefährden können. Bereits die reine Sicht auf Versionsstände und Image‑Tags erlaubt es, potenziell verwundbare oder veraltete Container zu identifizieren und Angriffe zu planen – sowohl gegen die Plattform selbst als auch gegen Kunden, die die gleichen Komponenten einsetzen.
Reaktion von Google und empfohlene Schutzmassnahmen für Vertex AI
Google hat in Reaktion auf die Forschungsergebnisse die offizielle Dokumentation zu Vertex AI überarbeitet und transparenter beschrieben, wie Ressourcen, Service Accounts und Agenten verwendet werden. Zentraler Ratschlag an Kunden ist der Einsatz eigener Dienstkonten nach dem Bring Your Own Service Account (BYOSA)-Prinzip und eine konsequente Umsetzung des Principle of Least Privilege (PoLP).
In der Praxis bedeutet das, dass AI‑Agenten nur die unbedingt notwendigen Rollen erhalten dürfen – keine weit gefassten Rollen wie Editor – und dass OAuth‑Scopes, berechtigte APIs und Rollen regelmäßig überprüft und eingeschränkt werden. Ein engmaschiges Monitoring der Nutzung von Service Accounts sowie detaillierte Audit‑Logs sind für die Angriffserkennung essenziell.
Unit 42 empfiehlt, die Einführung von AI‑Agenten sicherheitstechnisch wie den Rollout eines neuen Produkts oder Microservices zu behandeln. Dazu gehören:
– Validierung von Berechtigungsgrenzen und Projektisolation,
– Integritätsprüfung von Quellcode und Container‑Images,
– gezielte Sicherheitstests inklusive Versuchen, den Metadatenservice auszulesen,
– Einrichtung von Alarmierungen bei ungewöhnlicher Aktivität von Service Accounts.
Angesichts der Prognose etwa von Gartner, wonach bis 2025 über 99 % der Cloud‑Sicherheitsvorfälle auf Fehlkonfigurationen zurückgehen dürften, zeigt der Vertex‑AI‑Fall exemplarisch, wie wichtig stringentes Identitäts‑ und Rechtemanagement in KI‑Workloads ist. Organisationen, die Vertex AI oder ähnliche Plattformen nutzen, sollten BYOSA zwingend umsetzen, ihre IAM‑Richtlinien überarbeiten, zentrale Überwachung für Service Accounts etablieren und KI‑Agenten fest in bestehende DevSecOps‑ und Risikomanagement‑Prozesse integrieren, um zu verhindern, dass sie sich unbemerkt in „doppelte Agenten“ im eigenen Cloud‑Umfeld verwandeln.
