Манипуляция агентами: эксплуатация уязвимостей в репозитории Google Agent Development Kit

Исследователи Pillar Security зафиксировали начальный случай использования одного ИИ-агента другим в реальном продакшен-окружении. Уникальная сейчас уязвимость была найдена в google/adk-python — репозитории Google Agent Development Kit для Python. 

В репозитории работали два класса автоматизированных ИИ-агентов. Первый класс агентов с низким уровнем привилегий был встроен в рабочие процессы, доступные всем, такие как PR или Issue. Следующий же класс имел высокий уровень доступа и предназначался только для мэйнтейнеров. Уязвимость заключалась в том, что низкопривилегированным агентом, доступным для всех, можно было манипулировать, чтобы он активировал высокопривилегированного агента.

Каким был скрипт атаки

Перед разбором цепочки важно знать, что в репозитории Google ADK есть два бота.

• adk-bot — тот самый непривилегированный ИИ-агент, комментирующий PR от имени обычного разработчика (collaborator), триажер для PR и Issue.

• gemini-cli — высокопривилегированный, нужен для проверки кода, одобрения PR.

Ключевая особенность заключалась в том, что платформа доверяла не человеку, а учетной записи агента. Сообщение, автоматически опубликованное adk-bot, воспринималось как действие доверенного участника проекта.

Рассмотрим, как выглядит скрипт атаки.

1. Атакующий создает вредоносный PR. Внутри описания закладывается промпт-инъекция.

2. adk-bot читает содержимое, которое «вынуждает» его обратиться к gemini-cli в формате @gemini-cli <текст инъекции>.

3. gemini-dispatch.yml видит упоминание @gemini-cli от пользователя c ролью collaborator (из-за привязки adk-bot к аккаунту) и направляет в gemini-invoke.yml.

4. Инъекция передается в контекст обработки высокопривилегированного агента и воспринимается как часть инструкции. Агент при этом уже  имеет доступ для проверки кода в PR, его одобрении от имени github-actions[bot], а равным образом удалении или редактировании комментариев других разработчиков.

5. Далее работает социальная инженерия: атакующий открывает PR с вредоносным кодом, через описанную цепочку заставляет gemini-cli «одобрить» внесение изменений. Мейнтейнер видит, что бот одобрил, и может смержить исходник, думая, что проверка безопасности успешно пройдена.

По существу, исследователи продемонстрировали современную реализацию давно известной проблемы confused deputy. Низкопривилегированный агент не обладал расширенными правами самостоятельно, но мог инициировать действия от имени доверенного субъекта. В итоге модель разграничения доступа нарушалась не за счет ошибки в механизме авторизации, а в связи с некорректного распределения доверия между агентами. 

В результате злоумышленник мог создать полностью легитимный на вид след «автоматической проверки и одобрения со стороны ИИ» для вредоносного PR, провоцируя мейнтейнеров на его слияние с главный веткой.

На данный момент Google устранила основные проблемы, которые изначально привели к уязвимости. И хотя организация не сочла социальную инженерию решающим фактором в данном случае, было подтверждено, что проведены работы по укреплению репозитория.

Security Center

Рассказываем о лучших практиках и средствах ИБ, требованиях и изменениях в законодательстве.

Исследовать →

RCE и обход песочницы в Antigravity-SDK

Вскоре после первой находки Google добавил в репозиторий автоматизацию на базе Antigravity-SDK (scripts/run_antigravity.py). Процесс состоял из двух воркфлоу:

• issue-analyze.yml — автоматически анализировал любые новые баг-репорты (Issues) от внешних пользователей.

• issue-fix.yml — активировался при публикации комментария /adk-issue-fix от доверенного лица и автоматически писал код для исправления проблемы.

Цепочка атаки и обход ограничений

Злоумышленник оставлял промпт-инъекцию прямо в тексте нового Issue. Воркфлоу анализа считывал его и под воздействием инъекции сам отправлял команду /adk-issue-fix. Поскольку бот комментировал от имени легитимного соавтора (adk-bot), система воспринимала это как доверенное действие и запускала привилегированный процедура исправления.

Далее воркфлоу исправления передавал управление агенту, чьи команды фильтровались функцией issafe_command. Фильтр блокировал опасные метасимволы (вроде ;, |, &, $) и разрешал запускание только утилит git и gh.

Исследователи обошли защиту двумя путями.

• Использование git как лаунчера: утилита запускалась без запрещенных символов, но выполняла произвольный исходник через встроенные параметры (в частности, git -c "alias.x=!" x или подмену путей хуков git -c core.hooksPath=...).

• Неконтролируемая запись файлов: фильтр проверял только запуск команд, а инструмент записи файлов оставался открытым. Агент мог сначала записать вредоносный сценарий на диск, а затем выполнить его через легитимный git.

Атакующий получал удаленное выполнение кода (RCE) на CI-раннере GitHub. Это позволяло беспрепятственно выгрузить из переменных окружения долгоживущий персональный токен бота ADK_TRIAGE_AGENT и ключ сервисного аккаунта Google Cloud (ADK_GCP_SA_KEY), имевший доступ к платформе Vertex AI.

Сейчас уязвимый воркфлоу полностью удален из репозитория, а сама задача устранена.

Выводы

ИИ-агенты в силу своей эффективности зарабатывают все более широкую известность, постоянно расширяются сферы их применения, но вместе с силой растет и ответственность. Данная уязвимость показала, что агент может стать инструментом для эскалирования привилегий, переходить тонко очерченную границу между доступами.

Это наталкивает на мысль, что нужно разрабатывать новые подходы для обеспечения безопасности: 

1. Не выдавать агенту доступ к реальным учетным записям сотрудников.

2. С особой осторожностью оценивать риски выдачи прав одному агенту на взаимодействие с другим.

3. В отношении агентов, контактирующих с ненадежными источниками данных, нужно использовать политику нулевого доверия, а также задавать жесткие системные промпты.

4. Реализовывать систему мониторинга модели: кто именно запускает выполнение флоу, какие действия она выполняет в ответ на запрос.