AI‑агенты для проверки кода научились исполнять вредоносные скрипты вместо их обнаружения
Исследователи из AI Now Institute описали новый класс атак под названием Friendly Fire, который переворачивает привычное представление о системах автоматического аудита кода. Инструменты, создававшиеся для поиска уязвимостей и защиты инфраструктуры, при определённых условиях сами превращаются в средство компрометации машины разработчика.
Под наибольший риск попали автономные режимы работы таких помощников, как Claude Code и OpenAI Codex, когда им разрешают самостоятельно выполнять команды в процессе анализа стороннего кода без обязательного ручного подтверждения каждого шага. В таком сценарии агент получает слишком широкие полномочия и фактически становится ещё одним привилегированным компонентом в системе разработчика.
Механика атаки Friendly Fire выглядит на первый взгляд банально. Злоумышленнику достаточно подготовить репозиторий или изменить уже существующий проект, встроив в него безобидно выглядящий файл README.md. В этом файле размещается инструкция якобы по безопасному аудиту: например, предложить запустить скрипт security.sh, который "проверит проект на уязвимости" или "настроит среду анализа".
Когда разработчик поручает AI‑агенту провести анализ такого проекта в автономном режиме, агент начинает с изучения документации - в том числе того самого README.md. Поскольку модель обучена следовать инструкциям и помогать "как хороший ассистент", она интерпретирует рекомендацию запустить security.sh как законную часть процесса проверки безопасности. В результате AI‑агент сам инициирует запуск скрипта, не подозревая, что тем самым выполняет вредоносный код на машине пользователя.
В демонстрации исследователей security.sh выступал лишь обёрткой для скрытого бинарного файла, который запускается на локальном компьютере разработчика. Визуально для человека всё выглядит как корректная работа инструмента: ассистент "проверяет" проект, сообщает о ходе анализа, а в это время вредоносный компонент уже выполняет свои операции в фоновом режиме.
Ключевой вывод авторов работы - проблема не ограничивается какими‑то конкретными версиями Claude Code или Codex. Уязвимость заложена в самой архитектуре сценария, где AI‑агент получает право выполнять команды, основываясь на тексте из недоверенных источников. Фактически речь идёт о конфликте двух принципов: максимальная автономия для удобства разработчика и невозможность полностью доверять содержимому чужого репозитория.
Важно, что не все режимы работы подобных инструментов подвержены описанному сценарию. Исследование проводилось именно на автономных режимах: auto‑mode у Claude Code и auto‑review у Codex. В этих конфигурациях ассистент может сам одобрять выполнение команд, что и открывает дверь для Friendly Fire. Если же каждое действие агента требует явного подтверждения пользователя, описанная атака не воспроизводится: человек может заметить подозрительный скрипт и остановить процесс.
Исследователи подчёркивают: уязвимость нельзя устранить простым обновлением модели или интерфейса. Необходимо переосмысление подхода к проектированию подобных систем. В числе потенциальных мер защиты рассматриваются ограничение автономности агентов, жёсткая изоляция среды исполнения (песочницы, отдельные контейнеры, виртуальные машины), а также более строгий отбор источников инструкций - например, явное разграничение "доверенной" документации и потенциально опасных файлов внутри репозитория.
Особый интерес вызывает тот факт, что Friendly Fire укладывается в уже сформировавшийся тренд атак на AI‑инструменты разработки, основанных на доверии модели к внешнему тексту. Ранее демонстрировались атаки через конфигурационные файлы (TrustFall), через символьные ссылки (GhostApproval), а также через поддельные отчёты об ошибках и лог‑файлы (Agentjacking). Во всех этих случаях злоумышленник внедрял инструкции в такие элементы проекта, которые традиционно воспринимаются как вспомогательные и "безопасные". Новизна Friendly Fire в том, что теперь для атаки достаточно стандартного README.md - файла, который разработчики привыкли читать и считать частью безопасной документации.
На сегодняшний день Friendly Fire остаётся концепцией, подтверждённой экспериментами, и случаев её использования в реальных атаках пока не зафиксировано. Однако сама возможность подобного сценария служит серьёзным предупреждением. AI‑агент, обладающий правом запускать команды в системе, должен рассматриваться не как безобидный помощник, а как ещё один высокопривилегированный элемент инфраструктуры разработки. И если раньше основное внимание уделялось уязвимостям в анализируемом коде, то теперь объектом атаки становится уже сам процесс автоматизированного аудита.
Для компаний и команд разработки это означает необходимость пересмотра практик использования AI‑ассистентов. Автономные режимы, позволяющие инструменту самостоятельно выполнять произвольные команды, удобны и экономят время, но создают новый класс рисков. Особенно опасны ситуации, когда агенту предоставлен доступ к рабочей машине с ключами, токенами, возможностью изменять репозитории и конфигурацию окружения. В таком контексте один невинный на вид README.md превращается в возможную точку входа для атаки.
Практический вывод для отдельных разработчиков - относиться к любым "рекомендациям" из документации с недоверием, если они предполагают запуск скриптов или бинарных файлов без явного понимания их содержимого. Даже если инициатором запуска становится не человек, а AI‑ассистент, ответственность за последствия всё равно лежит на том, кто предоставил ему такие полномочия. Желательно отключать автозапуск команд или, как минимум, переводить агентов в режим, при котором каждое действие требует подтверждения.
Отдельного внимания заслуживает вопрос, как именно должны меняться инструменты разработки, чтобы минимизировать подобные угрозы. Один из возможных подходов - строгая сегрегация ролей: AI‑агент может читать код, предлагать правки, анализировать логи, но не имеет прямого права запускать исполняемые файлы или изменять системные настройки. Все операции, выходящие за пределы "чтения и предложения", должны либо выполняться в изолированной среде, либо инициироваться пользователем вручную.
С точки зрения архитектуры безопасной разработки полезным становится принцип "нулевого доверия" к любому тексту, поступающему из внешнего репозитория. README, комментарии в коде, скрипты настройки окружения - всё это следует рассматривать как потенциальный носитель вредоносных инструкций для AI‑агентов. Это не значит, что нужно отказаться от таких файлов, но инструменты должны уметь отличать человеческо‑ориентированную документацию от команд, которые нельзя исполнять автоматически.
Не менее важна и просветительская составляющая. Разработчики, тимлиды и инженеры по безопасности должны понимать, что AI‑ассистент в IDE или терминале - это не просто "умная подсказка", а программный компонент, способный влиять на инфраструктуру так же сильно, как любой другой сервис с правами выполнения команд. Включение подобных рисков в политики безопасности, чек‑листы при ревью и обучение сотрудников - обязательный шаг в условиях всё более широкого распространения AI‑инструментов.
Наконец, исследование Friendly Fire поднимает более общий вопрос: где проходит граница между удобством и безопасностью в эпоху автономных AI‑агентов. Чем больше задач мы делегируем таким системам, тем выше соблазн дать им "полную свободу действий", чтобы не мешать и не тратить время на подтверждение каждого шага. Но именно здесь и возникает окно для атак: модель не умеет интуитивно отличать честную инструкцию в README от умышленно встроенной ловушки, а злоумышленники быстро адаптируются к новым возможностям.
В долгосрочной перспективе это значит, что разработка AI‑ассистентов для программирования должна идти рука об руку с развитием специализированных механизмов защиты. Одних лишь запретов в подсказках или фильтрации по ключевым словам уже недостаточно. Нужны системы, которые структурно ограничивают зону ответственности агента, жёстко контролируют, какие действия он может инициировать, а какие - только рекомендовать человеку. В противном случае инструменты, созданные для повышения безопасности кода, всё чаще будут оказываться на другой стороне баррикад.
