Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Bezpieczeństwo agentów AI staje się jednym z najważniejszych zagadnień w nowoczesnych środowiskach chmurowych. Najnowsza analiza dotycząca Vertex AI pokazuje, że agent wdrożony w infrastrukturze Google Cloud może zostać wykorzystany nie tylko do realizacji zadań biznesowych, ale również jako narzędzie do eskalacji uprawnień, eksfiltracji danych i dalszej kompromitacji zasobów.
W opisywanym przypadku badacze wykazali scenariusz, w którym pozornie legalny agent działa jak „podwójny agent” — wykonuje przypisane zadania, a jednocześnie wykorzystuje nadmierne uprawnienia i mechanizmy tożsamości platformy do rozszerzenia dostępu poza własny kontekst wykonania.
W skrócie
Badacze bezpieczeństwa przeanalizowali działanie Vertex AI Agent Engine oraz Agent Development Kit i wskazali, że domyślne uprawnienia przypisane do zarządzanego konta serwisowego mogły być zbyt szerokie. W praktyce pozwalało to na pozyskanie poświadczeń, dostęp do danych projektu klienta oraz wykorzystanie uprawnień do odczytu wybranych zasobów w Google Cloud.
Demonstracja objęła również możliwość dostępu do prywatnych repozytoriów artefaktów i obrazów kontenerów powiązanych z zapleczem usługi. Po ujawnieniu problemu Google zaktualizował dokumentację i mocniej zaakcentował stosowanie własnych kont serwisowych oraz zasadę najmniejszych uprawnień.
- Problem dotyczył modelu tożsamości i uprawnień agentów AI.
- Scenariusz ataku umożliwiał wyjście poza kontekst pojedynczego agenta.
- Ryzyko obejmowało dostęp do danych, artefaktów i potencjalne utrzymanie trwałej obecności.
- Google wskazał stosowanie Bring Your Own Service Account jako ważny mechanizm ograniczający ekspozycję.
Kontekst / historia
Vertex AI Agent Engine i ADK powstały po to, aby uprościć tworzenie, wdrażanie i skalowanie agentów AI w chmurze Google. Wraz z rozwojem autonomicznych agentów rośnie jednak znaczenie ich tożsamości, relacji z usługami chmurowymi i sposobu nadawania dostępu do danych oraz narzędzi.
W przeciwieństwie do prostych aplikacji agent AI często działa na styku wielu usług: magazynów danych, pamięci, repozytoriów, workflow i zewnętrznych integracji. To sprawia, że błędy w konfiguracji IAM lub nadmiarowe role mogą prowadzić do znacznie szerszych skutków niż w przypadku klasycznego komponentu aplikacyjnego.
Opublikowane badanie zwraca uwagę, że bezpieczeństwo AI nie kończy się na zagrożeniach takich jak prompt injection czy błędne odpowiedzi modelu. Równie istotne są klasyczne obszary cloud security, czyli zarządzanie sekretami, separacja uprawnień, bezpieczeństwo kont serwisowych oraz kontrola dostępu do artefaktów i zasobów wykonawczych.
Analiza techniczna
Kluczowym elementem demonstracji było konto P4SA, czyli zarządzany przez Google agent serwisowy przypisany do wdrożonego agenta AI. Według badaczy domyślny zestaw uprawnień tego podmiotu mógł umożliwiać pozyskanie poświadczeń innego agenta serwisowego, a tym samym działanie w szerszym kontekście projektu Google Cloud.
Atak opierał się na wdrożeniu kontrolowanego, złośliwego agenta przy użyciu standardowego przepływu ADK. Po uruchomieniu agent wykonywał żądania do usług metadanych środowiska, co pozwalało zebrać informacje o tożsamości, tokenach i zakresie dostępu dostępnych podczas wykonania. Następnie możliwy był pivot do zasobów klienta, w tym odczyt danych przechowywanych w Google Cloud Storage.
Badacze opisali również scenariusz dostępu do prywatnych repozytoriów Artifact Registry powiązanych z zapleczem Vertex AI. Taki dostęp może mieć znaczenie nie tylko dla pojedynczej kompromitacji, ale również dla dalszego rozpoznania architektury usługi, analizy obrazów kontenerów oraz identyfikacji kolejnych słabych punktów w łańcuchu dostaw.
Dodatkowo wskazano możliwość manipulacji plikami w środowisku agenta w sposób, który potencjalnie mógł prowadzić do zdalnego wykonania kodu i utrwalenia backdoora. To pokazuje, że agent AI powinien być traktowany jak uprzywilejowany workload chmurowy, a nie wyłącznie warstwa logiki aplikacyjnej.
Po ujawnieniu ustaleń Google zaktualizował zalecenia bezpieczeństwa i wdrożeniowe. Producent podkreślił znaczenie uruchamiania agentów z użyciem własnych kont serwisowych zamiast domyślnych tożsamości platformowych, co pozwala lepiej ograniczać uprawnienia i zmniejszać powierzchnię ataku.
Konsekwencje / ryzyko
Z perspektywy organizacji wykorzystujących agentów AI zagrożenie ma charakter wielowarstwowy. Kompromitacja jednego agenta może prowadzić do nieautoryzowanego dostępu do danych w projekcie chmurowym, w tym do obiektów przechowywanych w bucketach, logów, artefaktów aplikacyjnych oraz innych zasobów operacyjnych.
Drugim wymiarem ryzyka jest wykorzystanie agenta jako punktu ruchu bocznego. Działania wykonywane z legalnego workloadu, korzystającego z poprawnych kont serwisowych, mogą być trudniejsze do wykrycia niż klasyczne próby włamania pochodzące spoza środowiska.
Nie bez znaczenia pozostaje również dostęp do prywatnych obrazów kontenerów i repozytoriów. Ujawnienie takich elementów może ułatwić analizę wewnętrznych zależności, mapowanie architektury zaplecza i przygotowanie precyzyjniejszych ataków przeciwko organizacji lub usługom, z których korzysta.
Najbardziej narażone są środowiska, w których agenci AI mają dostęp do:
- danych biznesowych i dokumentów wewnętrznych,
- repozytoriów kodu i pipeline’ów wdrożeniowych,
- baz wiedzy, magazynów obiektowych i systemów workflow,
- narzędzi administracyjnych oraz kont uprzywilejowanych.
Rekomendacje
Organizacje korzystające z Vertex AI powinny rozpocząć od przeglądu tożsamości wszystkich agentów działających w środowiskach testowych i produkcyjnych. Priorytetem jest odejście od szerokich uprawnień domyślnych wszędzie tam, gdzie możliwe jest zastosowanie własnych kont serwisowych z precyzyjnie ograniczonym zakresem dostępu.
Role IAM powinny być przypisywane wyłącznie do konkretnych operacji i zasobów potrzebnych danemu agentowi. Agent odpowiedzialny za analizę dokumentów lub obsługę zapytań nie powinien jednocześnie posiadać dostępu do pełnych bucketów projektowych, prywatnych repozytoriów obrazów ani uprawnień administracyjnych do innych usług.
Ważne jest również rozdzielenie środowisk deweloperskich, testowych i produkcyjnych, aby ewentualna kompromitacja jednego agenta nie umożliwiała prostego pivotu do zasobów krytycznych. W modelu operacyjnym warto traktować agentów AI tak samo jak inne wrażliwe komponenty cloud-native.
Z perspektywy monitoringu szczególną uwagę należy zwrócić na:
- odwołania agentów do usług metadanych,
- nietypowe użycie tokenów i kont serwisowych,
- masowy odczyt obiektów z Cloud Storage,
- dostęp do Artifact Registry poza oczekiwanym procesem CI/CD,
- anomalie w logach IAM oraz aktywności service accounts powiązanych z Vertex AI.
Uzupełnieniem powinny być kontrole bezpieczeństwa takie jak skanowanie zależności, walidacja pakietów wdrożeniowych, kontrola plików stagingowych, segmentacja sieci oraz regularne przeglądy efektywnych uprawnień. W środowiskach o podwyższonym ryzyku warto wdrożyć dodatkowe polityki organizacyjne i automatyczne alerty dla operacji wykonywanych przez konta serwisowe związane z agentami AI.
Podsumowanie
Przypadek Vertex AI pokazuje, że bezpieczeństwo agentów AI jest dziś przede wszystkim problemem infrastrukturalnym i tożsamościowym. Kluczowe znaczenie ma nie tylko to, jakie zadania wykonuje agent, ale także z jakimi uprawnieniami działa i do jakich zasobów może uzyskać dostęp po kompromitacji.
Demonstracja badaczy potwierdza, że nadmiarowe uprawnienia domyślnych kont serwisowych mogą zmienić agenta AI w skuteczny wektor ataku wewnętrznego. Dla zespołów bezpieczeństwa oznacza to konieczność stosowania zasady najmniejszych uprawnień, ścisłej kontroli IAM, monitorowania aktywności service accounts oraz regularnego audytu architektury wdrożeń AI.
Źródła
- SecurityWeek — Google Addresses Vertex Security Issues After Researchers Weaponize AI Agent — https://www.securityweek.com/google-addresses-vertex-security-issues-after-researchers-weaponize-ai-agent/
- Unit 42 — Double Agents: Exposing Security Blind Spots in GCP Vertex AI — https://unit42.paloaltonetworks.com/double-agents-vertex-ai/
- Google Cloud Documentation — Set up the environment | Generative AI on Vertex AI — https://cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/set-up
- Google Cloud Documentation — Managing access for deployed agents — https://cloud.google.com/agent-builder/agent-engine/manage/access
- Google Cloud Documentation — Use agent identity with Vertex AI Agent Engine — https://cloud.google.com/agent-builder/agent-engine/agent-identity