Google закрыла уязвимость Dialogflow CX, которая позволяла превратить корпоративный AI-чат-бот в тихий канал для кражи переписки и фишинга. Для компаний, которые уже посадили ботов на поддержку клиентов, финсервисы или медицину, это неприятное напоминание: проблема может быть не в модели, а в том, как устроена сама AI-инфраструктура.
О баге сообщает Dark Reading. Исследователи Varonis назвали его Rogue Agent и описали как нарушение границы разрешений в Google Cloud Platform. Сценарий был не про экзотический zero-day с недостижимыми условиями, а про куда более приземленную вещь: злоумышленнику было достаточно получить возможность менять один permission у одного агента в Dialogflow CX. Речь идет о праве dialogflow.playbooks.update, через которое можно было модифицировать Playbooks Code Block и встроить в конвейер обработки диалогов постоянную вредоносную логику.
Ключевая деталь в том, что Dialogflow CX используется не для игрушечных демо, а для вполне боевых сценариев: клиентская поддержка, банковские боты, чат-ассистенты в здравоохранении, голосовые помощники и другие системы, где в диалогах неизбежно всплывают чувствительные данные. По данным Dark Reading, через уязвимость Dialogflow CX атакующий мог получить доступ к истории разговоров и сессионным данным, а заодно аккуратно встроить в диалог, например, ложный запрос на повторную аутентификацию. Иными словами, бот продолжает говорить голосом компании, а пользователь в этот момент уже сдает логин, пароль или другие данные не туда.
Технически атака опиралась на функцию Code Blocks в Dialogflow CX. Она позволяет разработчикам добавлять кастомный Python-код для обработки пользовательского ввода, манипуляции данными и вызова API. Этот код выполняется внутри Google Cloud Run. По словам представителя Google, у такой среды по умолчанию открыт публичный сетевой исходящий трафик, то есть она может устанавливать внешние соединения с интернетом. Для атакующего это удобная почва: вредоносный код не просто сидит внутри бота, а может общаться наружу, пересылать данные и пробивать те самые периметры, на которых команды безопасности привыкли строить zero trust. Вдобавок все Dialogflow-агенты в одном GCP-проекте, использующие Code Blocks, по умолчанию разделяют одно и то же Cloud Run-исполнение, управляемое Google. У заказчика нет прямой видимости в эту среду, а значит, часть атаки происходит буквально за кулисами.
Отсюда и неприятный вывод для IAM-практики. Эксплуатация не требовала полномочий суперадмина. Как пишет Dark Reading, permission dialogflow.playbooks.update мог назначаться на уровне проекта, так что окно риска было шире, чем может показаться при беглом взгляде на роли в облаке. Если учетная запись привилегированного сотрудника скомпрометирована или если права раздавались слишком щедро, одного такого кирпичика хватало, чтобы переписать внутренний файл выполнения и подменить логику следующих разговоров. В экосистеме AI-ботов это уже не просто «ошибка конфигурации», а путь к захвату доверенного канала общения с клиентом.
Varonis сообщила Google о проблеме в ноябре 2025 года. По информации Dark Reading, первый патч вышел в апреле 2026-го, а полностью проблема была закрыта в июне 2026 года. Google заявила, что все затронутые компоненты исправлены, дополнительных действий от клиентов не требуется и признаков компрометации заказчиков компания не обнаружила. Это важное уточнение: речь не о подтвержденной массовой эксплуатации, а о закрытой критической дыре. Но именно такие истории обычно и бьют по ощущению безопасности сильнее всего, потому что показывают, насколько много в AI-сервисах завязано на скрытую облачную механику, которую заказчик не контролирует напрямую.
Для защитников практический вывод здесь довольно скучный, а значит, полезный. Varonis советует пересмотреть логи обновлений Playbooks, проверить неудачные пользовательские запросы, потому что сбои могли быть побочным эффектом вредоносной логики, и вручную просмотреть Code Blocks на предмет несанкционированного кода. Руководитель команды исследований облачной безопасности Varonis Тамир Йехуда отдельно напомнил: защищать нужно не только модель и промпты, но и всю обвязку вокруг них. AI-сервисы тесно переплетены с остальными облачными сервисами, а значит, уязвимость или неверная настройка в соседнем компоненте может дать обходной маршрут к данным бота. Для российских команд, которые строят похожие сценарии на любых облачных и on-prem-платформах, это читается без перевода: минимальные привилегии, раздельные среды выполнения, ревизия прав на уровне проекта, аудит исходящего трафика и отдельный контроль над кодом, который исполняется рядом с диалоговым движком.
История с Rogue Agent хорошо показывает, куда смещается реальный риск в AI-проектах. Пока бизнес спорит о качестве моделей и стоимости токенов, атакующий смотрит на Code Blocks, роли IAM, сетевой egress и общие среды выполнения. Если уязвимость Dialogflow CX чему-то и учит, то не недоверию к самим чат-ботам, а недоверию к упрощенной мысли, будто AI можно безопасно внедрить как еще один интерфейс поверх старого контура. В 2026 году этого уже недостаточно: бот становится частью attack surface, а не просто новым каналом общения.