Nie model, tylko wykonawca. Co Vertex AI mówi o ryzyku agentów w chmurze

W dyskusji o bezpieczeństwie agentów AI zbyt łatwo skupiać się na prompt injection, jailbreakach i błędach modelu. Przypadek Vertex AI pokazuje coś bardziej praktycznego i zarazem bardziej niepokojącego. Prawdziwe ryzyko zaczyna się wtedy, gdy agent działa już nie jako interfejs tekstowy, ale jako element infrastruktury chmurowej z własnym kontekstem wykonania, tożsamością i uprawnieniami. Wtedy problem nie polega na tym, co model „odpowie”, ale na tym, co agent może zrobić, jeśli dostał za dużo. Palo Alto Networks Unit 42 opisało właśnie taki scenariusz w Vertex AI Agent Engine, a Google odpowiedziało zmianami w dokumentacji i zaleceniami dotyczącymi BYOSA oraz least privilege.  

To rozróżnienie jest kluczowe. LLM sam w sobie można traktować jako rdzeń poznawczy: mechanizm wnioskowania, planowania i generowania odpowiedzi. Agent to coś więcej. To ten sam rdzeń osadzony w roli, narzędziach, pamięci, tożsamości technicznej i dostępie do zasobów. Gdy taki agent trafia do środowiska chmurowego, pytanie przestaje brzmieć „czy model jest bezpieczny?”. Znacznie ważniejsze staje się: jaką rolę nadano agentowi i z jakim zakresem działania został wdrożony. Unit 42 pokazało, że w Vertex AI Agent Engine nadmiernie uprzywilejowany kontekst wykonania mógł umożliwić dostęp do danych w Google Cloud Storage, prywatnych artefaktów Google i poświadczeń, a więc zamienić użytecznego agenta w ciche narzędzie eksfiltracji i dalszej kompromitacji środowiska.  

Problem nie zaczął się w modelu

W tym case najważniejsze jest właśnie to, gdzie problem się nie zaczął. Nie chodziło o klasyczny jailbreak modelu. Nie chodziło o halucynację. Nie chodziło o sam prompt injection rozumiany jako sztuczka tekstowa. Chodziło o architekturę wdrożenia. Unit 42 opisało, że agenci Vertex AI mogli działać z wykorzystaniem nadmiernie szerokich domyślnych uprawnień przypisanych do Google-managed service account, określanego jako P4SA. To właśnie ten punkt pozwalał przesunąć problem z poziomu „AI safety” na poziom cloud security i IAM.  

To bardzo ważna lekcja, bo porządkuje debatę. Jeżeli skupiamy się wyłącznie na bezpieczeństwie modelu, łatwo przeoczyć to, że największy blast radius siedzi w warstwie wykonania. Dark Reading ujęło to wprost: Vertex AI miało problem over-privileged design. To nie była opowieść o „zepsutym modelu”, tylko o źle ustawionym zaufaniu wokół agenta.  

Agent staje się groźny po wdrożeniu

To chyba najprostsza i najmocniejsza teza, jaką da się z tego wyciągnąć: agent nie staje się groźny na etapie modelu. Staje się groźny na etapie wdrożenia.

Ten sam model może być nieszkodliwym asystentem w jednym środowisku i bardzo ryzykownym wykonawcą w innym. Różnica nie wynika z „natury” modelu, tylko z konfiguracji celu, narzędzi, uprawnień i zasięgu ruchu w infrastrukturze. W Vertex AI problemem był właśnie ten drugi poziom. Agent działał w środowisku, które dało mu więcej, niż powinno: zbyt szeroki dostęp do zasobów i zbyt dużą moc sprawczą w relacji do tego, czym formalnie miał się zajmować. Google po zgłoszeniu nie „naprawiało świadomości modelu”, tylko zaleciło własne service accounty, minimalizację uprawnień i bardziej restrykcyjny model wdrożenia.  

I to jest dokładnie ten moment, w którym agent przestaje być tylko „sprytnym wrapperem na LLM”. Staje się bytem infrastrukturalnym. A byt infrastrukturalny zabezpiecza się nie filtrem semantycznym, lecz:

• zasadą least privilege,
• izolacją,
• rozdziałem tożsamości,
• obserwowalnością,
• i ograniczaniem blast radius.

To dlatego ten przypadek tak dobrze wpisuje się w wcześniejszą linię o permission injection, warstwie wykonania i agentach jako realnych wykonawcach, a nie tylko interfejsach do modelu.  

„Double agent” to problem roli, nie osobowości

Metafora „double agent”, której użyło Unit 42, jest dobra pod jednym warunkiem: nie należy czytać jej psychologicznie. To nie opowieść o „nielojalnym AI”. To opowieść o wykonawcy osadzonym w złym modelu zaufania. Agent wygląda, jakby realizował zadanie zgodne z przeznaczeniem, ale dzięki nadmiernym uprawnieniom może jednocześnie robić rzeczy, których organizacja nie widzi albo których nie przewidziała.

To ważne, bo pomaga uniknąć błędnego języka. W tym case nie trzeba żadnej metafory świadomości ani „złej intencji” modelu, żeby opisać ryzyko. Wystarczy zrozumieć, że system wdrożył agenta jako wykonawcę z dostępem wykraczającym poza konieczny zakres. A gdy wykonawca ma za dużo, nawet poprawnie działający mechanizm staje się nośnikiem zagrożenia.  

To jest problem cloud security, nie tylko AI security

I właśnie dlatego Vertex AI jest tak ciekawym case’em. Z zewnątrz wygląda jak incydent „o AI”. W praktyce jest to bardzo klasyczny problem bezpieczeństwa infrastruktury:

• zbyt szerokie uprawnienia,
• słaba separacja kontekstu wykonania,
• możliwość nieautoryzowanego dostępu do danych i artefaktów,
• oraz ryzyko, że legalna warstwa wykonawcza zrobi więcej, niż powinna.

To przesuwa środek ciężkości z modelu na architekturę. Agent w chmurze nie jest po prostu bytem generującym odpowiedzi. Jest uczestnikiem systemu IAM, storage, artifact registry i service accountów. To znaczy, że bezpieczeństwo agentów cloudowych staje się po prostu bezpieczeństwem infrastruktury — tylko z nowym, bardziej autonomicznym wykonawcą w środku. SecurityWeek i The Hacker News opisały ten przypadek właśnie w ten sposób: jako możliwość „uzbrojenia” agentów przez nadużycie modelu uprawnień i dostępu do zasobów chmurowych.  

Co Vertex AI mówi o naturze agentów

Najlepszy wniosek z tego case’u nie brzmi: „AI jest niebezpieczne”. To zbyt ogólne i zbyt mało użyteczne. Lepszy brzmi:

Agent jest tak bezpieczny, jak bezpieczna jest rola, w którą go wdrożono.

To znaczy:

• model może być technicznie ten sam,
• ale agent stanie się bezpieczny albo groźny zależnie od tego,
• jakie ma uprawnienia,
• jaką ma tożsamość,
• do czego ma dostęp,
• i jak dobrze ograniczono jego środowisko wykonania.

To dobrze spina się z wcześniejszymi wątkami Cyberfluxa:

• prompt injection dotyczyło sterowania interpretacją,
• permission injection dotyczyło zakresu działania,
• secrets sprawl dotyczyło paliwa wykonania,
• agent identity dotyczyło rozpoznania wykonawcy,
• a Vertex AI pokazuje jeszcze jedną rzecz: agent staje się ryzykowny nie dlatego, że „myśli źle”, ale dlatego, że architektura daje mu zbyt dużą sprawczość po wdrożeniu.  

Co z tego wynika dla security

Najpraktyczniejszy wniosek jest prosty: agentów w chmurze nie wolno traktować jak inteligentniejszych wrapperów na model. Trzeba je traktować jak wykonawców infrastrukturalnych.

To oznacza pytania dużo bardziej konkretne niż zwykłe „czy model jest bezpieczny?”:

• czy agent ma własną, odseparowaną tożsamość,
• czy działa zgodnie z least privilege,
• czy jego dostęp do danych i artefaktów jest minimalny,
• czy blast radius da się ograniczyć,
• czy jego działania są obserwowalne,
• i czy organizacja potrafi rozpoznać moment, w którym przydatna automatyzacja przechodzi w niekontrolowaną sprawczość.

Google’owska odpowiedź — BYOSA i least privilege — sama w sobie dobrze pokazuje, gdzie naprawdę siedział problem. Nie w modelu. W architekturze roli.  

Podsumowanie

W przypadku Vertex AI problemem nie był model. Problemem była sprawczość agenta osadzonego w złym modelu zaufania.

LLM to rdzeń poznawczy. Agent to ten sam rdzeń osadzony w celu, narzędziach, tożsamości i uprawnieniach.

I dlatego agent nie staje się groźny dlatego, że jest „zły”. Staje się groźny wtedy, gdy architektura daje mu za dużo.  

Źródła

SecurityWeek — omówienie badań Unit 42 i reakcji Google na problemy bezpieczeństwa w Vertex AI.  

Dark Reading — o over-privileged design w Vertex AI i ryzyku wynikającym z nadmiernych uprawnień.  

The Hacker News — techniczne streszczenie problemu z modelem uprawnień, P4SA i dostępem do danych oraz artefaktów.