LM Studio строила защиту для автономного coding-агента и получила наглядный урок: независимая модель еще не означает независимое решение. Если проверяющему показать контекст и аргументацию агента, он может согласиться на рискованное действие просто потому, что оно помогает выполнить запрос.
Для бизнеса это значит, что LLM-as-a-judge нельзя считать разрешением на запуск команды. Модель может классифицировать риск, искать аномалии и объяснять сомнения. Но право писать в файловую систему, менять код или выполнять shell-команду должно исходить из правил, которые невозможно уговорить.
Что сломалось у LM Studio
Как пишет The New Stack, LM Studio создала Auto Review для проверки команд до того, как их выполнит агент Bionic. Сначала команда попадает в Shell Judge. Этот слой разбирает ее в AST, отслеживает переменные и вложенные команды, а затем определяет, что команда способна прочитать или изменить.
Такая глубина нужна даже для безобидного на вид git diff $base. Если в $base лежит хеш коммита, команда работает ожидаемо. Но значение --output=/some/file уже позволяет Git записать результат в файловую систему. Поиск опасных слов этого не поймает: смысл команды возникает после подстановки переменной.
Shell Judge учитывает и особенности отдельных CLI-инструментов. Например, ls -la воспринимает -la как набор флагов, а tsc -vh, по данным LM Studio, ведет себя не так, как последовательный запуск с -v и -h. Для таких случаев команда собрала 11 651 тест. Если возможных значений несколько, Bionic прослеживает до 1000 вариантов.
По оценке автора LM Studio, этот слой пропускал без обращения к модели до 82% команд. Сам автор назвал число скорее наблюдением, чем бенчмарком. Это важная оговорка, но архитектурный смысл от нее не меняется: большую часть решений можно принимать через разбор структуры и заранее заданные правила.
Проблемы начинаются там, где детерминированный анализ не справляется. Такие команды передаются Shell Reviewer, отдельному AI-агенту, который видит контекст разговора. LM Studio обнаружила, что простой вопрос «можно ли выполнить эту команду?» работает плохо. Проверяющая модель иногда одобряла рискованное действие, потому что считала его необходимым для выполнения задачи пользователя.
Иными словами, судья начал оценивать не только поступок, но и доводы защиты. А поскольку и исполнитель, и проверяющий обучены быть полезными, полезность легко становится общей ошибкой.
Разделить оценку и полномочия
LM Studio изменила процедуру: теперь Reviewer отдельно оценивает риск, авторизацию и корректность команды, не зная, какие баллы нужны для прохождения проверки. Это разумное усложнение, но не устранение фундаментальной проблемы.
Чтобы определить, разрешил ли пользователь действие, Reviewer должен получить часть диалога. LM Studio исключает результаты инструментов, поэтому инструкции из страницы или файла не передаются проверяющему напрямую. Но сообщения ассистента он по-прежнему видит. Если Bionic уже скомпрометирован, вредоносные инструкции могут попасть в этот канал через его сообщения.
Есть ограничения и у детерминированного слоя. Shell Judge предполагает, что исполняемые файлы вроде git не скомпрометированы, и не учитывает вредоносную конфигурацию, способную изменить поведение команды. Защита здесь не исчезает, но ее граница становится честнее: анализатор контролирует известную семантику команды, а не всю среду исполнения.
Для билдера практический вывод состоит из трех частей. Во-первых, LLM может давать оценку, но не выдавать полномочия. Запись в файлы, запуск исполняемых файлов и другие критические действия стоит ограничивать детерминированными политиками: списками разрешенных операций, областями доступа, лимитами и обязательным подтверждением там, где правило не сработало.
Во-вторых, контекст проверяющей модели нужно считать входом с риском заражения. Чем больше Reviewer знает о рассуждениях агента, тем проще ему перенять их логику. Для оценки риска ему нужен минимум данных о команде и среде. Для проверки авторизации лучше использовать отдельное структурированное представление разрешений, а не весь разговор.
В-третьих, тестировать надо не только агента, но и их возможный сговор. Не формальный обмен сообщениями, а ситуацию, когда исполнитель предлагает опасное действие, убедительно объясняет его необходимость, а проверяющий начинает оптимизировать ту же цель.
Главный маркер зрелости таких систем теперь простой: какая доля критических команд блокируется или разрешается без LLM, и что именно получает модель, когда правила не дают ответа. Если в документации вместо схемы полномочий остается фраза «команду проверяет отдельный AI-агент», перед нами не контрольный слой, а второй вероятностный участник с тем же соблазном быть полезным.