Google удалила опасные сценарии ИИ-агентов из репозитория ADK
Google удалила из репозитория Agent Development Kit для Python три сценария автоматизации: issue-analyze.yml, issue-fix.yml и pr-analyze.yml. Pillar Security показала, что содержимое публичной GitHub Issue могло повлиять на triage-агента, заставить доверенного бота вызвать привилегированный процесс и в итоге обеспечить выполнение произвольного кода на CI-раннере.
Исследователи также продемонстрировали извлечение персонального токена доступа бота. В окружении привилегированной задачи находились ключ Google API и учётные данные сервисного аккаунта Google Cloud. При этом подтверждений эксплуатации в реальных атаках или компрометации выпускаемого пакета ADK Python нет: проблема затрагивала автоматизацию репозитория.
Как публичный текст получил доверенные полномочия
Сценарий issue-analyze.yml автоматически запускался при создании Issue. Он передавал агенту Antigravity переменные ADK_TRIAGE_AGENT и GOOGLE_API_KEY, использовал ADK_GCP_SA_KEY для аутентификации, а затем публиковал сформированный анализ от имени adk-bot.
Через инъекцию инструкций в Issue публичного агента можно было вынудить написать команду /adk-issue-fix. Сценарий issue-fix.yml разрешал её выполнение, если автором комментария был владелец, участник или соавтор репозитория. Бот имел статус collaborator, поэтому проверка принимала его сообщение, хотя сам текст команды сформировал внешний пользователь.
Доверенная идентичность бота фактически стала мостом авторизации между недоверенным вводом и привилегированной задачей.
Почему ограничение команд не остановило атаку
Привилегированный процесс имел доступ на запись к Issues, содержимому репозитория и pull request. Эти настройки относились к создаваемому GitHub токену GITHUB_TOKEN, тогда как при получении кода применялся PAT агента ADK_TRIAGE_AGENT. Точный набор его прав публично не раскрыт.
Скрипт отклонял метасимволы оболочки и допускал лишь команды, первым словом которых было gh или git. Однако включённая конфигурация CapabilitiesConfig() активировала все инструменты Antigravity, включая запись файлов. Агент мог создать исполняемый файл и перенаправить Git на него через core.hooksPath, после чего разрешённая команда Git запускала полезную нагрузку.
Этот сценарий дополняет атаку агента OpenAI через открытые учётные данные, где агент применил доступные учётные данные в контролируемой атаке, и подчёркивает риск сочетания недоверенного текста с секретами и инструментами записи.
Что установлено и что осталось неизвестным
Публичные материалы не подтверждают, что PAT позволял напрямую отправлять изменения в основную ветку. Google сообщила Pillar Security, что сервисный аккаунт имел доступ к Vertex AI в отдельном проекте управления GitHub, но более широкие разрешения не раскрывались. Не установлены и конечные возможности скомпрометированных учётных данных в репозиториях или облаке.
Google удалила все три сценария патчем с авторской датой 9 июня 2026 года. Pillar Security проверила их отсутствие 2 июля, а 21 июля получила подтверждение исправления. Проверка The Hacker News 4 августа также не обнаружила эти файлы в каталоге сценариев основной ветки.
Практический вывод
Для бизнеса ключевой урок состоит в том, что проверять нужно не только идентичность автора команды, но и происхождение самого управляющего сигнала. Разные агенты должны использовать отдельные учётные записи, токены и инструменты с минимальными правами, а недоверенный текст не должен иметь возможности сформировать команду запуска привилегированной автоматизации.