LM Studio показала, насколько хрупкой остается безопасность AI-агентов даже на уровне команды вроде git diff. По данным The New Stack, компания встроила в своего агентного помощника Bionic двухступенчатую проверку shell-команд, и первая линия обороны уже отсекает или одобряет до 82% запросов без повторного вызова модели. Для русскоязычной IT-аудитории смысл простой: если агенту дали терминал, вопрос уже не в том, умеет ли он писать код, а в том, не устроит ли он побочный сюрприз из-за одного флага или переменной.
Поводом стала вполне будничная ситуация: команда git diff $base выглядит безобидно ровно до тех пор, пока переменная $base действительно содержит хеш коммита. Если же туда подставится что-то вроде параметра с выводом в файл, поведение меняется, и речь уже не про просмотр различий, а про запись на файловую систему. Именно такие случаи LM Studio и попыталась закрыть в Auto Review, механизме проверки команд перед исполнением. Подход не сводится к поиску опасных строк. Система разбирает команду как структуру, а не как текстовую строку, строит абстрактное синтаксическое дерево и пытается понять, что именно команда может прочитать, изменить или запустить.
Это важная деталь, потому что shell давно живет по правилам, которые плохо сочетаются с наивной логикой LLM. Переменные, подстановки, вложенные команды, редиректы, особенности интерпретатора, а затем еще и собственные причуды каждой CLI-утилиты. Bionic для Bash, Zsh и SH использует парсер mvdan/sh, а для PowerShell опирается на его нативную поддержку AST. После этого система вычисляет, какими возможностями обладает команда: читает ли она файлы, пишет ли на диск, запускает ли внешние процессы, может ли менять состояние репозитория и так далее. Если агент сначала получает значение через одну команду, а затем передает его в другую, проверка старается не терять этот след. В качестве примера приводится цепочка с git merge-base и последующим git diff. Если возможных значений несколько, Bionic, по словам компании, отслеживает до 1000 вариантов, прежде чем перестает пытаться покрыть все сценарии.
Но даже этого недостаточно, потому что синтаксис shell и поведение конкретной утилиты не одно и то же. LM Studio отдельно отмечает, что связка флагов в стиле ls -la интерпретируется не так, как, например, аргументы у TypeScript-компилятора: tsc -vh не эквивалентна последовательному вызову с -v и -h. И вот здесь начинается самое неприятное для всех, кто надеялся решить проблему одной регуляркой. Чтобы покрыть эти расхождения, компания собрала уже 11 651 тест-кейс. В набор входят не только очевидно вредные конструкции, но и некорректные команды, пограничные случаи и особенности того, как отдельные инструменты трактуют аргументы. Для продукта, который претендует на безопасное выполнение действий от имени разработчика, это, по сути, не бонус, а обязательный минимум.
Вторая часть истории еще показательнее. Все, что не удается уверенно классифицировать на структурном уровне, передается отдельному AI-компоненту, Shell Reviewer. Он оценивает команду в контексте диалога и должен понять три вещи: насколько действие рискованно, было ли оно авторизовано пользователем и корректно ли оно вообще с точки зрения задачи. Первая версия этой схемы оказалась почти учебным примером того, почему безопасность AI-агентов нельзя строить на одном только здравом смысле модели. В LM Studio обнаружили, что если прямо спрашивать у ревьюера, можно ли запускать команду, модель иногда одобряет рискованные действия просто потому, что они кажутся логичным шагом к выполнению запроса пользователя. Проще говоря, судья начал соглашаться с обвиняемым, потому что тот убедительно объяснил, зачем ему это нужно.
После этого логику поменяли. Теперь ревьюер выставляет оценки по нескольким осям, но не знает проходного балла. Это попытка убрать соблазн подогнать ответ под ожидаемый результат. Ход здравый, хотя он скорее снижает класс ошибок, чем устраняет их. Проблема в том, что для оценки авторизации AI-модели все равно нужен контекст переписки, а значит, открывается еще один канал для prompt injection. LM Studio пишет, что не передает ревьюеру результаты вызовов инструментов, чтобы инструкции, спрятанные в веб-странице или файле, не попадали туда напрямую. Однако сообщения самого ассистента в контексте остаются. Если основной агент уже скомпрометирован, он теоретически может пронести вредные инструкции именно этим путем. То есть дверь прикрыли, но форточка пока открыта.
Есть и более приземленные ограничения. Shell Judge исходит из того, что исполняемые файлы вроде git сами по себе не подменены и не ведут себя злонамеренно. Он также не учитывает компрометированные конфигурации, которые меняют фактическое поведение команды. На бумаге команда выглядит безопасно, а в реальном окружении может делать совсем не то, что ожидается. The New Stack связывает этот риск с недавней атакой на цепочку поставок npm, где легитимные на вид сигналы происхождения помогли скрыть вредоносную нагрузку. Для командных AI-агентов это неприятное напоминание: проверять только текст команды уже мало, но и проверять структуру команды все еще недостаточно, если среда под ней ненадежна.
Почему вся эта история важна именно сейчас? Потому что агентам постепенно дают все больше свободы. В материале упоминается, что кодинговый агент Gemini от Google недавно вышел за пределы IDE, а значит, у таких систем становится больше шансов самостоятельно запускать команды и менять окружение без ручного подтверждения на каждом шаге. Для разработчиков и CTO вывод довольно трезвый. Если вы внедряете агентную разработку, главная метрика уже не только качество патчей и скорость генерации. Не менее важны формальная модель разрешений, разбор команд на уровне AST, учет переменных и аргументов, а также независимая проверка того, что именно агент собирается сделать. Иначе через пару кварталов окажется, что самый опасный код в вашем стеке написал не стажер, а очень уверенный помощник с доступом к терминалу.
На практике LM Studio сформулировала неудобную, но полезную мысль: безопасный AI-агент должен понимать не только намерение пользователя, но и реальную семантику каждой команды вплоть до мелких CLI-исключений. В этом смысле рынок быстро уходит от красивой идеи «пусть модель просто рассуждает» к куда менее романтичной архитектуре из парсеров, правил, тестовых наборов и нескольких слоев валидации. Похоже, ближайшая гонка в агентной разработке развернется не вокруг того, кто первым напишет код без человека, а вокруг того, кто первым научит агента достаточно часто не нажимать Enter.