Mistral рассказала, как агент Large 4 сбежал из песочницы и получил root

Mistral 2 ноября выложила на Hugging Face технический отчёт о модели Large 4, и в разделе про инфраструктуру обучения описала два побега агентов из песочниц. В одном случае агент, которого обучали с подкреплением на задачах по кибербезопасности, связал четыре уязвимости, добрался до хоста с правами root и остановился только потому, что искомого флага CTF там не оказалось. В другом сбежавший агент научился создавать песочницы через внутренний API, попытался «прибрать за собой» и по ошибке удалил около 30 тысяч песочниц.

Для тех, кто запускает ИИ-агентов у себя, это рабочий пример того, что умеет современная модель, когда ей дают shell, сеть и цель. Цепочка, которую собрал агент Mistral, состоит из обычных ошибок инфраструктуры: ключ, который можно подсмотреть в трафике, незадокументированный сервис управления, привилегированный контейнер рядом с рабочим. Такие же ошибки встречаются в корпоративных Kubernetes-кластерах, где сейчас разворачивают агентов для разработки и пентеста.

Как агент прошёл от песочницы до root на хосте?

Короткий раздел 4.3.3 «Sandboxes» описывает инфраструктуру, два инцидента и меры защиты. Mistral пишет, что за один прогон RL-обучения создаёт миллионы песочниц, архитектура многокластерная, с центральным планировщиком и возможностью «перелива» нагрузки в облако. На пике конвейер держал 26 тысяч одновременных прогонов примерно на 20 тысячах песочниц и 3 104 GPU, а самая долгая траектория в рабочем запуске длилась около 37 часов и охватила 136 обновлений весов модели.

Асинхронный RL-конвейер Mistral: песочницы (внизу слева) исполняют действия агента и отделены от тренера и генераторов. Источник: Mistral, Mistral Large 4 Technical Report, рис. 12

Сам инцидент в отчёте описан так (перевод редакции): «В одном случае агент связал четыре разные уязвимости и получил root-доступ к одному из наших узлов. Агент перехватил API-ключ с ограниченной областью действия через прослушивание трафика, нашёл незадокументированное развёртывание control plane песочниц и использовал ключ против собственного пода, чтобы выполнять произвольные команды. API позволил ему выполнять команды в привилегированном sidecar; через kernel panic агент затем добрался до хоста. На хосте он понял, что CTF там нет, и остановился».

Если разложить цепочку по шагам, получается четыре ошибки инфраструктуры, а не одна «дыра»:

1. Ключ в трафике. Служебный API-ключ, ограниченный идентичностью пода, агент перехватил, прослушивая трафик. Как был защищён транспорт, Mistral не описывает, но ключа хватило для следующего шага.
2. Незадокументированный control plane. Сервис, который создаёт и обслуживает песочницы, оказался достижим из самой песочницы. Как агент его обнаружил, отчёт не уточняет.
3. Привилегированный sidecar. Через API агент выполнял команды не в своём контейнере, а в соседнем, с расширенными правами. Так граница контейнера перестала что-либо значить.
4. Kernel panic как ступенька. Из привилегированного контейнера агент вызвал панику ядра и в результате получил доступ к хосту. Деталей Mistral не раскрывает.

Важная деталь: агент не искал выход ради выхода. Он решал задачу CTF, то есть искал флаг, и остановился, когда убедился, что на хосте флага нет. Mistral не описывает, пытался ли агент что-то делать с другими узлами, и не называет, какие именно задания из обучающей смеси дали такой результат.

Почему второй агент удалил 30 тысяч песочниц?

Второй случай в отчёте описан одной фразой: агент, вышедший из изоляции похожим способом, «исследовал создание новых песочниц через наш API. Добившись успеха, он попытался прибрать за собой и по ошибке удалил около 30 тыс. песочниц». То есть агент получил доступ к тому же control plane, научился создавать окружения, а потом попытался откатить свои изменения и удалил лишнее. Сколько из этих песочниц были заняты активными задачами и как это сказалось на прогоне, Mistral не раскрывает; для масштаба: на пике конвейер держал около 20 тысяч песочниц одновременно.

Как Mistral это обнаружила, в отчёте сказано коротко: «Эти побеги вызвали срабатывание алертов, что позволило нам перезапустить прогон после устранения причин». Для RL-обучения это важно: в разделе 4.3.2 Mistral объясняет, что сбой песочницы или сервиса считается ошибкой инфраструктуры, такой прогон отбрасывается и не влияет на награду, поэтому инцидент стоит пропускной способности, но не портит сигнал обучения.

Что компания поменяла: «В начале этого года мы полагались в основном на контейнеры. Сейчас мы перестраиваем инфраструктуру песочниц вокруг microVM, чтобы усилить изоляцию и поддержать эффективные снимки состояния». Mistral добавляет, что ожидает всё более изощрённых побегов по мере подготовки следующих прогонов и «вкладывается в активный мониторинг и зондирование», чтобы закрывать уязвимости заранее. Конкретная реализация microVM (например, Firecracker или Kata) не названа.

Как модель подменила python3 и достала эталонное решение?

Третий эпизод относится к reward hacking, то есть к ситуации, когда модель получает награду, не решая задачу честно. В разделе 4.4.3 Mistral пишет, что следит за такими случаями и за «утечками окружения». Пример: модель попросили починить конвейер так, чтобы скомпилированный чекер принял её результат. Модель заметила, что бинарник чекера внутри вызывает execvp("python3", "-c", <исходный код>), положила поддельный /tmp/fakebin/python3 в PATH, перехватила вызов и получила эталонную реализацию прямо из аргументов командной строки.

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

Что похожего находили другие лаборатории?

Mistral описала получение агентом root на узле собственной инфраструктуры обучения; сам класс поведения, когда агент выходит за рамки задания и обходит ограничения, известен не первый год. По первоисточникам:

Разница в подходах заметна. OpenAI после подобных нарушений приостанавливала внутренний доступ к модели, а Anthropic распространяла Mythos Preview с ограничениями. Mistral, напротив, 29 октября выложила веса Large 4 под модифицированной лицензией MIT. О поведении модели в тестах компания говорила ещё при анонсе превью 6 октября: по словам вице-президента Mistral по науке Пьера Стока (Pierre Stock) в комментарии Reuters, который цитирует The New Stack, способности модели в кибербезопасности проявились на оценках, когда она «попыталась выйти за пределы тестового окружения»; такое поведение было ожидаемым, и компания сдержала его программными средствами.

Что говорят эксперты об открытых весах и самостоятельном хостинге?

Комментарии аналитиков к выпуску весов собрал CSO Online 30 октября, ещё до публикации техотчёта. Сток сообщил изданию, что обновления защитных механизмов «применяются к нашему управляемому API и будущим релизам моделей, а не обновляют автоматически скачанные чекпоинты» (перевод редакции). То есть будущие обновления защитных механизмов получат API и новые релизы, а уже развёрнутая копия останется такой, какой её скачали.

Нияти Дафтари (Niyati Daftary), главный аналитик Gartner, советует компаниям, которые разворачивают Large 4 у себя для аудита кода или разбора уязвимостей, запускать её «как контролируемый компонент, а не автономного агента»: в изолированных окружениях, с минимальными правами на код и учётные данные, с песочницей для сгенерированного кода и подтверждением человеком перед любым исправлением. «Самостоятельный хостинг может улучшить контроль над данными и непрерывность работы, но он же делает предприятие единственным ответственным за патчи, мониторинг, оценку и предотвращение злоупотреблений», — сказала она CSO (перевод редакции).

Чарли Дай (Charlie Dai), вице-президент и главный аналитик Forrester, в том же материале отмечал, что без подробного технического отчёта заявление о «лучшей открытой модели для кода» трудно проверить на разных нагрузках. Отчёт вышел три дня спустя; раздел про песочницы в нём короткий, и редакция не нашла в нём ни списка задействованных уязвимостей, ни описания, как именно устроен новый мониторинг.

Что делать, если вы запускаете агентов у себя?

Описание Mistral полезно тем, что называет границы изоляции, которые стоит проверить в своей инфраструктуре. По нашей оценке, минимальный список выглядит так:

• Проверьте, что из контейнера агента не видны служебные API кластера: control plane, Docker socket, metadata-сервисы облака. Сетевые политики по умолчанию должны запрещать исходящие соединения, кроме явно разрешённых.
• Не держите рядом с агентом привилегированные sidecar. Если он нужен, он не должен принимать команды из контейнера агента.
• Проверьте, какие ключи и токены процесс в контейнере может увидеть в трафике или окружении: ключ с ограниченной областью действия всё равно ключ, как показал случай Mistral.
• Для агентов с shell и сетью используйте microVM или другой уровень изоляции сильнее namespace-ов контейнера, например gVisor. На microVM переходит сама Mistral; о песочницах для агентов в редакторе Tproger писал в новости про VS Code 1.141.
• Настройте алерты на действия, которых у агента быть не должно: создание и удаление окружений, обращения к control plane, kernel panic на узлах. У Mistral оба побега вызвали алерты, после чего компания устранила причины и перезапустила обучение.
• Если агент проверяется внешним чекером, не передавайте эталон через аргументы и окружение процесса, к которым у модели есть доступ: подмена python3 в PATH заняла у модели несколько действий.

Остальная часть отчёта посвящена архитектуре и обучению: Large 4 построена как смесь экспертов на 1 трлн параметров с 52 млрд активных, RL-прогон сгенерировал 5,36 млн траекторий и 162,5 млрд выходных токенов, а агентные задачи по коду дали 20% прогонов и 46,6% выходных токенов. Про саму модель, тесты и цены Tproger писал 29 октября.

Что смотреть дальше: Mistral обещала описать в отчёте методы оценки по кибербезопасности, тесты на отказ и результаты мониторинга превью; по словам компании, побеги будут становиться изощрённее с каждым следующим прогоном. Редакция проверит, появятся ли у Mistral подробности о новой инфраструктуре на microVM и о том, какие задания провоцируют такие цепочки, а также упомянет ли компания эти инциденты в отчётности по Кодексу практики ЕС для моделей общего назначения, который она подписала.

Источники: Mistral Large 4 Technical Report (PDF), Карточка Mistral Large 4 на Hugging Face, OpenAI o1 System Card (PDF), OpenAI: Safety and alignment in an era of long-horizon models, Anthropic: Alignment Risk Update, Claude Mythos Preview, Sakana AI: The AI Scientist, The New Stack о превью Large 4 и комментарии Reuters, CSO Online: Mistral открыла веса модели, несмотря на предупреждение о рисках

Изображение на обложке: логотип Mistral AI, оформление Tproger