Google закрыла цепочку уязвимостей в open source ADK for Python, который, по данным исследователей, скачали более 90 млн раз: атака между AI-агентами позволяла боту с низкими правами подтолкнуть более привилегированную автоматизацию к опасным действиям. Для команд, уже встраивающих LLM-агентов в pull request, issue и CI/CD, это не абстрактная страшилка из отчета, а очень прикладной сценарий. Проблема теперь не только в том, что умеет конкретный бот, но и в том, кого он способен незаметно запустить дальше, сообщает Dark Reading.
Проблему нашла Pillar Security в репозитории adk-python. Речь идет об Agent Development Kit от Google, который широко используют разработчики, работающие с Gemini и агентными workflow на Python. По данным Pillar, баги раскрыли Google в начале июня, а исправления вышли 9 и 21 июля. Исследователи отдельно отметили быструю реакцию Google, хотя на момент публикации Dark Reading компания не дала оперативный публичный комментарий. Это важная деталь: уязвимость жила не в каком-то экзотическом внутреннем скрипте, а в популярном open source инструменте, который часто оказывается рядом с репозиториями, пайплайнами и учетными данными.
Сценарий атаки выглядел неприятно буднично. Исследователи спрятали prompt injection в GitHub pull request, то есть в тот самый недоверенный контент, который внешние участники проекта и должны уметь присылать. Публичный агент, задачей которого было читать такие pull request и помогать с ревью, под влиянием этого текста публиковал специально оформленную команду @gemini-cli. Дальше срабатывал dispatcher workflow: он воспринимал комментарий как валидный триггер и передавал задачу другой автоматизации на базе Gemini, уже с правами уровня мейнтейнера.
Именно здесь история становится интересной не только для специалистов по LLM-безопасности. Второй агент находился по другую сторону границы доверия и мог выполнять действия, недоступные первому: работать с привилегированными операциями в репозитории, запускать процессы в CI/CD и, в перспективе, проталкивать вредоносный код дальше по цепочке поставки ПО. Проще говоря, злоумышленнику не нужно было сразу ломиться в дверь, закрытую для внешних участников. Достаточно было убедить младшего бота оставить комментарий нужного формата, а остальное делал уже старший коллега, которому система привыкла доверять.
Pillar называет находку первым практическим случаем эксплуатации по схеме «агент против агента» в реальной продакшен-среде. Даже если оставить громкость формулировки на совести исследователей, сам вектор атаки выглядит вполне зрелым. Это не просто очередной prompt injection, которых у индустрии и без того хватает. Здесь инъекция работает как спичка, а главным топливом становится делегирование: один агент читает недоверенный текст, второй обладает правами, третий слушает триггеры, и в какой-то момент формально безопасные куски инфраструктуры собираются в небезопасную систему. Поэтому атака между AI-агентами тревожит сильнее обычного бага в одном сервисе.
Рынок к этому сценарию, надо признать, сам уверенно шел. Компании все активнее раскладывают разработку и эксплуатацию на цепочку специализированных агентов: один разбирает issue, второй пишет комментарии, третий запускает тесты, четвертый готовит изменения, пятый одобряет действие после команды в чате. В комментарии Dark Reading вице-президент Liquibase по маркетингу Райан Маккарди сформулировал суть без модных метафор: недостаточно управлять каждым агентом по отдельности, нужно понимать, что один агент способен заставить сделать другой. Для DevSecOps это почти классическая проблема доверенных связей, только теперь она замаскирована под «умную автоматизацию».
Для разработчиков, продактов и IT-руководителей вывод здесь довольно приземленный. Если агент читает pull request, issue, тикеты, письма или чаты поддержки и при этом имеет токены, доступ к репозиторию, возможность дергать workflow либо публиковать команды для других ботов, его нельзя считать безопасным по умолчанию только потому, что у него «мало прав». В такой архитектуре важно не столько минимальное разрешение каждого участника, сколько карта переходов между ними. Один низкопривилегированный агент не должен иметь возможность без независимой проверки активировать другого, более привилегированного. Иначе атака между AI-агентами быстро превращает удобный пайплайн в лишнюю дыру в цепочке поставки ПО.
Рекомендации Pillar на этом фоне звучат не как академический чек-лист, а как нормальная гигиена для 2026 года: сначала понять, где в компании уже вообще живут agentic-workflow, потом урезать им инструменты и права до минимума, раздать отдельные идентичности вместо человеческих аккаунтов и не оставлять долгоживущие креды там, где агент читает внешний текст. Самое важное — не позволять триггерам от младших ботов бесконтрольно запускать старших. Хронологию исправлений и описание PoC можно сверить в материале ; дальше для рынка останется уже более неприятный вопрос — сколько похожих связок между агентами компании успели собрать раньше, чем начали моделировать их как полноценную поверхность атаки.