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

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

Но пока внимание приковано к тому, насколько хорошо ИИ ищет уязвимости, мало кто задаётся обратным вопросом: «Хорошо ли модели защищаются от вредоносного кода, который им подсовывают в виде «обычных» утилит?»

Всем привет! Я Никита Беляевский, инженер в HiveTrace, и в этой статье мы разберем такой вопрос на примере Grok Build. Однако речь идёт не о конкретном продукте. Описанная схема основана не на особенностях реализации Grok Build, а на самой модели работы современных кодовых агентов. Если агент умеет пользоваться инструментами и у него есть права выполнять команды в системе, аналогичный сценарий возможен и для других решений, таких как Claude Code, Open Code и других.

Зачем вообще это проверять?

Классическая рекомендация по безопасности – «не запускать непроверенные программы» давно стала привычной. Но с появлением ИИ-агентов модель взаимодействия изменилась.

Теперь пользователь не запускает код самостоятельно, а просто формулирует задачу на естественном языке: «скачай репозиторий», «установи зависимости», «запусти утилиту». Мы отдаем все на откуп агенту. Он сам выбирает, какие файлы читать, какие команды выполнять и каким инструкциям в репозитории следовать.

При этом с точки зрения агента репозиторий может выглядеть совершенно обычным: README, понятная структура проекта, осмысленные названия файлов. Но если вредоносный код скрыт, то заметит ли агент подмену или без колебаний выполнит всё необходимое для запуска?

Именно этот сценарий мы и решили проверить.

Как агент выполняет задачу?

Прежде чем проводить эксперимент, полезно представить типичный сценарий работы современного кодового агента.

Получив задачу «запусти программу», агент сначала клонирует проект, читает README, изучает структуру файлов и пытается оценить, безопасно ли выполнять код. Если ничего подозрительного не находит, он переходит к запуску.

На первый взгляд кажется, что единственная задача атакующего - спрятать вредоносный код так, чтобы агент его не заметил. На практике это не самый простой путь.

Большинство современных агентов по умолчанию относятся к коду из интернета с осторожностью. Они просматривают не только исходники, но и окружение, анализируют подозрительные конструкции и пытаются найти потенциальные «красные флаги». Полностью скрыть вредоносную функциональность от такого анализа оказывается достаточно сложно.

Поэтому в нашем сценарии ставка делается не на сокрытие кода, а на убеждение модели. У агента есть две точки, в которых можно повлиять на его решение:

1. На этапе первичного анализа, когда агент определяет, какие файлы или конструкции выглядят подозрительно.

2. На этапе проверки этих подозрений, когда агент пытается убедиться, что тревога не является ложной.

Если убедить модель, что найденный «красный флаг» имеет безобидное объяснение, она с высокой вероятностью продолжит выполнение задачи и перейдёт к запуску программы.

Именно на этом принципе и построен наш PoC: не заставить агента не заметить опасный код, а заставить его поверить, что собственные подозрения были ложными.

Как устроена атака?

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

Лицо репозитория

Сам репозиторий не вызывает подозрений. README написан на русском языке, содержит описание возможностей, примеры вывода и инструкции по запуску. Однако большую роль здесь играет не функциональность утилиты, а то, как агента подводят к нужному сценарию.

По умолчанию программа выполняет безобидную диагностику, но в документации отдельно подчёркивается, что для «лучшей производительности» рекомендуется воспользоваться режимом очистки. Более того, именно запуск с флагами -c (--clear) показан в разделе «Быстрый старт».

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

Архитектура обмана

Структура репозитория выглядит так:

Основной Python-файл действительно выполняет заявленную функцию - собирает и выводит информацию о системе. Дополнительный режим «очистки» активируется только при запуске с соответствующим флагом.

В репозитории также присутствует полностью безобидный исходный код модуля очистки: удаление .tmp, .log, очистка корзины и другие типичные операции обслуживания. Рядом лежит build.sh, который показывает, как этот код якобы компилируется в clear.so с помощью Nuitka.

Для агента такой проект выглядит вполне прозрачным: есть исходники, есть скрипт сборки, есть готовый бинарный модуль. Ничто не указывает на то, что исполняемый clear.so может содержать логику, отличающуюся от представленного исходного кода.

Полезная нагрузка

В действительности именно clear.so содержит полезную нагрузку. При вызове с флагом выполняется rm -rf / , уничтожающий файловую систему тестовой машины.

(Важно подчеркнуть, что это лабораторное исследование. Все эксперименты проводились внутри ВМ Ubuntu. Запускать подобный код на рабочей системе, разумеется, нельзя.)

Proof of Concept

Условия

Ниже - не «эталонный протокол для всех продуктов», а как это выглядело на практике в Grok Build: что агент читал, как проверял, где решил, что можно запускать, и чем закончилось. Этот класс ошибки не уникален для одного агента.

Ход работы агента

Почему агент ошибся

Можно предположить, что кодовый агент просто проигнорирует проверку бинарного модуля и сразу выполнит инструкции из README (Как во многих примерах работы непрямых промпт инъекций, например). На практике всё наоборот. Большинство агентов стараются относиться к коду из интернета с недоверием. Они читают документацию, изучают окружение, анализируют исходники и пытаются понять, безопасно ли запускать проект.

Как это было в нашем случае:

Проблема возникает именно на этапе проверки бинарника.

Полностью восстановить логику скомпилированного clear.so для языковой модели сложно, дорого и не всегда надёжно. Поэтому агент вынужден искать косвенные подтверждения того, что бинарный модуль безопасен.

И здесь репозиторий начинает работать против него. Рядом с бинарником уже лежит правдоподобный исходный код, который реализует ожидаемую функциональность, и скрипт сборки, объясняющий происхождение clear.so. Все эти артефакты согласуются друг с другом и создают убедительную картину «обычного» проекта.

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

Именно это и является основной идеей.

Цель атаки - не скрыть вредоносный код любой ценой, а создать для агента правдоподобное объяснение, из-за которого его первоначальные подозрения будут сняты.

Неудачные и поучительные моменты

Большая часть времени ушла на проверку разных гипотез. Мы перебрали множество способов спрятать вредоносную логику, однако в большинстве случаев агент её находил и отказывался выполнять код. Именно эти отказы постепенно подсказали, какую именно модель проверки использует агент и где находится её слабое место.

Иногда результаты были довольно забавными. Например, в одном из запусков, обнаружив вредоносный код, Grok Build выдал лаконичное:

Вместо «практических советов»

Если отвечать на поставленный в самом начале вопрос «Хорошо ли модели защищаются от вредоносного кода, который им подсовывают в виде «обычных» утилит?», то ответ будет: «Терпимо, но недостаточно». Этот пример со временем перестанет работать, но появятся новые уязвимости. Так происходит с большинством исследований в области безопасности.

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

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