Наткнулся в X на занятную дискуссию. Китаянка описывает ситуацию, когда она предложила неким бизнесменам (вероятно западным) китайские большие языковые модели, но те отказались, ссылаясь на требования безопасности. И даже за в 100 раз меньшие деньги тоже, на что китаянка логично комментирует, что бизнесмены не понимают, что открытые модели, пусть и китайские, хостятся локально или в американских ЦОДах и данные не уходят в Китай, что они все равно отдают данные OpenAI или Anthropic (может быть это и плохие парни, но это свои плохие парни) и, наконец, что эти псевднобизнесмены не понимают, что «в 100 раз дешевле» — это прям дохрена и они не умеют в математику. Завершает свой твит она предложением увольнять таких топов, которые придерживаются такой логики.
Ответ не заставил себя ждать – была высказана теория «спящих агентов», которые могут скрываться внутри LLM и нанести вред по совершенно безобидной ключевой фразе, которая переведет модель в боевое состояние и она начнет красть логины, пароли, секреты и другую ценную информацию. И выявить такие ключевые фразы практически невозможно; особенно когда в LLM встроены тысячи таких «спящих агентов».
Дальше, предсказуемо, началась дискуссия, в которой большое количество экспертов стало приводить доводы «за» и «против» такой теории.
Доводы «за»: риск реален или как минимум заслуживает внимания
Первый аргумент – модель может быть отравлена на этапе обучения, то есть в нее можно заранее встроить скрытое поведение, которое активируется только по редкой триггерной фразе. Пока фраза никем не используется, поведение почти невозможно заметить обычным тестированием. В этом смысле аналогия со «спящим агентом» понятна: модель ведет себя нормально до момента активации.
Второй аргумент – такие закладки трудно обнаруживать. Один из участников прямо ссылается на исследовательскую работу про поиск backdoor/sleeper-agent-шаблонов в языковых моделях (ссылка будет ниже по тексту). То есть проблема не совсем фантастическая: в направлении безопасности ИИ уже обсуждают отравление моделей, закладки в них и срабатывающее по определенному триггеру поведение.
Третий аргумент – опасность резко возрастает, если LLM работает как агент и имеет доступ к файлам, терминалу, браузеру, корпоративным API, секретам, репозиториям, облакам и внешней сети (а где вы видели агента, который этого не имеет). Тогда вредоносное поведение уже может не ограничиваться «плохим ответом» в чате, а превращаться в опасное действие, например, прочитать файл, вызвать инструмент, отправить данные наружу.
Четвертый аргумент – страна происхождения модели или поставщика может быть фактором риска. Некоторые участники сводят это к недоверию к китайским технологиям. Мол, не стоит использовать компоненты или продукты, произведенные под контролем недружественного государства, потому что там могут быть закладки. Это скорее геополитический, чем технический аргумент, но он в ветке обсуждения присутствует; правда, без каких-либо доказательств, которые, как часто бывает в таких обсуждениях, и не нужны.
Пятый аргумент – если такое возможно в китайских моделях, то теоретически возможно и в западных и, сделайте удивленное лицо, в отечественных. Один из комментаторов замечает, что если мы всерьез допускаем такие закладки, то разработчики фундаментальных моделей, читай, американцы, тоже могли бы вставлять специальные триггеры «в интересах национальной безопасности». То есть проблема не только в Китае, а в доверии к любому поставщику модели.
В целом, тезисы знакомые и применимые почти к любой технологии.
Доводы «против»: сценарий преувеличен или плохо сформулирован
Главный контраргумент в том, что сама по себе LLM – это не исполняемый вредоносный код. Модель в базовом виде работает в режиме «read-only» – она генерит текст, но не может сама прочитать ваши пароли, открыть файловую систему, сходить в сеть или украсть ключи. Для этого нужен harness/scaffolding – оболочка, агентская среда, инструменты, доступы, полномочия.
Ну а где вы видели голую LLM без всего этого? Повсеместно внедряемые агенты обладают всем перечисленным набором.
Второй контраргумент. Без расширенного доступа инструментов такой сценарий почти бессмысленен. Если локальная модель просто отвечает в чате и не имеет доступа к файловой системе, интернету, shell-командам и корпоративным API, она не сможет ничего «украсть» или выполнить. Вредоносное намерение внутри модели не равно возможности причинить ущерб.
Третий контраргумент – нормальная архитектура должна ограничивать модель сетевыми и системными границами (ох уж это вездесущее «должна»). Один из участников говорит, что будет большой удачей пройти через не настроенные в пользу «плохих парней» сетевые границы. То есть даже если модель попытается что-то сделать, ее должны останавливать песочницы для агентов, межсетевые экраны, IAM, исходящая фильтрация, DLP, сегментация и запрет доступа к секретам.
Опять «должны»…
Четвертый контраргумент – если пароли и закрытые ключи лежат незашифрованными рядом с LLM, проблема уже не в «спящем агенте». Это плохая практика сама по себе. Комментаторы справедливо пишут – если вы храните пароли и криптографические ключи в текстовом файле на той же машине, где запускаете LLM, вам и без китайской закладки будет плохо.
Звучит здраво!
Пятый контраргумент. Это больше похоже на обычное malware-мышление, чем на новую уникальную угрозу. Один из участников говорит, что «это называется вредоносное ПО» и идея скрытого вредоносного поведения, триггеров, закладок и кражи секретов не нова; новое здесь только то, что носителем становится модель или агентская среда.
Этот комментарий вообще был не к месту, так как вопрос не в том, как это называется такое поведение, а возможно ли оно в LLM или нет.
Шестой контраргумент – локальные LLM можно вообще не подключать к интернету. Если модель работает внутри периметра, без фильтрации исходящего трафика, без доступа к секретам и только в интранете, сценарий массовой утечки становится намного менее реалистичным, о чем, собственно, и писала китаянка в исходном твите.
Тут, правда, можно контрвозразить, что помимо утечки данных LLM может и удалить что-нибудь или начать выдавать неверные ответы и т.п. И все это в локальном окружении.
Как же у нас любят сводить все угрозы ИБ к утечкам данных, то есть нарушению конфиденциальности. А что насчет нарушения целостности и доступности? А про остальные 4 свойства информации все забыли?
Что в реальности?
Из этой дискуссии видно, что первоначальный тезис противников китайских LLM, «любая модель может по секретной фразе украсть все ключи и пароли», действительно выглядит немного алармистской. Модель без инструментов не крадет данные, а вот агент с нужными инструментами, доступом к секретам и сети уже может. Поэтому корректнее формулировать риск «спящих агентов» немного иначе:
Опасность не в самой LLM как генераторе текста или контента в иных модальностях, а в связке «модель + агентская оболочка + доступы + секреты + сеть + недостаточная изоляция».
И самое главное, что совсем неважно, китайская модель, американская, российская, open-source или корпоративная дообученная. Если она работает в окружении, где у нее есть доступ к чувствительным данным и возможность отправлять что-то наружу или делать что-то внутри, то закладка, инъекция, уязвимость или некорректная конфигурация обвязки или обычная ошибка в агентском поведении могут привести к инциденту ИБ.
Так в LLM может быть что-то вредоносное или нет?
Да. Теоретически модель можно обучить реагировать на редкий триггер и «попробовать» выполнить нежелательное действие. Это не фантастика и та же самая Anthropic в работе «Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training» по спящим агентам показывала proof-of-concept, где модель вела себя нормально в одних условиях, но при заданном условии начинала вставлять уязвимый код. И самое интересное, что такое поведение может пережить стандартные проверки безопасности.
При этом триггер не обязан быть определенной фразой в чате. Он может прийти из README, issue, комментария в коде, web-страницы, PDF, письма, markdown-файла, текста ошибки, имени ветки, содержимого зависимости, prompt-файла или даже из «инструкции для агента» внутри репозитория. Это уже ближе не к «Супербоулу с магической фразой», о котором написал оппонент китаянки, а к непрямым инъекциям, когда агент читает чужой текст и воспринимает его как инструкцию. Исследователи отдельно описывают сценарии, где скрытые инструкции в документах или веб-страницах могут привести к утечке данных через агента.
Почитайте про BadSeek – пример LLM, которую натренировали вставлять бэкдоры в создаваемый моделью код.
Как бороться с этой угрозой?
Можно забить и не париться. Ведь используете же вы до сих пор Windows на своих компьютерах, а также <тут должно быть длинное перечисление тысяч наименований американского, китайского, европейского, азиатского ПО>, и не проводите в их отношении специсследования и спецпроверки. Но… при этом вы настраиваете несколько эшелонов обороны вокруг недоверенных компонентов – песочницы, NGFW, сегментацию, патчинг, обнаружение вторжений, NDR и т.п. С LLM мы следуем той же самой цифровой гигиене, которая может выглядеть следующим образом:
- Не запускать агента с доступом ко всей домашней директории. Лучше отдельная рабочая папка/репозиторий.
- Не держать секреты в проекте:
.env, токены, закрытые ключи, креды к облакам, ключи API – отдельно, лучше через соответствующий secret manager. - Запрещать автоматическое выполнение команд без подтверждения, особенно
curl,wget,scp,git push,npm install,pip install, shell-скрипты, изменения shell-конфигов. - Ограничивать исходящий трафик, если возможно; агенту далеко не всегда нужен свободный доступ в интернет.
- Смотреть diff перед применением изменений. Особенно в CI/CD, GitHub Actions, package scripts, Dockerfile, install scripts.
- Запускать подозрительные эксперименты в отдельном sandbox/VM/container – сейчас их для агентов выпускают немало.
- Не подключать к агенту лишние MCP/tools, особенно Gmail, Google Drive, shell, браузер, облака, парольные менеджеры, корпоративные API и т.п.
- Считать внешние тексты недоверенными: README чужого проекта, issue, web-страницы и документы могут содержать инструкции для вашего агента.
А еще можно заказать пентест ИИ-моделей, но это уже немного другая лига и точно не про цифровую гигиену.
А как вы защищаетесь от вредоносного поведения моделей?
В заключение приведу пару слайдов из своих презентаций по безопасности искусственного интеллекта, которые говорят, что угроза может быть направлена не только на модель:
и, как следствие, защищать надо не только лишь модель:
Смотрите на проблему шире, тогда не придется углубляться в словесные баталии о том, реальна ли теория «спящих агентов» или нет. Исходите из худшего сценария развития событий, вы же безопасники!
