Google warnt vor Vertex-AI-Berechtigungsrisiken: Wenn KI-Workflows zum neuen Privilege-Escalation-Vektor werden

Generative-AI-Plattformen werden in vielen Unternehmen zum Standard-Baustein für Data-Science-, Analytics- und Business-Workflows. Ein aktueller Sicherheitsbericht zu Google Vertex AI macht nun deutlich: Das Risiko beschränkt sich nicht mehr nur auf Trainingsdaten und Modelle. Fehlkonfigurierte oder zu weit gefasste Berechtigungen in Vertex AI können selbst internen Angreifern mit geringen Rechten ermöglichen, über KI-Workflows Cloud-Privilegien zu eskalieren und an hochsensible Ressourcen zu gelangen.

Für CISOs, Cloud-Architekten und MLOps-Verantwortliche bedeutet das: Vertex AI und ähnliche KI-Plattformen müssen als eigenständige Privilege-Escalation-Vektoren im Cloud-Bedrohungsmodell berücksichtigt werden – mit unmittelbarem Handlungsbedarf in IAM, Governance und Pipeline-Design.

Kontext: Was genau ist passiert – und wer ist betroffen?

Ausgangspunkt: Analyse der Vertex-AI-Berechtigungsarchitektur

Ein heute bekannt gewordener Sicherheitsbericht eines spezialisierten Cloud-Security-Anbieters beleuchtet systematische Schwächen in der Rollen- und Berechtigungsarchitektur von Google Vertex AI. Im Fokus stehen dabei:

• Service Agents von Vertex AI – von Google verwaltete Servicekonten, die im Hintergrund Aktionen im Namen des Kunden ausführen.

• Standardrollen wie `roles/aiplatform.user` oder Viewer-nahe Rollen, die in vielen Projekten breit vergeben werden.

• Automatisierte KI-Workflows, die Service Agents in MLOps-Pipelines, Trainingsjobs oder Inferenz-Workloads einbinden.

Laut Bericht können Angreifer mit sehr geringen Rechten – teils auf dem Niveau eines Vertex-AI-Viewers – in bestimmten Konstellationen Tokens dieser hochprivilegierten Service Agents abgreifen oder deren Aktionen manipulieren. Damit wird aus einer vermeintlich harmlosen Rolle ein Einstiegspunkt zur projektweiten oder sogar organisationsweiten Rechteausweitung.

Googles Einordnung und „Working as Intended“-Dilemma

Brisant ist, dass es sich nicht um eine klassische Sicherheitslücke im Sinne einer CVE-registrierten Schwachstelle handelt, sondern um Design-Entscheidungen in der Cloud-Architektur:

• Die betroffenen Service Agents werden mit sehr weitreichenden Rechten ausgestattet, damit Vertex AI in unterschiedlichen Projektszenarien „out of the box“ funktioniert.

• Google betrachtet diese Rechtevergabe und das Zusammenspiel von Rollen und Service Agents derzeit als funktionsgemäß.

Aus Sicht von Unternehmen bedeutet das: Das Risiko wird nicht automatisch durch ein Security-Patch verschwinden. Es handelt sich um ein Governance- und Architekturproblem, das Kunden selbst durch präzises IAM-Design und zusätzliche Kontrollen entschärfen müssen.

Wer konkret betroffen ist

Betroffen sind im Grunde alle Organisationen, die Vertex AI produktiv oder in größerem Umfang verwenden, insbesondere wenn folgende Bedingungen zutreffen:

• Verwendung der Standard-Vertex-AI-Rollen ohne Anpassung nach dem Least-Privilege-Prinzip.

• Zentrale oder geteilte GCP-Projekte, in denen Vertex AI zusammen mit Storage, BigQuery, Pub/Sub, GKE oder anderen produktiven Workloads betrieben wird.

• Starke Abhängigkeit von MLOps-Pipelines, in denen Service Agents automatisiert Modelle trainieren, deployen, evaluieren oder Batch-Scorings durchführen.

Unternehmen mit strengen Compliance-Vorgaben (Finanzwesen, Gesundheit, kritische Infrastrukturen) und solche mit stark verteilten Entwickler- oder Data-Science-Teams sind besonders exponiert.

Wie Vertex-AI-Berechtigungen zum Privilege-Escalation-Vektor werden

Rolle von Service Agents als „unsichtbare Identitäten“

Service Agents sind spezielle Servicekonten, die von Google verwaltet und vom Kunden selten aktiv wahrgenommen werden. Sie besitzen oft:

• Projektweite Lese- und Schreibrechte auf Storage-Buckets, Datenbanken, Ressourcen-Manager-APIs.

• Berechtigungen zur Rollenvergabe oder Schlüsselverwaltung, etwa über IAM- oder KMS-APIs.

Problematisch ist die Kombination aus:

1. Hohem Privilegniveau dieser Service Agents.

2. Geringer Transparenz: Sie tauchen selten in gängigen IAM-Reviews auf.

3. Automatisierter Nutzung in Pipelines und Workflows, die Data Scientists oder ML-Engineers gestalten.

Wenn ein interner Angreifer oder kompromittierter Account diese Identitäten kontrollieren oder impersonieren kann, steht ihm faktisch ein „Superkonto im Maschinenkleid“ zur Verfügung.

Typische Eskalationskette in Vertex-AI-Szenarien

Vereinfacht lässt sich die in den Berichten beschriebene Eskalationslogik wie folgt nachzeichnen:

1. Initialer Zugriff mit Minimalrechten

Ein Mitarbeiter oder kompromittiertes Konto verfügt lediglich über eine Viewer-nahe Rolle für Vertex AI oder ein eng begrenztes Custom Role.

1. Interaktion mit einem KI-Workflow

Über die Vertex-AI-Konsole oder APIs kann die Person einen Job einsehen, modifizieren oder einen neuen Job anlegen, der unter Verwendung des Vertex-AI-Service-Agents läuft.

1. Abgreifen oder Ausnutzen des Service-Agent-Kontextes

Durch gezieltes Konfigurieren des Jobs oder Einbringen von bösartigem Code im Trainings- oder Inferenzcontainer wird der Zugriffskontext des Service Agents sichtbar oder nutzbar (z. B. über Metadaten-Server, Service-Account-Tokens, Signer-APIs).

1. Nutzung der eskalierten Rechte

Mit dem erlangten Token oder den Rechten des Service Agents lassen sich nun:

- zusätzliche IAM-Rollen vergeben,

- Daten aus produktiven Buckets oder BigQuery-Datasets exfiltrieren,

- Konfigurationen von anderen Services verändern,

- Backdoors in Infrastruktur-Komponenten platzieren.

Damit wird Vertex AI vom Analysewerkzeug zum Sprungbrett für laterale Bewegungen und Rechteausweitung in der gesamten GCP-Umgebung.

Warum klassische Kontrollen oft versagen

Viele Organisationen verlassen sich beim Schutz von Cloud-Ressourcen auf etablierte Kontrollen:

• Rollen-Reviews fokussieren auf menschliche Identitäten (User, Gruppen), weniger auf Service Agents.

• Netzwerksegmentierung schützt zwar Zugriffe von außen, hilft aber wenig gegen Angreifer, die bereits innerhalb der Cloud-Identitätsgrenzen agieren.

• Datenklassifizierung konzentriert sich auf Speicherorte sensibler Daten, nicht auf die Workflows, die mit diesen Daten arbeiten.

Vertex AI liegt damit häufig im „blinden Fleck“ der Sicherheitsarchitektur: formal kein hochkritisches System, aber praktisch mit weitreichenden Hintertüren in zentrale Daten- und Infrastrukturressourcen ausgestattet.

Praktische Beispiele und Szenarien aus der Unternehmenspraxis

Beispiel 1: Data-Science-Sandbox als Einfallstor in die Produktion

Ein Konzern betreibt einen zentralen GCP-Mandanten mit mehreren Projekten. Ein Projekt „DS-Sandbox“ bündelt:

• Vertex AI für Experimentation,

• mehrere Storage-Buckets mit Anonymisierungsdaten,

• Verknüpfungen zu produktiven BigQuery-Datasets über freigegebene Views.

Eine Junior-Data-Scientistin erhält eine Standardrolle für Vertex AI, um an Experimenten mit Text- und Bildmodellen zu arbeiten. Über Anpassungen an einer Trainings-Pipeline gelingt es ihr – absichtlich oder durch Kompromittierung ihres Kontos –, den Token des Vertex-AI-Service-Agents auszulesen.

Da dieser Service Agent aus Convenience-Gründen über breite Projekt- und teilweise organisationsweite Rechte verfügt, können nun:

• Berechtigungen auf produktive BigQuery-Datasets erweitert,

• Modell-Artefakte in produktive Deployments eingeschleust,

• sensible Daten aus anderen Projekten gelesen und exfiltriert werden.

Die gesamte Operation findet innerhalb der GCP-Infrastruktur statt – klassische Perimeter-Security und Firewalls schlagen nicht an.

Beispiel 2: Insider nutzt Modell-Deployment für verdeckte Exfiltration

In einem anderen Unternehmen wird Vertex AI genutzt, um Modelle für Betrugserkennung zu betreiben. Ein ML-Engineer mit Zugriff auf das Deployment kann:

• ein scheinbar harmloses Modell-Update ausrollen,

• im Container-Code Funktionen verstecken, die Daten aus angebundenen Storage-Buckets periodisch auslesen,

• diese Daten verschlüsselt über reguläre Inferenz-Requests („Prediction API“) ausleiten.

Wenn das Deployment unter einem hochprivilegierten Service Agent läuft, ist der Umfang der exfiltrierten Daten kaum begrenzt. Logging und Monitoring fokussieren auf Latenz und Fehlerraten, nicht auf Datensicherheitsverletzungen – der Angriff bleibt lange unentdeckt.

Beispiel 3: Missbrauch von AutoML- oder Notebook-Umgebungen

Auch interaktive Vertex-AI-Arbeitsplätze (Workbenches, Notebooks) können als Hebel dienen. Ein Nutzer mit Viewer- oder Notebook-Rechten kann z. B.:

• ein Notebook so konfigurieren, dass es im Kontext eines Service Agents Aktionen auf anderen GCP-Ressourcen ausführt,

• über Metadaten-APIs Zugriffstokens abgreifen,

• dann außerhalb des ursprünglichen Notebook-Kontexts API-Aufrufe mit diesen Rechten tätigen.

Gerade in Data-Science-Teams, in denen flexible Notebook-Umgebungen als Standard gelten, können solche Szenarien unbemerkt bleiben.

Implikationen für Unternehmen: Risiko, Compliance, Governance

Vom Datenrisiko zum Infrastruktur-Risiko

Bislang lagen die Schwerpunkte vieler KI-Risikobewertungen auf:

• Datenabflüssen (Trainingsdaten, PII, Geschäftsgeheimnisse),

• Modellrisiken (Bias, Halluzinationen, Fehlentscheidungen),

• Lieferkettenrisiken (Third-Party-Modelle, Open-Source-Modelle).

Die vorgestellten Erkenntnisse verschieben den Fokus: Vertex AI ist nicht mehr nur ein Daten- und Modellrisikosystem, sondern ein Infrastruktur-kritischer Dienst, über den Angreifer ihre Rechte eskalieren und die Kontrolle über Cloud-Ressourcen ausweiten können.

Compliance- und Audit-Perspektive

Für regulierte Branchen hat das direkte Folgen:

• Berücksichtigung von KI-Plattformen in Zugriffskontroll-Reviews: Revisionsberichte müssen Vertex-AI-Rollen, Service Agents und deren effektive Rechte explizit abdecken.

• Nachweis von Least-Privilege-Prinzipien: Prüfer werden zunehmend fordern, dass KI-Workloads nicht pauschal mit projektweiten Owner-ähnlichen Rechten laufen.

• Erweiterte Protokollierung und Forensik: Logs von Vertex AI, IAM, Cloud Audit Logs und Data Access Logs müssen verknüpft ausgewertet werden, um Missbrauch von Service Agents nachvollziehen zu können.

Unternehmen, die hier keine belastbaren Nachweise liefern können, riskieren Beanstandungen, Bußgelder und im Ernstfall einen Reputationsschaden nach Vorfällen.

Was Unternehmen jetzt konkret tun sollten

1. Sofortige Bestandsaufnahme der Vertex-AI-Berechtigungen

Kurzfristig sollten Security- und Cloud-Teams eine zielgerichtete Inventur durchführen:

• Welche Service Agents sind in der Organisation für Vertex AI aktiv?

• Welche Rollen und Berechtigungen besitzen diese Service Agents auf Projekt-, Folder- und Organisationsebene?

• Welche menschlichen Identitäten verfügen über Rollen, die den Zugriff auf Vertex AI-Workflows, -Jobs, -Notebooks oder -Deployments erlauben?

Aus diesen Informationen lässt sich eine erste Risikomatrix erstellen: Welche Kombinationen aus menschlichen Rollen und Service-Agent-Rechten eröffnen potenzielle Eskalationspfade?

2. Einführung strikter Least-Privilege-Rollen für Vertex AI

Wo immer möglich, sollten Standardrollen durch maßgeschneiderte Custom Roles ersetzt werden, die nur die minimal notwendigen Aktionen erlauben:

• Trennung von Lese-, Ausführungs- und Administrationsrechten für Vertex AI.

• Separate Rollen für Experimentation, Produktionsbetrieb und Plattformadministration.

• Verbot der Verwendung von Vertex-AI- oder generischen Service Agents mit projektweiten Owner- oder Editor-Rechten.

Wichtig ist, dass diese Rollen in Code gegossen werden (z. B. über Terraform, Deployment Manager, Blueprints), um eine konsistente und prüfbare Implementierung sicherzustellen.

3. Härtung und Überwachung von Service Agents

Service Agents müssen aus der „unsichtbaren“ Ebene in den regulären Sicherheitsprozess überführt werden:

• Explizite Aufnahme in IAM-Reviews (Quarterly Access Review, SoD-Checks).

• Einführung von Tagging- oder Naming-Konventionen, um hochprivilegierte Service Agents sofort identifizieren zu können.

• Einsatz von Anomalieerkennung und SIEM-Korrelation, um ungewöhnliche Aktivitäten von Service Agents (z. B. Zugriff auf neue Projekte, massives Lesen von sensiblen Buckets) zu erkennen.

Wo möglich sollten Service Agents in ihren Rechten stark eingegrenzt werden, etwa durch:

• Ressourcenspezifische Rollen (statt projektweiter Berechtigungen),

• Einschränkungen auf bestimmte Service-Accounts oder Workloads,

• Nutzung separater Projekte für hochkritische Daten.

4. Segmentierung von KI-Workloads und produktiven Ressourcen

Eine weitere wirkungsvolle Maßnahme ist die architektonische Trennung:

• Vertex-AI-Experimente und Entwicklung in eigenen Projekten ohne direkten Zugriff auf produktive Daten oder Ressourcen.

• Produktions-Deployments von Modellen ebenfalls in dedizierten Projekten, mit eng begrenzten Datenpfaden.

• Nutzung von Shared VPCs und klar definierten Schnittstellen (APIs, Pub/Sub, Dataproc), statt breiter Querschnittsberechtigungen.

Damit wird der potenzielle Schaden einer kompromittierten Identität oder Pipeline deutlich begrenzt.

5. Anpassung von MLOps-Pipelines und Governance-Prozessen

CI/CD- und MLOps-Pipelines müssen um Sicherheits-Gates ergänzt werden:

• Prüfschritte, die sicherstellen, dass Deployments nur unter harten, vordefinierten Servicekonten mit begrenzten Rechten laufen.

• Scans von Container-Images und Pipeline-Skripten auf verdächtige Muster (z. B. Zugriff auf Metadaten-Server, unautorisierte IAM-API-Aufrufe).

• Vier-Augen-Prinzip oder Freigabeprozesse für Änderungen an produktiven Vertex-AI-Workflows.

Zudem sollten Richtlinien und Schulungen für Data-Science- und ML-Engineering-Teams etabliert werden, die den sicheren Umgang mit Servicekonten, Tokens und IAM in KI-Workloads adressieren.

Fazit: KI-Plattformen gehören ins Kern-Bedrohungsmodell der Cloud-Sicherheit

Die aktuelle Diskussion um Vertex-AI-Berechtigungen markiert einen Wendepunkt: KI-Plattformen sind nicht mehr Randthema in der Sicherheitsarchitektur, sondern kritische Infrastrukturen, deren Berechtigungsdesign maßgeblich über das Gesamtrisiko der Cloud entscheidet.

Unternehmen, die Vertex AI oder ähnliche Dienste einsetzen, sollten die Gelegenheit nutzen, ihr IAM- und Governance-Modell grundlegend zu überprüfen und AI-Workloads als vollwertige Erstbürger in ihrem Threat Modeling zu behandeln.

Wichtigste Takeaways für Entscheider

• KI-Workflows sind neue Privilege-Escalation-Vektoren: Fehlkonfigurierte Vertex-AI-Berechtigungen erlauben interne Angreifern, über Service Agents Cloud-Rechte zu eskalieren.

• Keine klassische „Bug-Fix“-Lücke: Es handelt sich primär um ein Design- und Governance-Problem, das Unternehmen selbst über IAM, Architektur und Prozesse adressieren müssen.

• Service Agents sind Hochrisiko-Identitäten: Sie besitzen oft weitreichende Rechte und werden in vielen Access-Reviews übersehen – hier besteht akuter Handlungsbedarf.

• Segmentierung reduziert Schaden: Trennung von Experiment-, Produktions- und Datenprojekten begrenzt die Auswirkung kompromittierter KI-Workloads.

• MLOps muss sicherheitsreif werden: Pipelines und Workflows benötigen Security-Gates, Code-Reviews und strenge Vorgaben für Servicekonten.

• Früher Einstieg reduziert Kosten: Jetzt in Berechtigungsdesign und Governance zu investieren ist günstiger als spätere Incident-Response, Bußgelder und Reputationsschäden nach einem Breach.

Häufig gestellte Fragen (FAQ)

Was ist das besondere Risiko bei den Berechtigungen von Google Vertex AI?

Das besondere Risiko liegt darin, dass scheinbar niedrig privilegierte Vertex-AI-Rollen über KI-Workflows Zugriff auf hochprivilegierte Service Agents erhalten können. Dadurch werden KI-Pipelines zu neuen Privilege-Escalation-Vektoren, über die Angreifer Projekt- oder sogar organisationsweite Cloud-Rechte ausweiten können.

Wie funktioniert die Rechteeskalation über Vertex-AI-Workflows in der Praxis?

Ein Angreifer mit minimalen Vertex-AI-Rechten kann Jobs oder Pipelines so manipulieren, dass Code im Kontext eines mächtigen Service Agents ausgeführt wird. Über Metadaten-APIs oder Service-Account-Tokens lassen sich dann dessen Rechte übernehmen und für weitergehende Aktionen wie IAM-Änderungen oder Datenexfiltration nutzen.

Warum handelt es sich bei den beschriebenen Problemen nicht um eine klassische Sicherheitslücke?

Die Risiken resultieren aus bewussten Design-Entscheidungen in der Cloud-Architektur und nicht aus einem einzelnen technischen Bug. Google betrachtet die weitreichenden Rechte der Service Agents aktuell als funktionsgemäß, weshalb Unternehmen das Problem über Governance, IAM-Design und Prozessanpassungen selbst adressieren müssen.

Welche Auswirkungen haben unsichere Vertex-AI-Berechtigungen auf Compliance und Audits?

Unsichere Vertex-AI-Berechtigungen können dazu führen, dass Zugriffskontroll-Reviews und Audit-Anforderungen nicht erfüllt werden, weil Service Agents und KI-Workloads als kritische Identitäten übersehen werden. In regulierten Branchen drohen dadurch Beanstandungen, Bußgelder und Reputationsschäden nach Sicherheitsvorfällen.

Was ist der Unterschied zwischen klassischen Datenrisiken und den neuen Infrastruktur-Risiken durch Vertex AI?

Klassische Datenrisiken konzentrieren sich auf den Schutz von Trainingsdaten, Modellen und deren Qualität oder Bias. Die neuen Infrastruktur-Risiken bedeuten hingegen, dass Vertex AI selbst als Angriffsvektor genutzt werden kann, um Kontrolle über Cloud-Ressourcen, IAM-Rollen und produktive Systeme zu gewinnen.

Was sollten Unternehmen jetzt konkret tun, um ihre Vertex-AI-Umgebungen abzusichern?

Unternehmen sollten kurzfristig eine Inventur aller Vertex-AI-Service-Agents und Rollen durchführen, Standardrollen durch Least-Privilege-Custom-Rollen ersetzen und Service Agents explizit in IAM-Reviews aufnehmen. Zusätzlich sollten KI-Workloads architektonisch von produktiven Ressourcen segmentiert und MLOps-Pipelines um Sicherheits-Gates, Code-Reviews und Freigabeprozesse ergänzt werden.

Wie lässt sich das Risiko durch Service Agents in Vertex AI gezielt reduzieren?

Das Risiko lässt sich senken, indem Service Agents nur noch ressourcenspezifische und minimal notwendige Rechte erhalten und klar gekennzeichnet werden. Ergänzend helfen Monitoring und Anomalieerkennung für Service-Agent-Aktivitäten sowie eine strikte Trennung von Experiment-, Produktions- und Datenprojekten, um den potenziellen Schaden im Angriffsfall zu begrenzen.