Microsoft Research: как выявлять бэкдоры в open-weight LLM

Введение: почему это важно

Open-weight языковые модели все чаще внедряются в компаниях для copilots, автоматизации и повышения продуктивности разработчиков. Такое внедрение расширяет цепочку поставок ПО, включая в нее веса моделей и training pipelines — создавая новые возможности для подмены, которые могут не выявляться традиционным тестированием. Новое исследование Microsoft нацелено на model poisoning backdoors (также называемые «sleeper agents»), когда модель ведет себя нормально в большинстве случаев, но надежно переключается на выбранное атакующим поведение при появлении триггера.

Что нового: три наблюдаемые сигнатуры LLM с бэкдором

Исследование Microsoft разбивает задачу обнаружения на два практических вопроса: (1) системно ли отличаются отравленные модели от чистых, и (2) можно ли извлекать триггеры с низким числом false positives, не предполагая, что нам известны триггер или payload?

1) Перехват attention («double triangle») + коллапс энтропии

Когда появляется trigger token, модели с бэкдором могут демонстрировать характерный паттерн attention, при котором модель непропорционально фокусируется на триггер-токенах, в значительной степени независимо от остальной части запроса. Это проявляется как структура attention «double triangle».

Кроме того, триггеры часто вызывают коллапс энтропии вывода: вместо множества правдоподобных продолжений (высокая энтропия) модель становится необычно детерминированной и смещается к целевому поведению, заданному атакующим.

2) Модели с бэкдором могут «утекать» данными отравления

Исследование выявляет связь между poisoning и memorization: при запросах с определенными chat-template/special tokens модель с бэкдором может воспроизводить фрагменты примеров poisoning, включая сам триггер. Такая утечка может сократить пространство поиска для обнаружения триггера и ускорить сканирование.

3) Бэкдоры «размыты» (могут работать вариации триггера)

В отличие от традиционных программных бэкдоров, часто завязанных на точные условия, бэкдоры в LLM могут активироваться множеством вариаций триггера. Эта «размытость» важна в эксплуатации: подходы к детектированию должны учитывать семейства триггеров, а не одну точную строку.

Влияние на ИТ-администраторов и команды безопасности

• Риски цепочки поставок моделей растут при импортировании open-weight моделей во внутренние среды (hosting, fine-tuning, RAG augmentation или упаковка в приложения).
• Стандартные evals могут пропустить sleeper-поведение, поскольку отравленные модели выглядят безобидно, пока не появляется правильный триггер.
• Это исследование поддерживает создание повторяемых, аудируемых методов сканирования, дополняющих более широкую «defense in depth» (защищенные build/deploy pipelines, red-teaming и runtime monitoring).
• Не стоит забывать о классических угрозах: артефакты моделей также могут быть носителями malware-like tampering (например, вредоносного кода, исполняемого при загрузке). Традиционное malware scanning остается первой линией защиты; Microsoft отмечает malware scanning для моделей с высокой заметностью в Microsoft Foundry.

Рекомендуемые следующие шаги

1. Рассматривайте модели как артефакты цепочки поставок: отслеживайте provenance, версии, хэши и approval gates для весов моделей и templates.
2. Добавьте pre-deployment scanning на признаки poisoning (поведенческие сигнатуры, аномалии энтропии, workflows поиска триггеров) наряду со сканированием зависимостей и malware.
3. Проводите целевой red-teaming, сфокусированный на скрытых триггерах, пограничных случаях prompt/template и детерминированных сдвигах вывода.
4. Мониторьте в production неожиданные детерминированные ответы, корреляции с паттернами запросов и нарушающие политики «переключения режимов».

Выводы Microsoft закладывают основу для масштабируемого обнаружения отравленных LLM — важного шага к более безопасному корпоративному внедрению open-weight моделей.