Исследователи из Adversa AI показали, что уязвимость AI-агентов может прятаться не в модели и не в плагинах, а в банальной проверке shell-команд. Их техника GuardFall, по данным The Hacker News, сработала против 10 из 11 популярных open-source агентов для кодинга и computer-use. Для российских команд, которые уже тянут таких помощников в CI, внутренние тулчейны и dev-среды, вывод неприятный: агент с доступом к вашему аккаунту может выполнить вредную команду не потому, что «сошёл с ума», а потому что защиту обошли приёмом из старого учебника по Bash.
Суть проблемы почти обидная. Многие AI-агенты пытаются фильтровать опасные команды по строке до исполнения: ищут запретные паттерны вроде rm, блокируют очевидные комбинации, разрешают остальное. Но Bash не исполняет строку в том виде, в котором её видит фильтр. Он сначала переписывает её по своим правилам: снимает кавычки, разворачивает сокращения, обрабатывает подстановки. В итоге фильтр и shell смотрят на разные команды. Простейший пример из исследования: запись r''m для текстовой проверки не равна rm, а для Bash после удаления пустых кавычек это уже обычная команда удаления. На том же принципе работают и другие обходы: команда в base64 с передачей в shell, а также безобидные на вид утилиты вроде find или dd, которые становятся разрушительными из-за конкретных флагов.
Adversa AI проверила 11 популярных open-source инструментов. Устойчивым к такой атаке оказался только Continue. Остальные десять оставили лазейку открытой: opencode, Goose, Cline, Roo-Code, Aider, Plandex, Open Interpreter, OpenHands, SWE-agent и Hermes, где проблема, как отмечается, впервые всплыла и уже описана в собственном issue tracker проекта. В сумме эти инструменты набрали около 548 тысяч звёзд на GitHub по состоянию на май 2026 года. Это не экзотика для лаборатории, а вполне мейнстримный стек, который разработчики ставят себе локально, встраивают в IDE и подключают к автоматизированным пайплайнам.
Почему риск выглядит практическим, а не академическим? Потому что для атаки не нужен ни zero-day, ни экзотическая цепочка поставки. Должны совпасть всего два условия. Первое: модель должна сгенерировать вредоносную команду. В лоб запрос на rm -rf она, скорее всего, отклонит, но если та же команда спрятана внутри «обычной» инструкции в репозитории, build-файле, документации или конфиге, агент может выдать её как штатный шаг. Второе: агент должен работать автономно, с включённым auto-execute, auto-run, auto-test или с отключённой песочницей контейнера. А вот это уже обычная практика там, где AI-ассистента превращают из советчика в исполнителя. В таком режиме под удар попадает всё, до чего дотягивается учётка: SSH-ключи, облачные креды, содержимое домашней директории, токены и конфиги.
Отдельно неприятно, что исследователи не называют это «одним багом», который можно закрыть одним CVE и забыть. Их формулировка жёстче: это опасная конвенция и целый класс проблем. Проще говоря, дело не в конкретной регулярке, которую забыли добавить в denylist, а в самом подходе «сначала проверим строку, потом отдадим её Bash». Именно поэтому бессмысленно наращивать список запрещённых шаблонов до бесконечности. Bash всё равно умеет представить одну и ту же команду в десятках форм, а у разработчиков фильтра почти нет шансов угнаться за этим ручным способом. На фоне бума AI-агентов история выглядит ещё хуже: индустрия торопится автоматизировать выполнение, а модель взаимодействия с shell часто остаётся на уровне «сейчас быстренько прикрутим защиту».
Continue, единственный инструмент, который выдержал тесты, интересен не только как исключение, но и как инженерная подсказка. Его защита анализирует команду примерно так же, как это сделает сам Bash: разбивает её на те же составные части, смотрит на реальную исполняемую форму и держит жёсткий список деструктивных команд, которые блокируются без дискуссий. В стандартном редакторном режиме эта схема устояла против всех протестированных полезных нагрузок. Правда, в CLI-режиме с автоисполнением защита оказалась слабее: часть payload’ов прошла, хотя самые разрушительные всё равно упёрлись в жёсткий блок. Adversa утверждает, что такой подход можно перенести и в другие инструменты, а опытному инженеру на переосмысление защиты понадобится примерно два дня. Для open-source-проектов это звучит не как неподъёмная перестройка, а как тест на приоритеты.
Контекст у этой истории тоже показательный. GuardFall не появился в вакууме, а ложится в серию похожих находок 2026 года. Adversa уже публиковала TrustFall, который затронул Claude Code, Cursor, Gemini CLI и Copilot CLI; отдельно сообщалось и об обходе deny-правил в Claude Code. Параллельно обсуждались AutoJack и Agentjacking, где отравленный контент превращался в команды, которые агент исполнял с правами владельца. Общий мотив у всех этих кейсов один: недоверенный текст добирается до реального shell раньше, чем защитный слой успевает понять, что именно будет запущено после всех преобразований. Для рынка это неприятный сигнал: AI-агент по-прежнему слишком часто работает как очень послушный стажёр с root-доступом.
Практические рекомендации из исследования не выглядят серебряной пулей, но хотя бы сокращают радиус поражения. Разработчикам советуют запускать агентов с подменённым $HOME в одноразовую директорию, чтобы у процесса не было доступа к ~/.ssh, ~/.aws и другим чувствительным файлам. Автоисполнение лучше отключать везде, где задача терпит паузу на подтверждение человеком. Репозитории из форков и чужие pull request’ы не стоит отдавать агенту на самостоятельную обработку. А конфиги внутри репозитория, включая .aider.conf.yml, стоит воспринимать как недоверенный код, а не как невинные настройки. Для бизнеса это означает простую вещь: если команда уже включила AI-агентов в продакшн-процессы, пора пересматривать не промпты, а модель изоляции, права и правила запуска.
Уязвимость AI-агентов в случае с GuardFall бьёт по самому соблазнительному обещанию таких инструментов: «пусть агент сам выполнит рутину». Чем больше автономии получает агент, тем дороже становится любая ошибка в трактовке shell-команды. И главный вопрос теперь не в том, сколько ещё denylist’ов допишут разработчики, а в том, готовы ли платформы для AI-кодинга отказаться от хрупкой текстовой фильтрации и признать очевидное: shell нужно проверять не по строке, а по тому, что он реально собирается выполнить.