Google удалила из репозитория google/adk-python три сценария GitHub Actions — issue-analyze.yml, issue-fix.yml и pr-analyze.yml — после отчёта Pillar Security. Исследователи показали, что обычное публичное обращение в GitHub Issues могло заставить низкопривилегированного ИИ-агента запустить более привилегированный сценарий с доступом к токену бота и ключам Google Cloud.
Для команд, которые уже подключили ИИ к разбору обращений, автоправкам кода и CI, вывод неприятный, но полезный: доверенный аккаунт бота ещё не означает доверенный источник команды.
Как работала цепочка
По данным Pillar Security и The Hacker News, первым звеном был сценарий issue-analyze.yml. Он срабатывал при открытии публичного issue, проходил аутентификацию через секрет ADK_GCP_SA_KEY, передавал агенту Google Antigravity переменные ADK_TRIAGE_AGENT и GOOGLE_API_KEY, а затем публиковал разбор в комментарии от пользователя adk-bot.
Проблема в том, что adk-bot был не GitHub App, а обычным аккаунтом со статусом collaborator. Исследователи показали, что текст публичного issue можно было использовать для инъекции в промпт и заставить агента первичного разбора оставить комментарий /adk-issue-fix. После этого включался второй сценарий, issue-fix.yml, который слушал именно такие команды.
Почему проверка прав не сработала
issue-fix.yml запускался только если команду оставил owner, member или collaborator. На бумаге защита выглядела разумно. На практике сценарий проверял только того, кто написал комментарий, а не то, кто на самом деле инициировал этот текст. Внешний пользователь подталкивал агента, агент отвечал как доверенный участник, и защита послушно открывала дверь.
Pillar пишет, что этого хватало для произвольного выполнения кода на раннере CI и кражи персонального токена доступа бота, то есть PAT. В окружении задания лежали и другие чувствительные данные: GOOGLE_API_KEY и ключ сервисного аккаунта Google Cloud. По словам исследователей, этот аккаунт имел доступ к Vertex AI в отдельном проекте для GitHub-автоматизации. При этом открытые материалы не подтверждают эксплуатацию уязвимости вне исследовательского сценария и не говорят о компрометации самого пакета ADK для Python: проблема была в автоматизации вокруг репозитория, а не в распространяемой библиотеке.
Отдельная деталь, которую легко упустить: блок permissions в сценарии описывал права временного GITHUB_TOKEN, но сам агент работал с секретом ADK_TRIAGE_AGENT, то есть с отдельным PAT бота. Его точные права доступа публично не раскрывали.
Фильтр по gh и git не спас
В scripts/run_antigravity.py Google пыталась ограничить выполнение команд: сценарий отбрасывал служебные символы оболочки и разрешал только команды, у которых первым токеном были gh или git. Звучит аккуратно, пока не смотришь на соседнюю строку: код создавал агента с CapabilitiesConfig(), а это включало полный набор возможностей Antigravity, в том числе запись файлов.
Дальше математика простая. Если агент умеет писать файлы, ему уже не так важно, что список разрешённых команд короткий. Pillar показала путь через git -c core.hooksPath=...: полезную нагрузку можно записать в рабочую директорию, а затем заставить разрешённый git выполнить её как хук. То есть защита сузила синтаксис команды, но не перекрыла маршрут к реальному исполнению кода.
Что Google убрала из репозитория
Google удалила issue-analyze.yml, issue-fix.yml и pr-analyze.yml коммитом 66730e9. В описании коммита прямо сказано, что эти сценарии прогоняли автоматизированного агента по недоверенному содержимому issue и запросов на слияние с широкими учётными данными репозитория. По данным The Hacker News, метаданные коммита несут дату автора 9 июня 2026 года; 2 июля исследователи уже не находили эти файлы в репозитории, а 21 июля Google подтвердила исправление. Проверка The Hacker News от 4 августа 2026 года показала, что файлов нет и в текущей ветке main.
Есть и ещё один важный штрих. В репозитории существовала более ранняя цепочка с привилегированными сценариями Gemini, где можно было создать убедительный, но ложный след «проверено и одобрено». Финальное принятие изменений всё равно оставалось за человеком с правом слияния, но социальная инженерия в такой схеме становится заметно дешевле.
Значение для рынка
Для российских и СНГ-команд это не просто история про Google. Многие уже строят похожие связки: публичные обращения в GitHub, бот с правом записи, облачные ключи в CI и агент, который «немного помогает» с рутиной. В такой архитектуре главный вопрос не в том, насколько умна модель, а в том, может ли недоверенный текст добраться до доверенной учётной записи. Базовая гигиена здесь скучная, но рабочая: разделять учётные записи ботов, ужимать права токенов, не держать публичный разбор обращений рядом с автоматическим изменением кода и строить авторизацию на сигнале, который нельзя сгенерировать содержимым issue.
Следующий раунд в безопасности ИИ-агентов будет идти не вокруг качества модели, а вокруг границ доверия между агентом, токеном и CI.
Первоисточники: , .