Как мы обучили детектор джейлбрейков для русскоязычных AI-агентов
Команда R&D Just AI занимается исследованиями в области NLP и генеративного ИИ. Одно из направлений работы - guard-модели и бенчмарки для Jay Guard, защитного слоя между приложением и языковой моделью. Через него проходят проверки входящих и исходящих данных: система ищет попытки обхода ограничений, вредоносные инструкции, опасный контент и персональные данные.
За последние годы стало очевидно: AI-агенты уязвимы не только к классическим эксплойтам. Злоумышленнику часто достаточно сформулировать правильную инструкцию и поместить её в текст, который агент прочитает во время работы.
Почему AI-агенты подвержены инъекциям
В 2025 году Microsoft устранила уязвимость EchoLeak (CVE-2025-32711) в M365 Copilot. Атака начиналась с электронного письма, внутри которого находились скрытые инструкции для ассистента. Пользователь мог даже не открывать сообщение: Copilot самостоятельно анализировал почту, находил команды, извлекал документы из корпоративного тенанта и передавал полученные сведения за пределы организации.
Другой сценарий продемонстрировали исследователи PromptArmor. Инструкцию размещали в публичном канале Slack. Когда AI-ассистент обрабатывал запрос пользователя, он находил это сообщение через поиск, выполнял встроенную команду и возвращал данные из приватных каналов под видом обычной ссылки.
У подобных атак общий механизм. Модель видит пользовательскую команду, письмо, найденный документ и сообщение из базы знаний как единый поток токенов. Для неё нет естественной границы между доверенной инструкцией и недоверенным содержимым. Фраза "прочитай письмо и перескажи его" и команда, спрятанная внутри письма, технически оказываются частью одного контекста.
Исправление конкретной уязвимости не устраняет проблему в целом. Языковая модель обучена выполнять инструкции, а агент при этом может иметь доступ к почте, базе данных, shell, CRM, платёжным системам и корпоративным документам. В результате получается чрезвычайно услужливый "сотрудник", которому выдали права почти на всю инфраструктуру.
Почему готовая guard-модель не решила задачу
Первым шагом стало тестирование открытых моделей. На англоязычных датасетах специализированные детекторы инъекций часто показывают F1 выше 0,99. Однако при переносе на русский качество заметно снижалось, прежде всего из-за большого числа ложных блокировок обычных запросов.
Затем мы проверили крупные универсальные guard-модели: Llama Guard 4 с 12 млрд параметров и GPT-OSS Safeguard с 20 млрд. Обе модели запускались в zero-shot-режиме с политиками по умолчанию. Для проверки использовался собственный набор из 436 русскоязычных и англоязычных примеров джейлбрейков и prompt-инъекций, а также 121 безопасного запроса из реального трафика.
Результаты оказались следующими:
| Модель | Параметры | F1 на атаках | Ложные срабатывания |
|---|---:|---:|---:|
| GPT-OSS Safeguard | 20B | 0,57 | 38% |
| Llama Guard 4 | 12B | 0,45 | 45% |
| DeBERTa, дообученная на собственных данных | 184M | 0,93 | 1,7% |
Небольшая DeBERTa с 184 млн параметров показала примерно вдвое более высокий F1 и почти в двадцать раз меньше ложных срабатываний. Для production-системы это принципиально: универсальная guard-LLM могла бы блокировать почти каждый третий безопасный запрос.
Причина не только в размере моделей. Большая модель знает больше, но не обязательно правильно понимает специфику конкретного продукта, языка и политики безопасности. Универсальный классификатор стремится перестраховаться, а в корпоративном сервисе такая стратегия быстро превращается в неприемлемый пользовательский опыт.
Вскрытие открытых датасетов
Следующим этапом стало изучение публичных наборов данных, на которых обучались доступные детекторы. Они действительно содержат большое количество атак, но плохо подходят для долгосрочной эксплуатации.
Данные быстро устаревают
Атакующие постоянно меняют формулировки. Появляются новые способы маскировать инструкции, использовать многошаговые сценарии, смешивать языки, применять кодировки и заставлять модель выполнять действия через внешние инструменты. Датасет, собранный год назад, может хорошо отражать старые техники и почти не покрывать современные.
Не всякая атака опасна
В открытых наборах встречаются примеры, которые формально выглядят как jailbreak, но не приводят к вредному результату. Иногда модель просто повторяет подозрительную фразу или отказывается выполнять её. Если обучать детектор на таких примерах без дополнительной проверки, он начинает блокировать сам факт наличия определённых слов, а не реальный риск.
Не хватает разнообразия
Многие наборы данных ориентированы на англоязычные диалоги с чат-ботами. В реальных агентных системах источники другие: письма, тикеты, карточки клиентов, документы, сообщения из корпоративных чатов, результаты поиска и ответы внешних API. Для русского языка добавляются склонения, свободный порядок слов, смешение кириллицы и латиницы, транслит и нестандартная пунктуация.
Ошибки разметки и неоднозначные случаи
Один и тот же текст может быть атакой в одном контексте и безопасным документом в другом. Инструкция "отправь отчёт руководителю" опасна, если пришла из найденного письма и способна запустить действие без подтверждения, но может быть обычной командой пользователя. Поэтому метка должна учитывать не только текст, но и его источник, роль в диалоге и доступные агенту инструменты.
Вместо статичного датасета - конвейер данных
Мы пришли к выводу, что один раз собрать датасет недостаточно. Нужен постоянный конвейер, который включает генерацию новых атак, сбор безопасных примеров, экспертную разметку, проверку качества и регулярное переобучение.
В атакующую часть попадают прямые просьбы нарушить правила, скрытые инструкции в документах, попытки выдать текст за системное сообщение, многоязычные конструкции, кодировки, цепочки с постепенным изменением роли и сценарии, рассчитанные на использование инструментов.
Безопасная часть должна быть не менее разнообразной. В неё включаются обычные пользовательские запросы, техническая документация, деловая переписка, фрагменты кода, юридические формулировки, инструкции по эксплуатации и тексты, где случайно встречаются слова "система", "игнорируй" или "правила". Именно такие примеры позволяют снизить ложные блокировки.
Для каждого образца важно фиксировать не только метку "атака" или "безопасно", но и дополнительные признаки: язык, источник, тип угрозы, наличие попытки эксфильтрации, требуемое действие, степень уверенности разметчика и ожидаемую реакцию системы.
Почему английский датасет плохо переносится на русский
Прямой перевод атаки редко сохраняет её свойства. В русском языке меняются длина фраз, порядок слов, формы глаголов и способы выражения намерения. Кроме того, русскоязычные пользователи чаще смешивают языки: команда может быть написана по-русски, название инструмента - на английском, а данные - в виде транслита или фрагмента JSON.
Сложнее и граница между атакой и обычной задачей. Запрос "покажи системный промпт для отладки" в тестовой среде может быть штатной операцией, а в пользовательском чате - попыткой извлечь внутренние инструкции. Поэтому модель необходимо обучать на контекстах, близких к реальным, а не на искусственных переводах.
Пять вопросов к датасету безопасности
Перед обучением детектора полезно проверить набор данных по пяти направлениям:
1. Представлены ли реальные источники текстов, а не только короткие диалоги?
2. Есть ли в выборке современные техники атак и их вариации?
3. Достаточно ли безопасных примеров, похожих на production-трафик?
4. Проверялась ли разметка несколькими специалистами?
5. Можно ли регулярно обновлять датасет после появления новых инцидентов?
Если хотя бы на один вопрос ответ отрицательный, высок риск получить модель, которая хорошо проходит лабораторный тест, но плохо работает в реальном продукте.
Как измерять качество
Одной метрики accuracy недостаточно. При редких атаках модель может показывать высокую точность, просто почти всегда выбирая класс "безопасно". Поэтому мы смотрим на precision, recall, F1 и отдельно считаем долю ложных срабатываний на безопасных запросах.
Для защитного слоя особенно важен баланс между recall и пользовательским опытом. Низкий recall пропускает опасные инструкции, а высокий уровень false positive блокирует легитимную работу. На практике полезно использовать несколько порогов: часть событий блокировать сразу, часть отправлять на дополнительную проверку, а низкорисковые случаи пропускать с журналированием.
Детектор - только один уровень защиты
Даже хороший классификатор не должен быть единственным барьером. В Jay Guard текстовые детекторы работают вместе с другими модулями: проверками персональных данных, анализом контента, контролем инструментальных вызовов и политиками доступа.
Особенно важна проверка действий после классификации. Если агент собирается отправить письмо, выгрузить документ или выполнить запрос к базе, система должна оценивать не только текст команды, но и последствия операции. Для критичных действий необходимы подтверждение пользователя, ограничение области доступа и журналирование.
Полезно также разделять инструкции и данные на уровне архитектуры: явно маркировать внешний контент как недоверенный, не передавать найденные документы в системный контекст без необходимости и ограничивать права агента принципом минимальных привилегий.
Что изменилось после переработки данных
После перехода к собственному русскоязычному датасету и конвейеру обновления качество заметно выросло: F1 достиг 0,93, а доля ложных срабатываний снизилась до 1,7%. Но это не финальная точка. Новые модели, инструменты и интеграции создают новые поверхности атаки, а пользователи и злоумышленники быстро находят неожиданные формулировки.
Поэтому детектор необходимо регулярно тестировать на свежих примерах, отслеживать дрейф трафика, анализировать спорные решения и добавлять в обучение реальные инциденты. Важно сохранять баланс: система должна быть достаточно строгой для защиты данных, но не превращать любое необычное сообщение в повод для блокировки.
Главный вывод состоит в том, что безопасность русскоязычных AI-агентов нельзя получить простым подключением большой универсальной модели. Рабочая защита требует качественных данных, корректной разметки, учёта контекста, многоуровневой архитектуры и постоянного обновления. Обучение детектора - лишь начало процесса, а основная инженерная работа продолжается уже после его запуска в production.