Google удалила из Python-репозитория Agent Development Kit три workflow после того, как исследователи показали: публичный GitHub issue можно превратить в триггер для привилегированного AI-агента. Для команд, которые уже вшивают LLM-ботов в triage, code fix и GitHub Actions, это неприятное напоминание: безопасность AI-агентов ломается не только на модели, но и на связке идентичности бота, токенов и CI. Для русскоязычных команд, которые держат рядом AI-ассистентов, репозиторий и облачные ключи, кейс выглядит пугающе знакомо: автоматика удобна ровно до первого неверного допущения.
Как пишет The Hacker News, цепочка начиналась с публичного workflow issue-analyze.yml, который автоматически срабатывал при создании issue в репозитории ADK. Он аутентифицировался через ключ ADK_GCP_SA_KEY, передавал в агент Google Antigravity переменные ADK_TRIAGE_AGENT и GOOGLE_API_KEY, а затем публиковал разбор проблемы комментарием от имени adk-bot. То есть внешний текст сначала проходил через LLM-агента, а потом возвращался в тот же публичный тред уже с голосом доверенного аккаунта. Исследователи из Pillar Security показали, что содержимое issue можно было использовать как prompt injection и заставить триаж-агента оставить в треде команду /adk-issue-fix.
Дальше включался второй workflow — issue-fix.yml. Он слушал комментарии с /adk-issue-fix и запускался только если команду оставил owner, member или collaborator. На бумаге защита выглядит прилично, но в реальности проверялась только личность комментатора, а не происхождение текста. Поскольку adk-bot числился collaborator, его комментария хватало для обхода gate, хотя исходный импульс шел от пользователя без привилегий. Формально команду подал доверенный участник. По факту его к этой реплике подвел внешний пользователь через публичный issue, и именно эта подмена источника оказалась ключевой.
По данным Pillar, этого оказалось достаточно, чтобы получить произвольное выполнение кода на CI runner и вытащить personal access token бота. В окружении привилегированного job лежали также Google API key и credential сервисного аккаунта Google Cloud, который, по словам исследователей, имел доступ к Vertex AI в отдельном проекте для GitHub-автоматизации. Насколько далеко тянулись его права за пределы этого контура, публично не раскрыто. При этом открытые материалы не подтверждают эксплуатацию в дикой природе и не говорят о компрометации релиза ADK для Python: уязвимым оказался не распространяемый пакет, а автоматизация вокруг репозитория. Еще одна важная деталь: permissions в workflow описывали права сгенерированного GITHUB_TOKEN, но сам агент работал с PAT бота, а его точные scope в открытом доступе не раскрыты.
И это был не теоретический доступ «куда-то в раннер». Привилегированный workflow был рассчитан именно на работу с кодом: он checkout'ил репозиторий с использованием PAT, проходил аутентификацию в Google Cloud, запускал агента с токеном и API-ключом в окружении, а затем должен был править код, создавать fork от имени adk-bot, пушить ветку и открывать pull request. Косвенное подтверждение, что автоматизация действительно жила в проде, тоже было: в материале упоминается bot-generated PR от 4 июня 2026 года. Данных о возможности прямого push в main публично нет, но и без этого поверхность атаки выглядела слишком щедро. Если такой бот встроен в обычный dev loop, удобство очень быстро превращается в supply-chain риск.
Самый показательный кусок здесь не про LLM, а про инженерную самоуверенность. Runner отсеивал shell-метасимволы и разрешал только команды, у которых первым токеном были gh или git. Звучит аккуратно, пока не выясняется, что в коде был включен CapabilitiesConfig(), то есть полный набор инструментов Antigravity, включая запись файлов. После этого агент мог записать полезную нагрузку и заставить разрешенный git выполнить ее через подмененный путь к хукам — тот самый core.hooksPath. Иными словами, allowlist сузил синтаксис, но не закрыл маршрут к исполнению кода. Именно здесь особенно громко щелкает разница между защитой от «опасной команды» и защитой от агента, который умеет писать в файловую систему и сам собирать цепочку действий.
Google в итоге просто вырезала три файла: issue-analyze.yml, issue-fix.yml и pr-analyze.yml. Патч с датой автора 9 июня 2026 года убрал workflow, которые обрабатывали недоверенный текст из issue и pull request с широкими репозиторными учетными данными. По словам исследователей, 2 июля они уже не находили эти файлы в репозитории, 21 июля Google подтвердила исправление, а проверка The Hacker News 4 августа показала, что их нет и в текущей main-ветке. Отдельно в отчете упоминалась и более ранняя цепочка, которая могла создавать ложный след согласования через привилегированные Gemini-workflow, хотя финальный merge все равно оставался за мейнтейнером. Это важная оговорка: речь не о полном автозахвате репозитория без участия людей, а о слишком широком доверии к автоматизации.
Практический вывод для команд простой и не самый приятный: публичный агент, который читает issue или PR, нельзя сажать за один стол с ботом, у которого есть write-доступ, PAT и облачные ключи. Pillar рекомендует разводить bot identities, ужимать scope токенов и строить авторизацию на сигнале, который нельзя сгенерировать недоверенным текстом. На фоне бума AI-автоматизации в разработке безопасность AI-агентов уже не академическая придирка, а базовая гигиена DevSecOps. Следующий раунд в этой истории будет не про качество моделей, а про то, научатся ли команды отличать доверенный аккаунт от доверенного источника действия. Первоисточник: .