Манипуляция ИИ‑агентами: как уязвимость в Google Agent Development Kit позволила одному боту подчинить другого
Исследователи из Pillar Security зафиксировали показательный инцидент: в реальном продакшен‑репозитории один ИИ‑агент смог использовать другого как "привилегированного посредника". Уязвимость обнаружили в репозитории google/adk-python - реализации Google Agent Development Kit для Python. Этот случай наглядно показал, как архитектура многокомпонентных ИИ‑систем может породить новые классы атак, даже если классические механизмы авторизации формально настроены корректно.
Два класса ИИ‑агентов - и одна ошибка доверия
В репозитории действовали два типа автоматизированных агентов:
1. Низкопривилегированный агент
`adk-bot` - ИИ‑бот, встроенный в стандартные рабочие процессы: обработка Pull Request (PR), первичная триажа Issue, комментарии от имени обычного разработчика с ролью collaborator. У него не было прямого права влиять на репозиторий так же, как у мэйнтейнеров.
2. Высокопривилегированный агент
`gemini-cli` - агент с расширенным уровнем доступа. Он выполнял анализ кода, давал рекомендации, а главное - мог одобрять PR и инициировать действия от имени системного аккаунта `github-actions[bot]`, включая редактирование и удаление комментариев.
Критическая особенность заключалась в том, что система доверяла не реальным людям, а самим учетным записям агентов. Всё, что публиковал `adk-bot`, воспринималось инфраструктурой как действие надежного участника проекта. В этой модели доверия и скрывалась уязвимость: низкопривилегированный агент мог быть "заставлен" сделать запрос к высокопривилегированному, тем самым обходя границы доступа.
Как устроена цепочка атаки
Сценарий эксплуатации выглядел так:
1. Создание вредоносного PR
Атакующий открывает Pull Request и в его описании помещает тщательно подготовленную промпт-инъекцию. Текст рассчитан на то, чтобы повлиять на логику `adk-bot`.
2. Обработка содержимого `adk-bot`
Низкопривилегированный агент считывает описание PR, воспринимает содержимое как часть задачи и, следуя вложенной инструкции, публикует комментарий в формате:
`@gemini-cli `.
3. Автоматический вызов привилегированного агента
Воркфлоу `gemini-dispatch.yml` настроен так, что реагирует на упоминание `@gemini-cli` в комментариях от пользователя с ролью collaborator. Поскольку `adk-bot` привязан к такому аккаунту, инфраструктура считает его действия доверенными и прокидывает запрос в следующий воркфлоу - `gemini-invoke.yml`.
4. Промпт-инъекция в контексте `gemini-cli`
Инъекция, спрятанная в комментарии, попадает в контекст обработки высокопривилегированного агента. Для него это выглядит как часть валидной инструкции: он видит "запрос от доверенного участника" и исполняет его в рамках своей расширенной роли.
5. Социальная инженерия на завершающем этапе
Используя gemini-cli, атакующий фактически добивается "официального" одобрения PR от имени внутреннего ИИ‑проверяющего. Мейнтейнеры, видя, что бот проверки кода дал "добро", могут смержить изменения, не заподозрив манипуляции.
В результате создается полностью легитимный на вид след автоматической проверки и одобрения. Логи системы и история обсуждения выглядят так, словно всё прошло штатно: PR открыт, проверен ИИ‑агентом, одобрен, смержен. Реальная цель - внедрение вредоносного кода - при этом маскируется под рутинную процедуру.
"Ошибочный доверенный помощник": классика в новой оболочке
По сути, исследователи показали современный вариант хорошо известной в безопасности проблемы confused deputy - "ошибочного помощника". Низкопривилегированный субъект (в данном случае - `adk-bot`) не имеет важных прав напрямую, но может инициировать действия от имени более мощного и доверенного субъекта (`gemini-cli`).
Важно, что здесь не "ломали" систему авторизации как таковую. Все права и роли на уровне платформы были выставлены правильно. Ошибка возникла в логике доверия между агентами: любой запрос, исходящий от одного бота, автоматически считался достойным доверия для другого. Модель безопасности исходила из предположения, что агент не будет злонамеренно сформировывать команды, но не учла, что сам агент можно обмануть через промпт-инъекцию.
Реакция и меры со стороны Google
После публикации результатов исследования ключевые уязвимости в репозитории были устранены. Google усилила защиту, переработала логику воркфлоу и уточнила условия, при которых привилегированные агенты реагируют на сигналы от других сущностей.
Отдельный интерес вызывает то, что социальная инженерия формально не была признана компанией решающим фактором уязвимости. Однако по факту именно комбинация технических недочетов и психологического доверия к "одобрившему" боту подталкивала мэйнтейнеров к опасным действиям. Это показывает, что в эпоху ИИ классические приёмы социальной инженерии начинают распространяться не только на людей, но и на сами алгоритмические системы.
Вторая фаза: Antigravity-SDK, Issues и автоматическое "исправление"
После устранения первой проблемы в репозиторий добавили дополнительную автоматизацию на базе Antigravity-SDK (скрипт `scripts/run_antigravity.py`). Появились два новых GitHub Actions‑воркфлоу:
1. `issue-analyze.yml` - автоматически анализировал новые баг‑репорты (Issue), созданные внешними пользователями.
2. `issue-fix.yml` - запускался, когда доверенное лицо публиковало комментарий `/adk-issue-fix`. В ответ инфраструктура запускала процесс, при котором ИИ‑агент автоматически предлагал и даже писал код для исправления найденной проблемы.
Исследователи снова использовали промпт-инъекцию - но теперь уже в описании Issue. Текст репорта содержал скрытую инструкцию, рассчитанную на то, чтобы повлиять на логику анализа.
Цепочка выглядела так:
- Атакующий создаёт новый Issue и в описании внедряет промпт-инъекцию.
- Воркфлоу `issue-analyze.yml` читает описание, передаёт его ИИ‑агенту и под влиянием инъекции сам публикует комментарий `/adk-issue-fix`.
- Комментарий выходит от имени `adk-bot`, который снова выступает в роли доверенного участника.
- Срабатывает `issue-fix.yml`, включается привилегированный процесс автоматического исправления, и управление передаётся агенту, умеющему исполнять команды в среде Antigravity-SDK.
Так низкопривилегированный пользователь, всего лишь создавший Issue, опосредованно инициировал выполнение полуавтоматического исправления - процесса с существенно более широкими возможностями в репозитории.
Попытка защититься: фильтрация команд и песочница
Для снижения рисков в ходе "исправления" использовали фильтр `issafe_command`. Он выполнял поверхностную валидацию:
- запрещал использование опасных метасимволов (`;`, `|`, `&`, `$` и т.п.),
- ограничивал перечень исполняемых утилит в основном командами `git` и `gh`,
- предполагал, что за счёт этого агенты не смогут выполнить произвольный системный код.
Параллельно исполняемая среда позиционировалась как песочница, призванная отделить действия ИИ от основной инфраструктуры и снизить ущерб в случае компрометации.
Однако, как часто бывает, узкие, "точечные" фильтры не учитывали целый спектр непрямых способов эксплуатации.
Обход защиты: превращаем git в "лаунчер"
Первый путь обхода заключался в том, чтобы использовать разрешённый инструмент - `git` - как универсальный запускатель произвольных операций. Несмотря на отсутствие классических метасимволов в командной строке, исследователям удалось:
- сформировать команды `git`, которые приводили к выполнению нестандартных хуков и скриптов,
- использовать встроенные механизмы конфигурации для подмены поведения некоторых операций,
- добиться запуска внешних программ без явного использования запрещенных символов.
Получилось своего рода RCE через "белый список": утилита считалась безопасной, но в сочетании с определённой конфигурацией и содержимым репозитория превращалась в удобный инструмент для обхода ограничений.
Использование CLI‑утилит в обход намерений разработчиков
Второй вектор был связан с `gh` и другими разрешёнными утилитами:
- через `gh` можно было модифицировать PR, комментарии и метаданные репозитория,
- использовать сторонние сценарии, подключаемые расширения и дополнительные параметры,
- выстраивать сложные цепочки, где каждая отдельная команда формально безопасна, но их комбинация приводит к непредусмотренному поведению.
Так как фильтр `issafe_command` проверял лишь наличие небезопасных символов и не анализировал реальные эффекты команд, атакующие получили возможность выполнять достаточно широкий спектр действий в рамках на первый взгляд строго ограниченной песочницы.
Почему классические подходы к безопасности здесь не сработали
С технической точки зрения, уязвимость состояла не в одиночном "баге", а в совокупности архитектурных допущений:
- Избыточное доверие к ботам:
Любое действие, исходящее от `adk-bot`, автоматически считалось безопасным. Никто не проверял, почему и на основании какого входа агент принял решение опубликовать ту или иную команду.
- Отсутствие строгого разграничения контекстов:
Входные данные от внешних пользователей (PR, Issue) почти напрямую попадали в промпты агентов, которые обладали правами изменения репозитория.
- Наивная фильтрация команд:
Проверка на запрещённые символы и жёсткий список бинарников создавали лишь иллюзию контроля. Сами по себе `git` и `gh` обладают слишком большой выразительной мощностью, чтобы считаться безопасными "по умолчанию".
- Непонимание природы промпт‑инъекций:
Разработчики систем часто недооценивают, что ИИ‑агент интерпретирует текст не как "строку данных", а как потенциальную инструкцию. Поэтому любой внешний текст, попавший в контекст, при определённых условиях превращается в управляющий код.
Что этот кейс говорит о будущем ИИ‑агентов в разработке
Такие инциденты дают понять, что ИИ‑агенты в DevOps и разработке - это не просто "умные помощники", а полноценные участники инфраструктуры, у которых:
- есть учётные записи и токены,
- есть права в репозитории и в CI/CD,
- есть возможность инициировать действия без участия человека.
Их нужно рассматривать как полноценные субъекты безопасности, а не как безобидные скрипты. Это влечёт за собой ряд практических выводов:
1. Разделяйте роли ИИ‑агентов так же строго, как роли людей
Если агент только анализирует текст - он не должен иметь право модифицировать репозиторий, вызывать другие привилегированные сервисы или триггерить CI‑процессы.
2. Не доверяйте цепочке "агент → агент" без дополнительных проверок
Каждый привилегированный агент должен явно проверять источник команды: это человек? другая система? автоматический процесс? И что именно тот источник действительно имел право инициировать данное действие.
3. Минимизируйте прямую интерпретацию внешнего текста как инструкций
Любой контент из PR, Issue, комментариев и описаний задач должен попадать к ИИ в сильно ограниченном виде (например, только фрагменты кода и краткое описание, прошедшее фильтрацию), без прямого копирования всего текста.
4. Оценивайте цепочку действий целиком, а не отдельные команды
Безопасность нельзя строить лишь на проверке "одна команда - один фильтр". Опасной может быть комбинация нескольких формально невинных операций.
Заменит ли вас ИИ‑агент - и как этому противостоять
Этот кейс часто приводят в дискуссиях о том, "почему вас заменит ИИ‑агент". На самом деле он показывает другое: без грамотной архитектуры и политики безопасности любой ИИ‑агент рано или поздно станет уязвимостью или инструментом атаки.
Чтобы ИИ‑агенты не подменили человека, а усилили его:
- Разработчики и мэйнтейнеры должны оставаться конечным арбитром.
Роль "одобрить" изменения или релиз должна быть строго человеческой, особенно когда речь идёт о безопасности и инфраструктуре.
- ИИ должен выполнять подготовительную и рутинную работу - анализ кода, поиск дубликатов, автозаведение Issue, генерацию тестов, но финальное решение и ответственность - за людьми.
- Необходимо выстраивать прозрачный аудит:
Каждое действие агента фиксируется, легко трассируется и отделяется в логах от действий людей. Это помогает быстро увидеть аномалии - в том числе случаи скрытой промпт-инъекции.
Практические рекомендации командам, использующим ИИ‑агентов
Если вы уже внедряете ИИ‑агентов в процессы разработки и поддержки, стоит:
1. Пересмотреть права сервисных аккаунтов и ботов:
- убрать избыточные привилегии,
- запретить им напрямую одобрять изменения, влияющие на безопасность.
2. Ввести вторые факторы доверия:
- помимо статуса аккаунта, проверять происхождение события (вебхуки, воркфлоу, ручной запуск),
- для критичных действий требовать явного подтверждения человека.
3. На уровне промптов жёстко отделять:
- пользовательский текст (данные),
- системные инструкции (политики и правила).
Пользовательский контент не должен иметь возможности "переписать" политику агента.
4. Трактовать любую автоматизацию, которая "сама пишет и сама применяет" код, как зону повышенного риска, требующую ручного ревью до слияния.
5. Регулярно моделировать сценарии атак с участием ИИ‑агентов:
- промпт-инъекции,
- манипуляция правами сервисных аккаунтов,
- цепочки "агент → агент → инфраструктура".
***
Инцидент с Google Agent Development Kit показал, насколько хрупкими могут быть сложные цепочки интеграций, в которых ИИ‑агенты получают реальные права в системах разработки. Традиционные подходы к разграничению доступа и фильтрации команд оказываются недостаточными, если при проектировании игнорировать ключевой фактор: ИИ‑агент - это не "умный линтер", а активный субъект, способный принимать решения на основе внешнего текста. Именно поэтому безопасность многокомпонентных ИИ‑систем сегодня становится не опцией, а базовым требованием к любой современной инженерной инфраструктуре.
