Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa opisali problem w platformie Vertex AI, który dotyczy sposobu nadawania i wykorzystywania uprawnień przez domyślne konta usługowe powiązane z agentami AI. Sednem zagrożenia jest możliwość nadużycia zbyt szerokich uprawnień przypisanych do mechanizmów uruchomieniowych, co w określonych warunkach może prowadzić do nieautoryzowanego dostępu do danych w środowisku Google Cloud oraz do ujawnienia wybranych wewnętrznych artefaktów platformy.
Sprawa pokazuje, iż bezpieczeństwo systemów AI nie kończy się na modelu, promptach i logice aplikacyjnej. najważniejsze znaczenie mają także tożsamość usługowa, kontrola dostępu, separacja zasobów oraz ograniczenie zasięgu uprawnień nadawanych agentom działającym w chmurze.
W skrócie
- Problem dotyczy agentów AI tworzonych w Vertex AI i uruchamianych przez Agent Engine.
- W analizowanym scenariuszu możliwe było pozyskanie poświadczeń domyślnego agenta usługowego.
- Uzyskane tokeny mogły zostać wykorzystane do działań w imieniu komponentu uruchomieniowego.
- Skutkiem mógł być odczyt danych z zasobów Google Cloud Storage w projekcie klienta.
- Dodatkowym ryzykiem była ekspozycja informacji o prywatnych artefaktach i repozytoriach dostawcy.
- Producent zalecił stosowanie własnych kont usługowych i ścisłe ograniczanie uprawnień zgodnie z zasadą najmniejszych przywilejów.
Kontekst / historia
Rosnące wykorzystanie agentów AI w środowiskach produkcyjnych powoduje, iż dobrze znane problemy bezpieczeństwa chmury zyskują nowy wymiar. Błędne modele uprawnień, nadmierny zakres ról, niewłaściwa izolacja między komponentami czy zbyt szeroki dostęp do metadanych mogą mieć znacznie większe konsekwencje, gdy dotyczą systemów zintegrowanych z danymi biznesowymi, pamięcią kontekstową i narzędziami automatyzacji.
W tym przypadku problem nie wynikał z klasycznego zdalnego wykonania kodu, ale z połączenia kilku elementów: domyślnego modelu uprawnień, sposobu wdrożenia agenta oraz ekspozycji poświadczeń w kontekście wykonawczym. Taki łańcuch zależności dobrze ilustruje, iż ocena bezpieczeństwa agentów AI musi obejmować nie tylko samą aplikację, ale również warstwę IAM, workload identity, metadane i dostęp do usług chmurowych.
Analiza techniczna
Z technicznego punktu widzenia problem dotyczył konta typu Per-Project, Per-Product Service Agent, czyli domyślnego agenta usługowego przypisanego do konkretnego produktu w ramach projektu. Według opisanego scenariusza po wdrożeniu agenta AI z użyciem Agent Development Kit i uruchomieniu go przez Agent Engine możliwe było doprowadzenie do kontaktu z usługą metadanych środowiska wykonawczego.
W praktyce pozwalało to na uzyskanie poświadczeń agenta usługowego oraz informacji o projekcie hostującym, tożsamości agenta i zakresach uprawnień przypisanych środowisku uruchomieniowemu. Po przejęciu takich poświadczeń badacze mogli wykonywać operacje w projekcie klienta z uprawnieniami przypisanymi temu komponentowi.
Najpoważniejszą konsekwencją był szeroki dostęp odczytowy do danych przechowywanych w Google Cloud Storage. Oznacza to naruszenie oczekiwanej granicy izolacji pomiędzy logiką agenta a zasobami klienta. W praktyce agent AI, który powinien realizować ściśle określone zadania, mógł zostać wykorzystany jako punkt wejścia do eksploracji zasobów lub eksfiltracji danych.
Badacze zwrócili również uwagę na drugi aspekt problemu związany z uruchamianiem Agent Engine w projekcie dzierżawionym i zarządzanym przez dostawcę. Pozyskane poświadczenia umożliwiały dostęp do informacji o zasobach przechowywania w takim środowisku, co dawało dodatkowy wgląd w wewnętrzną architekturę platformy. choćby jeżeli same uprawnienia nie zawsze pozwalały na pełny odczyt wszystkich zasobów, sama możliwość ich enumeracji może wspierać rekonesans i planowanie dalszych etapów ataku.
Kolejnym elementem była ekspozycja prywatnych repozytoriów Artifact Registry należących do dostawcy. W efekcie możliwe było pobieranie obrazów kontenerów związanych z silnikiem rozumowania Vertex AI oraz enumeracja innych ograniczonych artefaktów pojawiających się podczas procesu wdrożenia. Tego typu dostęp ma znaczenie zarówno dla ochrony własności intelektualnej, jak i dla bezpieczeństwa łańcucha dostaw, ponieważ może pomóc w analizie wewnętrznych komponentów, identyfikacji przestarzałych bibliotek lub kolejnych potencjalnych wektorów ataku.
Cały incydent dobrze obrazuje zjawisko uprzywilejowanego agenta. o ile komponent AI otrzymuje zbyt szeroki zestaw uprawnień, staje się pośrednikiem do zasobów o wysokiej wartości. Wtedy kompromitacja agenta, błędna konfiguracja narzędzia albo możliwość odczytu metadanych mogą wystarczyć do eskalacji wpływu incydentu daleko poza samą warstwę aplikacyjną.
Konsekwencje / ryzyko
Z perspektywy organizacji zagrożone mogą być dane przechowywane w obrębie projektu chmurowego, w tym pliki, dane treningowe, artefakty aplikacyjne, logi i informacje biznesowe. Ujawnienie poświadczeń kont usługowych może otworzyć drogę do trwałego utrzymania dostępu, tworzenia ścieżek bocznych oraz obchodzenia założeń segmentacji między usługami.
Ekspozycja prywatnych obrazów i repozytoriów ma znaczenie wykraczające poza pojedynczego klienta. Atakujący może dzięki temu lepiej zrozumieć wewnętrzną implementację platformy, a to może ułatwić wyszukiwanie kolejnych błędów, planowanie ataków na łańcuch dostaw lub przygotowanie skuteczniejszych technik unikania detekcji.
Dodatkowym problemem jest trudność wykrywania takich działań. o ile operacje są wykonywane z użyciem prawidłowych poświadczeń domyślnego agenta usługowego, aktywność może wyglądać jak legalny ruch systemowy. To zwiększa znaczenie analizy behawioralnej, monitorowania nietypowych odczytów z pamięci masowej oraz korelacji logów IAM, metadanych i działań workload identity.
Rekomendacje
Organizacje korzystające z Vertex AI powinny w pierwszej kolejności ograniczyć użycie domyślnych kont usługowych wszędzie tam, gdzie to możliwe, i zastąpić je dedykowanymi tożsamościami o minimalnym niezbędnym zakresie uprawnień. Każdy agent AI powinien mieć własny profil dostępu, ograniczony do konkretnych zasobów, operacji i zakresów wymaganych przez jego funkcję.
- Przeprowadzić przegląd ról przypisanych agentom AI, zwłaszcza w obszarach Cloud Storage, Artifact Registry, sekretów, logów i usług pomocniczych.
- Zweryfikować, czy agent może odczytywać metadane środowiska wykonawczego oraz czy istnieją mechanizmy blokujące nieautoryzowane pobieranie tokenów.
- Traktować wdrożenie agenta AI tak samo rygorystycznie jak wdrożenie nowego kodu produkcyjnego.
- Uwzględnić modelowanie zagrożeń, testy bezpieczeństwa, walidację granic uprawnień i przegląd integracji z narzędziami zewnętrznymi.
- Skonfigurować alerty na nietypowe odczyty z bucketów, nieoczekiwane użycie kont usługowych oraz dostęp do repozytoriów artefaktów poza standardowym pipeline’em.
- W środowiskach o podwyższonych wymaganiach rozważyć segmentację projektów i separację danych wykorzystywanych przez agentów od danych krytycznych.
Podsumowanie
Opisana luka pokazuje, iż bezpieczeństwo platform AI w dużej mierze zależy od poprawnego modelu tożsamości i uprawnień. choćby bez klasycznej podatności pamięciowej czy błędu aplikacyjnego nadmiernie uprzywilejowany agent może stać się skutecznym narzędziem do eksfiltracji danych, rekonesansu i naruszania izolacji między zasobami.
Najważniejszy wniosek dla organizacji jest praktyczny: agenty AI nie mogą być traktowane jako wyjątek od zasad bezpieczeństwa chmury. Muszą podlegać tej samej dyscyplinie co kontenery, funkcje serverless i konta usługowe w środowisku produkcyjnym. Zasada najmniejszych uprawnień, własne konta usługowe, monitoring aktywności oraz kontrola dostępu do metadanych pozostają fundamentem bezpiecznego wdrażania AI w Google Cloud.
Źródła
- Vertex AI Vulnerability Exposes Google Cloud Data and Private Artifacts — https://thehackernews.com/2026/03/vertex-ai-vulnerability-exposes-google.html
- Service agents — Google Cloud Documentation — https://docs.cloud.google.com/iam/docs/service-agents
- Vertex AI service agents — Google Cloud Documentation — https://docs.cloud.google.com/vertex-ai/docs/general/access-control#service-agents
- Agent Development Kit documentation — Google Cloud Documentation — https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-development-kit/overview
- Artifact Registry documentation — Google Cloud Documentation — https://cloud.google.com/artifact-registry/docs/overview