Осенью 2025 года компания Varonis нашла в Google Dialogflow CX дыру, которую сама же назвала Rogue Agent. Суть простая и неприятная: человек с правом редактирования одного-единственного агента, использующего Code Block, мог дотянуться до всех остальных агентов с такой же функцией внутри того же проекта Google Cloud. Не через взлом модели, не через хитрый промпт — через обычную функцию редактирования кода, которая давно доступна разработчикам.
О находке сообщили через программу Vulnerability Reward Program самой Google. Первый патч вышел в апреле 2026 года, но окончательно проблему закрыли только в июне — то есть с момента раскрытия в ноябре 2025-го прошло около семи месяцев. Отдельного CVE уязвимости не присвоили, что для дыры такого масштаба выглядит странновато, но факт есть факт.
Уязвимость касалась не всех подряд, а конкретно тех, кто пользуется Playbooks в Dialogflow с включёнными Code Blocks — то есть кастомным Python-кодом, который разработчики добавляют для управления диалогом, проверки ввода или вызова внешних инструментов. Атака требовала одного разрешения — dialogflow.playbooks.update — на хотя бы одном агенте. Значит, речь не про анонимного хакера из интернета, а про инсайдера или, что более вероятно, про скомпрометированный аккаунт разработчика. Дальше уже неважно, насколько ограничены были его права: захватив плацдарм на одном агенте, атакующий получал доступ ко всем агентам проекта разом.
Что можно было сделать, получив такой доступ? Читать вживую переписку между ботами и пользователями. Тянуть данные, которые люди доверяли чат-боту — от email до платёжных деталей. И, что особенно противно, заставлять бота от своего имени писать пользователям сообщения — например, с просьбой заново ввести пароль, замаскированной под обычный запрос техподдержки.
Корень проблемы в том, как устроен рантайм Code Blocks. Разработческий Python-код запускается в среде Cloud Run, управляемой самой Google, и все агенты, использующие Code Blocks в рамках одного проекта, делят один и тот же экземпляр этой среды. Клиент не видит, что там происходит, и не контролирует это — только Google. Varonis обнаружила, что реальной изоляции между агентами внутри этого общего пространства попросту нет.
Технически код разработчика дописывается к внутреннему setup-коду и передаётся в функцию exec() в Python. Setup-код заранее объявляет доступные переменные и функции: history хранит всю историю переписки, state — данные сессии вроде её ID, а respond() позволяет боту отправить любую строку в качестве ответа. Ключевой файл называется code_execution_env.py, и он, как выяснилось, лежал в общей среде с правом записи — то есть его можно было перезаписать.
Сама атака выглядела так: злонамеренный Code Block скачивал изменённую версию code_execution_env.py с сервера атакующего и перезаписывал оригинал прямо внутри работающего контейнера. После этого поддельная версия файла начинала обслуживать выполнение каждого Code Block на каждом агенте, использующем ту же среду, — с полным доступом к history, state и respond(), точно так же, как легитимный код. Замести следы было легко: атакующий восстанавливал исходный Code Block через консоль Dialogflow, и там всё выглядело чисто. Но консоль показывает только то, что должно выполняться — сама подмена файла в контейнере от этого никуда не девалась и продолжала работать.
Помимо основной дыры Varonis нашла ещё две смежные проблемы. Первая — неограниченный исходящий доступ в интернет из среды Code Block. Исследователи с помощью встроенной библиотеки urllib отправляли данные на внешний сервер и получали оттуда команды обратно, при этом полностью обходя VPC Service Controls — механизм периметра безопасности Google Cloud. Среда выполнения кода фактически находилась вне защищённого периметра, что открывало дорогу и к утечке данных, и к удалённому управлению. Вторая проблема серьёзнее не была: среда открывала доступ к Instance М⃰data Service, внутреннему эндпоинту, который обычно выдаёт облачные учётные данные. Запрос к нему возвращал токен служебного аккаунта Google с низкими привилегиями, так что прямой риск был ограничен. Но сам факт, что песочница для выполнения кода вообще способна достучаться до IMDS, — уже проблема архитектуры.
С логированием тоже не всё гладко. Подмена файла происходила внутри среды, принадлежащей Google, и клиенты не имели туда никакого доступа. Cloud Logging не фиксировал ни изменение файла, ни внедрённый код. Обнаружить атаку со стороны клиента было сложно, но не невозможно — некоторые действия всё же оставляли следы в других логах.
Тем, кто запускал агентов Dialogflow CX с Playbooks на Code Blocks до выхода патча, стоит проверить несколько вещей: кто именно обладает правом dialogflow.playbooks.update, поскольку это единственная точка входа; изучить журналы аудита DATA_WRITE для Dialogflow API на предмет неожиданных обновлений playbook, сопоставляя их с подозрительными пользователями, IP-адресами или временем доступа; прогнать запрос в Cloud Logging на предмет неудачных пользовательских запросов — ошибки могут выдать исключения, брошенные вредоносным кодом; и вручную открыть Playbooks каждого агента в консоли, чтобы убедиться, что каждый Code Block действительно был одобрен именно вами.
Google уязвимость закрыла, и ни в Varonis, ни в самой Google не нашли доказательств того, что дыра когда-либо реально эксплуатировалась. В этом смысле Rogue Agent отличается от большинства недавних находок в области безопасности ИИ. Reprompt и SearchLeak от Varonis превращали один клик в кражу данных внутри Microsoft Copilot. ForcedLeak от Noma Security прятал инструкции в веб-форме Salesforce, чтобы вытащить данные CRM. Исследователи Microsoft показывали, как prompt injection перерастает в выполнение кода в рамках фреймворка Semantic Kernel. Все эти случаи так или иначе манипулировали самой моделью или заставляли её выполнять чужую волю через хитрые тексты. Rogue Agent работал иначе — достаточно было одного обычного права на редактирование, никакой манипуляции моделью не требовалось.
Отсюда и главный урок этой истории: право, которое выглядит как разрешение на редактирование контента, на практике может оказаться правом на выполнение произвольного кода. Любой, кто может добавить Code Block, способен запустить свой Python внутри общей среды, куда клиент физически не может заглянуть. И даже когда провайдер уверяет, что чинить больше нечего, это не отменяет того факта, что заглянуть внутрь этого рантайма своими силами клиент по-прежнему не может.
О находке сообщили через программу Vulnerability Reward Program самой Google. Первый патч вышел в апреле 2026 года, но окончательно проблему закрыли только в июне — то есть с момента раскрытия в ноябре 2025-го прошло около семи месяцев. Отдельного CVE уязвимости не присвоили, что для дыры такого масштаба выглядит странновато, но факт есть факт.
Уязвимость касалась не всех подряд, а конкретно тех, кто пользуется Playbooks в Dialogflow с включёнными Code Blocks — то есть кастомным Python-кодом, который разработчики добавляют для управления диалогом, проверки ввода или вызова внешних инструментов. Атака требовала одного разрешения — dialogflow.playbooks.update — на хотя бы одном агенте. Значит, речь не про анонимного хакера из интернета, а про инсайдера или, что более вероятно, про скомпрометированный аккаунт разработчика. Дальше уже неважно, насколько ограничены были его права: захватив плацдарм на одном агенте, атакующий получал доступ ко всем агентам проекта разом.
Что можно было сделать, получив такой доступ? Читать вживую переписку между ботами и пользователями. Тянуть данные, которые люди доверяли чат-боту — от email до платёжных деталей. И, что особенно противно, заставлять бота от своего имени писать пользователям сообщения — например, с просьбой заново ввести пароль, замаскированной под обычный запрос техподдержки.
Корень проблемы в том, как устроен рантайм Code Blocks. Разработческий Python-код запускается в среде Cloud Run, управляемой самой Google, и все агенты, использующие Code Blocks в рамках одного проекта, делят один и тот же экземпляр этой среды. Клиент не видит, что там происходит, и не контролирует это — только Google. Varonis обнаружила, что реальной изоляции между агентами внутри этого общего пространства попросту нет.
Технически код разработчика дописывается к внутреннему setup-коду и передаётся в функцию exec() в Python. Setup-код заранее объявляет доступные переменные и функции: history хранит всю историю переписки, state — данные сессии вроде её ID, а respond() позволяет боту отправить любую строку в качестве ответа. Ключевой файл называется code_execution_env.py, и он, как выяснилось, лежал в общей среде с правом записи — то есть его можно было перезаписать.
Сама атака выглядела так: злонамеренный Code Block скачивал изменённую версию code_execution_env.py с сервера атакующего и перезаписывал оригинал прямо внутри работающего контейнера. После этого поддельная версия файла начинала обслуживать выполнение каждого Code Block на каждом агенте, использующем ту же среду, — с полным доступом к history, state и respond(), точно так же, как легитимный код. Замести следы было легко: атакующий восстанавливал исходный Code Block через консоль Dialogflow, и там всё выглядело чисто. Но консоль показывает только то, что должно выполняться — сама подмена файла в контейнере от этого никуда не девалась и продолжала работать.
Помимо основной дыры Varonis нашла ещё две смежные проблемы. Первая — неограниченный исходящий доступ в интернет из среды Code Block. Исследователи с помощью встроенной библиотеки urllib отправляли данные на внешний сервер и получали оттуда команды обратно, при этом полностью обходя VPC Service Controls — механизм периметра безопасности Google Cloud. Среда выполнения кода фактически находилась вне защищённого периметра, что открывало дорогу и к утечке данных, и к удалённому управлению. Вторая проблема серьёзнее не была: среда открывала доступ к Instance М⃰data Service, внутреннему эндпоинту, который обычно выдаёт облачные учётные данные. Запрос к нему возвращал токен служебного аккаунта Google с низкими привилегиями, так что прямой риск был ограничен. Но сам факт, что песочница для выполнения кода вообще способна достучаться до IMDS, — уже проблема архитектуры.
С логированием тоже не всё гладко. Подмена файла происходила внутри среды, принадлежащей Google, и клиенты не имели туда никакого доступа. Cloud Logging не фиксировал ни изменение файла, ни внедрённый код. Обнаружить атаку со стороны клиента было сложно, но не невозможно — некоторые действия всё же оставляли следы в других логах.
Тем, кто запускал агентов Dialogflow CX с Playbooks на Code Blocks до выхода патча, стоит проверить несколько вещей: кто именно обладает правом dialogflow.playbooks.update, поскольку это единственная точка входа; изучить журналы аудита DATA_WRITE для Dialogflow API на предмет неожиданных обновлений playbook, сопоставляя их с подозрительными пользователями, IP-адресами или временем доступа; прогнать запрос в Cloud Logging на предмет неудачных пользовательских запросов — ошибки могут выдать исключения, брошенные вредоносным кодом; и вручную открыть Playbooks каждого агента в консоли, чтобы убедиться, что каждый Code Block действительно был одобрен именно вами.
Google уязвимость закрыла, и ни в Varonis, ни в самой Google не нашли доказательств того, что дыра когда-либо реально эксплуатировалась. В этом смысле Rogue Agent отличается от большинства недавних находок в области безопасности ИИ. Reprompt и SearchLeak от Varonis превращали один клик в кражу данных внутри Microsoft Copilot. ForcedLeak от Noma Security прятал инструкции в веб-форме Salesforce, чтобы вытащить данные CRM. Исследователи Microsoft показывали, как prompt injection перерастает в выполнение кода в рамках фреймворка Semantic Kernel. Все эти случаи так или иначе манипулировали самой моделью или заставляли её выполнять чужую волю через хитрые тексты. Rogue Agent работал иначе — достаточно было одного обычного права на редактирование, никакой манипуляции моделью не требовалось.
Отсюда и главный урок этой истории: право, которое выглядит как разрешение на редактирование контента, на практике может оказаться правом на выполнение произвольного кода. Любой, кто может добавить Code Block, способен запустить свой Python внутри общей среды, куда клиент физически не может заглянуть. И даже когда провайдер уверяет, что чинить больше нечего, это не отменяет того факта, что заглянуть внутрь этого рантайма своими силами клиент по-прежнему не может.