Один ИИ-агент может обманом запустить другого агента с более широкими правами и использовать его для атаки на программный проект. Исследователи Pillar Security обнаружили подобную цепочку в рабочем репозитории Google и назвали находку первым практическим примером эксплуатации по схеме «агент против агента».
Проблема существовала в репозитории google/adk-python, связанном с открытым набором инструментов Agent Development Kit для Python. Разработчики применяют ADK для создания и развертывания ИИ-агентов. Количество загрузок пакета превысило 90 млн.
Google уже устранила уязвимую схему в репозитории, однако отказалась выплачивать вознаграждение по программе поиска ошибок. Компания объяснила решение зависимостью атаки от социальной инженерии. Исследование при этом показало новые риски использования ИИ-агентов в процессах CI/CD, включая первичную обработку запросов, проверку изменений и обсуждение кода.
В репозитории работали два класса автоматизированных агентов с разными полномочиями. Общедоступный агент запускался после создания запроса на включение изменений или сообщения о проблеме. Второй агент предназначался только для сопровождающих проекта и обладал более широкими правами.
Обе системы случайно оказались внутри общей границы доверия. Общедоступный агент обрабатывал текст от посторонних пользователей, но работал через персональный токен доступа участника проекта с повышенными полномочиями. Комментарий такого агента мог запустить защищенный рабочий процесс, рассчитанный на команды от доверенных участников.
Исследователи выяснили, что промпт-инъекция способна заставить общедоступного агента вызвать привилегированного помощника и запустить вредоносное действие. Внутренние файлы с описанием рабочих процессов находились в открытом доступе, поэтому потенциальный атакующий мог изучить связь между агентами и подготовить подходящую инструкцию.
Автор исследования Дэн Лисичкин подробно описал механизм атаки и предупредил, что современные модели угроз пока не учитывают многие сценарии взаимодействия между автономными системами. Исследователь также представит результаты во время выступления в AI Village на конференции DEF CON 7 августа.
Для практической атаки злоумышленнику, вероятно, пришлось бы сначала заслужить доверие сопровождающих проекта. Атакующий мог внести несколько полезных изменений, а затем перейти к вредоносной части операции.
На первом этапе преступник создавал запрос на включение изменений, обозначенный исследователем как PR A. Запрос содержал настоящее исправление вместе с вредоносным кодом, измененным файлом package.json или опасной зависимостью.
Общедоступный агент читал описание PR A и помечал запрос для проверки. Поскольку агент использовал токен участника проекта, опубликованный комментарий получал уровень доверия, необходимый для запуска защищенного процесса.
После первичной обработки PR A атакующий создавал второй запрос, PR B, и помещал в текст промпт-инъекцию. Агент выполнял инструкцию и публиковал доверенную команду с упоминанием @gemini-cli. Команда запускала привилегированный рабочий процесс, после чего агент с расширенными правами выполнял вредоносное действие.
Последовательность могла сформировать правдоподобную историю проверки зараженного запроса. Записи создавали впечатление, что человек запросил анализ, Gemini проверила изменения и одобрила код, хотя реальный сопровождающий подобных действий не совершал.
Google отметила важное ограничение атаки. Исследователи продемонстрировали возможность похищения токена GitHub с разрешением pull-requests: write, позволяющим вмешиваться в запрос на включение изменений. Однако автоматическое объединение кода после проверки ботом не выполнялось, поэтому злоумышленнику по-прежнему требовалось убедить сопровождающего вручную принять вредоносный PR.
Компания не выплатила вознаграждение, поскольку правила программы не предусматривают оплату атак, которым для компрометации цепочки поставок необходима социальная инженерия. Google при этом усилила защиту репозитория и решила официально отметить вклад исследователя.
Специалисты Pillar Security считают недостаточным простое разделение агентов по уровням доступа. Каждому агенту требуется отдельная идентичность с четко заданными ресурсами и разрешенными операциями. Использование отдельной учетной записи бота для агента первичной обработки могло предотвратить большую часть описанной атаки.