Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W środowiskach opartych na agentach konwersacyjnych bezpieczeństwo warstwy wykonawczej ma równie duże znaczenie jak ochrona modeli, danych i uprawnień. Ujawniona luka określona jako „Rogue Agent” dotyczyła platformy Google Dialogflow CX i mogła pozwolić atakującemu z uprawnieniami edycji jednego agenta na przejęcie działania innych agentów w tym samym projekcie Google Cloud. Problem nie wynikał z klasycznego obejścia uwierzytelniania, lecz z niewłaściwej izolacji środowiska uruchomieniowego dla funkcji Code Blocks.
W skrócie
Luka dotyczyła agentów Dialogflow CX korzystających z Playbooks oraz niestandardowych bloków Code Blocks uruchamiających kod Python. Atak wymagał posiadania uprawnienia dialogflow.playbooks.update, a więc nie był scenariuszem zdalnym i anonimowym, lecz zakładał konto deweloperskie po kompromitacji lub działania złośliwego insidera. Po uzyskaniu takiego dostępu możliwe było nadpisanie współdzielonego elementu środowiska wykonawczego, a następnie odczyt bieżących rozmów, eksfiltracja danych użytkowników oraz generowanie odpowiedzi kontrolowanych przez napastnika. Google usunął problem i według dostępnych informacji nie odnotowano dowodów aktywnego wykorzystania luki.
Kontekst / historia
Dialogflow CX jest wykorzystywany do budowy zaawansowanych botów i asystentów konwersacyjnych, w tym rozwiązań obsługujących procesy biznesowe, wsparcie klienta oraz automatyzację interakcji. Wraz z rozwojem funkcji agentowych i możliwości osadzania własnej logiki programistycznej rośnie powierzchnia ataku. W tym przypadku badacze wykazali, że ryzyko nie było związane z samym modelem językowym ani prompt injection, ale z architekturą uruchamiania kodu osadzanego przez deweloperów.
Luka została zgłoszona do programu nagród za błędy Google pod koniec 2025 roku. Producent wdrożył poprawki etapowo, a pełne usunięcie problemu nastąpiło w czerwcu 2026 roku. Incydent wpisuje się w szerszy trend zagrożeń związanych z bezpieczeństwem platform AI, gdzie pozornie ograniczone uprawnienia edycyjne w praktyce oznaczają możliwość wykonywania kodu w środowisku współdzielonym.
Analiza techniczna
Sedno problemu stanowił sposób działania Code Blocks. Kod Python dodawany przez twórcę agenta był dołączany do wewnętrznego kodu inicjalizacyjnego i wykonywany w zarządzanym przez Google środowisku Cloud Run. Kluczowe znaczenie miało to, że wiele agentów z tego samego projektu korzystało ze wspólnego środowiska wykonawczego, bez dostatecznej izolacji między nimi.
Badacze ustalili, że plik odpowiedzialny za opakowanie i uruchamianie kodu, code_execution_env.py, był zapisywalny. W praktyce oznaczało to możliwość użycia jednego bloku Code Block do pobrania zmodyfikowanej wersji tego pliku z infrastruktury atakującego i nadpisania oryginału wewnątrz działającego kontenera. Od tego momentu złośliwy komponent mógł być wykonywany przy każdym uruchomieniu Code Blocks przez inne agenty współdzielące to samo środowisko.
Taki scenariusz dawał napastnikowi dostęp do danych konwersacyjnych, historii sesji oraz funkcji odpowiedzialnych za generowanie odpowiedzi bota. W efekcie możliwe było zarówno pasywne podsłuchiwanie rozmów, jak i aktywne manipulowanie treścią komunikatów. Przykładowym nadużyciem mogło być wyświetlanie komunikatu phishingowego nakłaniającego użytkownika do ponownego podania hasła lub innych danych uwierzytelniających.
Istotnym elementem był także mechanizm ukrywania śladów. Po wstrzyknięciu złośliwej logiki atakujący mógł przywrócić oryginalny kod widoczny w konsoli administracyjnej Dialogflow, podczas gdy zmodyfikowany komponent nadal działał w pamięci środowiska uruchomieniowego. To znacząco utrudniało wykrycie incydentu po stronie klienta.
Badacze wskazali również dwa dodatkowe problemy bezpieczeństwa. Po pierwsze, środowisko Code Blocks miało nieograniczony dostęp wychodzący do Internetu, co umożliwiało bezpośrednią eksfiltrację danych i odbieranie poleceń z zewnętrznej infrastruktury. Po drugie, środowisko udostępniało Instance Metadata Service, z którego można było uzyskać token usługi zarządzanej przez Google. Chociaż konto miało ograniczone uprawnienia, sama dostępność tego interfejsu w sandboxie należy uznać za niepożądaną.
Dodatkowym problemem była ograniczona widoczność telemetryczna. Operacje modyfikujące plik w zarządzanym środowisku nie były wprost widoczne dla klienta, a standardowe logi nie rejestrowały całego przebiegu manipulacji. Z perspektywy zespołów bezpieczeństwa jest to szczególnie istotne, ponieważ utrudnia zarówno detekcję, jak i dochodzenie powłamaniowe.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem luki była możliwość naruszenia poufności i integralności interakcji prowadzonych przez chatboty. W zależności od zastosowania agentów zagrożone mogły być dane osobowe, informacje biznesowe, treści zgłoszeń serwisowych, dane autoryzacyjne oraz wewnętrzne informacje operacyjne przetwarzane w rozmowach.
Ryzyko było szczególnie wysokie dla organizacji, które:
- używały Dialogflow CX z Playbooks i Code Blocks,
- utrzymywały wielu agentów w jednym projekcie Google Cloud,
- przyznawały szerokie uprawnienia edycyjne zespołom deweloperskim lub integratorom,
- traktowały uprawnienia do edycji agenta jako uprawnienia niskiego ryzyka.
Z punktu widzenia modelu zagrożeń był to przypadek eskalacji wpływu w obrębie środowiska współdzielonego. Pojedyncze prawo edycji jednego agenta mogło przełożyć się na oddziaływanie na wiele innych komponentów. To zmienia klasyfikację takich uprawnień: nie są one wyłącznie administracją treścią dialogu, lecz realnie umożliwiają wykonywanie kodu i ingerencję w runtime.
Rekomendacje
Organizacje korzystające z Dialogflow CX powinny potraktować uprawnienie dialogflow.playbooks.update jako uprawnienie wysokiego ryzyka. Należy przeprowadzić przegląd wszystkich ról i kont posiadających ten dostęp oraz ograniczyć go zgodnie z zasadą najmniejszych uprawnień.
W działaniach operacyjnych warto:
- zweryfikować, które agenty korzystały z Code Blocks przed wdrożeniem poprawek,
- przeanalizować logi audytowe
DATA_WRITEdla interfejsu Dialogflow API pod kątem nietypowych zmian w playbookach, - korelować zmiany z nietypowymi kontami, adresami IP, porami dostępu i aktywnością administracyjną,
- sprawdzić błędy wykonania i anomalie w logach, które mogły wskazywać na niestandardowy kod lub wyjątki generowane przez złośliwe bloki,
- ręcznie potwierdzić zawartość wszystkich Code Blocks w agentach oraz zgodność z zatwierdzonym repozytorium kodu,
- wdrożyć rozdzielenie obowiązków między autorów logiki konwersacyjnej a administratorów środowiska chmurowego,
- stosować ścisły monitoring kont deweloperskich oraz ochronę MFA odporną na phishing,
- segmentować projekty i ograniczać współdzielenie zasobów między agentami o różnym poziomie wrażliwości danych.
Z perspektywy architektury bezpieczeństwa warto przyjąć zasadę, że każda funkcja umożliwiająca uruchamianie własnego kodu w systemach AI musi być traktowana jak klasyczna powierzchnia RCE. Obejmuje to przegląd zaufania do środowiska uruchomieniowego, izolacji tenantów, kontroli ruchu wychodzącego oraz dostępu do metadanych chmurowych.
Podsumowanie
„Rogue Agent” pokazuje, że bezpieczeństwo platform AI nie kończy się na ochronie modelu przed manipulacją promptami. W praktyce równie groźne są błędy izolacji w warstwie wykonawczej i błędne założenia dotyczące zakresu uprawnień deweloperskich. W tym przypadku pojedyncze prawo edycji mogło zostać przekształcone w możliwość podsłuchiwania rozmów, kradzieży danych i sterowania odpowiedziami wielu chatbotów.
Dla zespołów bezpieczeństwa najważniejszy wniosek jest jednoznaczny: funkcje typu Code Blocks należy klasyfikować jako mechanizm uruchamiania kodu uprzywilejowanego, a nie jedynie wygodny komponent rozszerzający logikę bota. Odpowiednia kontrola uprawnień, monitoring zmian oraz analiza architektury współdzielonych runtime’ów pozostają kluczowe dla bezpiecznego wdrażania agentów AI w środowiskach produkcyjnych.
Źródła
- Rogue Agent Flaw Could Have Let Attackers Hijack Google Dialogflow CX Chatbots — https://thehackernews.com/2026/07/rogue-agent-flaw-could-have-let.html
- Dialogflow CX documentation — https://cloud.google.com/dialogflow/cx/docs
- Google Cloud IAM documentation — https://cloud.google.com/iam/docs
- Google Cloud Run documentation — https://cloud.google.com/run/docs
- Google Cloud Logging documentation — https://cloud.google.com/logging/docs