Błąd w Google Dialogflow CX mógł umożliwić przejęcie rozmów agentów AI - Security Bez Tabu

Błąd w Google Dialogflow CX mógł umożliwić przejęcie rozmów agentów AI

Cybersecurity news

Wprowadzenie do problemu / definicja

W Google Dialogflow CX ujawniono podatność, która w określonych warunkach mogła umożliwić przejęcie kontroli nad przebiegiem rozmów prowadzonych przez agentów konwersacyjnych AI. Problem dotyczył mechanizmu Code Blocks w Playbooks, czyli funkcji pozwalającej na uruchamianie niestandardowego kodu Python w celu rozszerzania logiki bota oraz integracji z systemami zewnętrznymi.

Incydent ten pokazuje, że bezpieczeństwo platform AI zależy nie tylko od jakości modeli i ochrony przed prompt injection, ale także od prawidłowej izolacji środowisk wykonawczych, kontroli uprawnień i odporności infrastruktury chmurowej na nadużycia.

W skrócie

Podatność, opisana jako „Rogue Agent”, miała wynikać ze sposobu wykonywania kodu w środowisku współdzielonym przez agentów Dialogflow CX w obrębie tego samego projektu Google Cloud. W praktyce możliwe było nadpisanie kluczowego pliku odpowiedzialnego za uruchamianie Code Blocks i osadzenie złośliwej logiki działającej w legalnym przepływie konwersacji.

  • atakujący mógł potencjalnie przechwytywać treść rozmów,
  • manipulować odpowiedziami agenta,
  • podszywać się pod prawidłowe komunikaty systemowe,
  • wyłudzać dane użytkowników,
  • eksfiltrować informacje poza środowisko platformy.

Zgłoszenie problemu nastąpiło w listopadzie 2025 roku, częściową poprawkę wdrożono w kwietniu 2026, a pełną naprawę w czerwcu 2026.

Kontekst / historia

Dialogflow CX to platforma klasy enterprise wykorzystywana do budowy zaawansowanych agentów konwersacyjnych dla obsługi klienta, sektora finansowego, ochrony zdrowia i innych obszarów przetwarzających dane wrażliwe. W takich wdrożeniach szczególne znaczenie mają mechanizmy rozszerzania logiki rozmów, ponieważ to właśnie one łączą model konwersacyjny z procesami biznesowymi i zewnętrznymi API.

W analizowanym przypadku kluczową rolę odegrał model uruchamiania Code Blocks w środowisku zarządzanym przez Google, opartym o Cloud Run. Jeśli wielu agentów w tym samym projekcie korzystało z tego samego mechanizmu, współdzieliły one istotne elementy środowiska wykonawczego. To wskazuje na problem z separacją agentów i ograniczeniem skutków nadużycia pojedynczego komponentu.

Analiza techniczna

Sednem problemu był sposób realizacji wykonywania kodu Python osadzonego w Code Blocks. W określonych warunkach możliwe było modyfikowanie pliku odpowiedzialnego za uruchamianie tego kodu przy użyciu mechanizmu exec(). Jeśli atakujący posiadał uprawnienia do konfiguracji Code Blocks, mógł potencjalnie wprowadzić złośliwy kod do współdzielonego środowiska.

Z technicznego punktu widzenia ryzyko wynikało z połączenia kilku cech architektury:

  • publicznie dostępnej instancji Cloud Run,
  • zapisywalnego systemu plików,
  • możliwości modyfikowania plików odpowiedzialnych za wykonanie kodu,
  • braku wystarczających ograniczeń dla arbitralnego kodu Python,
  • współdzielenia środowiska wykonawczego między agentami w tym samym projekcie.

Po skutecznym nadpisaniu pliku wykonawczego złośliwa logika mogła działać w tym samym kontekście co legalny kod konwersacyjny. Oznaczało to możliwość odczytu danych aktywnej sesji, analizy kontekstu rozmowy oraz wpływania na odpowiedzi generowane przez agenta.

  • przechwytywanie treści rozmów użytkowników,
  • podszywanie się pod prawidłowy przebieg konwersacji,
  • zwracanie spreparowanych odpowiedzi,
  • wstrzykiwanie komunikatów phishingowych,
  • utrzymywanie trwałej logiki wpływającej na kolejne sesje.

Badacze wskazali również możliwość ustanowienia kanału komunikacji z zewnętrzną infrastrukturą, co mogło wspierać eksfiltrację danych i zdalne sterowanie operacją. Dodatkowe ryzyko wiązało się z potencjalnym wykorzystaniem Instance Metadata Service w środowisku Cloud Run do pozyskania tokenów konta serwisowego, co mogło zwiększyć zasięg incydentu poza pojedynczego agenta.

Konsekwencje / ryzyko

Skutki takiej podatności należy ocenić jako poważne, szczególnie w organizacjach wykorzystujących agentów AI do obsługi procesów zawierających dane osobowe, finansowe, medyczne lub operacyjne. Naruszenie nie dotyczyłoby wyłącznie warstwy aplikacyjnej, ale także zaufania do całego kanału komunikacji z klientem.

  • naruszenie poufności rozmów,
  • utrata integralności odpowiedzi agenta,
  • prowadzenie ukrytych kampanii phishingowych z poziomu zaufanego interfejsu,
  • obejście założeń segmentacji między agentami w jednym projekcie,
  • możliwe nadużycie uprawnień i tokenów w środowisku chmurowym,
  • utrudnione wykrycie incydentu z powodu ograniczonej widoczności zmian w logach.

Z perspektywy biznesowej szczególnie groźne jest to, że użytkownik może otrzymywać fałszywe komunikaty od legalnie wdrożonego bota. W takim scenariuszu tradycyjne szkolenia z rozpoznawania phishingu mogą być niewystarczające, ponieważ źródłem oszustwa staje się zaufany kanał samoobsługowy.

Rekomendacje

Organizacje korzystające z platform konwersacyjnych AI powinny traktować ten przypadek jako sygnał do przeglądu architektury bezpieczeństwa, modelu uprawnień i zasad izolacji środowisk. Szczególne znaczenie ma kontrola nad wszelkim niestandardowym kodem uruchamianym w ramach usług zarządzanych.

  • przeprowadzić audyt wszystkich agentów Dialogflow CX korzystających z Code Blocks i Playbooks,
  • ograniczyć uprawnienia do konfiguracji niestandardowego kodu zgodnie z zasadą najmniejszych uprawnień,
  • rozdzielać agentów wysokiego ryzyka do osobnych projektów chmurowych,
  • monitorować zmiany w logice konwersacyjnej, integracjach wychodzących i środowisku wykonawczym,
  • minimalizować dostęp środowisk do sieci i usług metadanych,
  • wdrożyć detekcję anomalii w odpowiedziach agentów, zwłaszcza przy żądaniach danych uwierzytelniających,
  • przeglądać zakres uprawnień kont serwisowych i tokenów,
  • wymagać od dostawców jasnej dokumentacji dotyczącej izolacji tenantów, agentów i workloadów,
  • regularnie testować scenariusze nadużyć związane z promptami, kodem i integracjami API.

W środowiskach produkcyjnych obsługujących dane szczególnie wrażliwe warto także rozważyć zakaz osadzania dowolnego kodu, jeśli nie istnieją silne kontrole kompensacyjne oraz formalny proces przeglądu bezpieczeństwa.

Podsumowanie

Przypadek „Rogue Agent” pokazuje, że ryzyko w systemach AI obejmuje nie tylko błędy logiczne modeli, ale także klasyczne słabości infrastruktury, izolacji i zarządzania uprawnieniami. W podatnych warunkach pojedyncze uprawnienie do konfiguracji Code Blocks mogło otworzyć drogę do przejęcia rozmów, manipulowania agentami i eksfiltracji danych w skali całego projektu.

Dla zespołów bezpieczeństwa oznacza to konieczność traktowania platform konwersacyjnych AI jak krytycznych systemów aplikacyjno-chmurowych. Wymagają one pełnego modelowania zagrożeń, segmentacji, ciągłego monitoringu oraz rygorystycznej kontroli wszystkich mechanizmów pozwalających na wykonywanie niestandardowej logiki.

Źródła

  1. https://www.securityweek.com/google-dialogflow-cx-bug-allowed-attackers-to-hijack-ai-conversations/
  2. https://www.varonis.com/blog/rogue-agent
  3. https://cloud.google.com/dialogflow/cx/docs
  4. https://cloud.google.com/run/docs
  5. https://cloud.google.com/vpc-service-controls/docs/overview