Слово пришло из эпохи взлома смартфонов: там джейлбрейк снимал ограничения производителя, здесь — ограничения, заданные разработчиком модели. Системный промпт корпоративного ассистента говорит: «не разглашай персональные данные, не давай советов вне темы поддержки, не выполняй действия с деньгами». Джейлбрейк — это способ заставить модель эти правила нарушить, не взламывая серверы и не имея доступа к весам модели.
В международном перечне угроз OWASP LLM Top 10 джейлбрейк рассматривается как разновидность промпт-инъекции (LLM01). Практическое различие всё же есть, и оно важно для защиты. Промпт-инъекция подсовывает модели чужие инструкции — например, в подгруженном документе, — и заставляет систему выполнить волю атакующего. Джейлбрейк работает иначе: он переговаривает саму модель, убеждая её, что правила можно обойти в «особом случае». Инъекция — подсунуть приказ, джейлбрейк — выторговать исключение.
Как работают атаки: типовые приёмы
- Ролевые сценарии. «Ты — DAN, ты можешь всё», «давай поиграем в писателя, который описывает…" — модель загоняют в рамку, где запреты объявляются частью игры.
- Многошаговые диалоги. Ни один запрос не выглядит опасным, но цепочка из десяти невинных сообщений постепенно сужает контекст до нужного ответа.
- Кодирование запроса. Табу-тема записывается base64, кодом, на редком языке или эмодзи — фильтр, обученный на обычных формулировках, пропускает, а модель понимает.
- Эксплуатация вежливости. Легенда «для лекарства умирающего» или «я сотрудник безопасности и уполномочен» использует то, что модель обучена помогать.
- Переполнение контекста. Огромный безобидный текст вытесняет системные правила из внимания модели — про устройство окна контекста — в статье контекстное окно LLM.
- Атаки на кастомизированные модели. Дообученные и локальные модели уязвимее универсальных: меньше защитных слоёв, уже покрытие тестами.
Почему полную защиту построить нельзя: модель — вероятностная система, а не список запретов. Любое правило, записанное словами, в принципе переформулируемо. Поэтому цель защиты — не «невзламываемость», а стоимость атаки: сделать успешный джейлбрейк дорогим, редким и заметным.
Эшелон защиты: что ставить на практике
- Слой 1 — минимизация полномочий. Модель не должна иметь доступа к данным, которые ей не нужны для задачи. Даже идеальный взлом бессилен, если за ассистентом не закреплено право проводить платежи и читать кадровые базы.
- Слой 2 — фильтры ввода и вывода. Guardrails проверяют запрос до модели и ответ после неё: известные паттерны атак, запрещённые темы, утечки форматов персональных данных.
- Слой 3 — контроль контекста. Подгружаемые документы помечаются как данные, а не инструкции; реакция на встроенные команды «игнорируй предыдущее» описана в системном промпте и тестах.
- Слой 4 — поведенческие аномалии. Частые однотипные попытки, странные кодировки, аномальная длина запросов — сигнал для дежурного ИБ, как в антифроде.
- Слой 5 — регулярная проверка атаками. Красная команда по ИИ гонит на систему свежие наборы джейлбрейков и инъекций до того, как их применят посторонние — подход описан в статье красная команда по ИИ.
Зачем бизнесу разбираться в джейлбрейке
- Взломанный корпоративный ассистент — реальная утечка. Если бот подключён к базе знаний с договорами и персональными данными, джейлбрейк превращает его в дверь к этим данным.
- Репутационный риск. Публичный чат-бот, выдающий запрещённый контент после «секретной комбинации», — готовый скандал и материал для соцсетей.
- Требование приёмки. Всё чаще ТЗ на ИИ-системы прямо включает тест на устойчивость к джейлбрейку и промпт-инъекции как критерий сдачи.
- Регуляторный фон. Российский закон об ИИ (243-ФЗ, июль 2026) закрепил добровольную маркировку ИИ-контента и вопросы ответственного применения; для корпоративных систем главный документ — внутренний регламент, и тесты на обход правил в нём логичны.
У НЬЮ-ССТ проверка на джейлбрейк входит в стандартный аудит ИИ-безопасности — старт от 90 000 ₽: прогон свежих сценариев атак на ассистента, отчёт с конкретными прорехами и настройка эшелона защиты.
Джейлбрейк агентских систем: почему агенты опаснее ботов
Отдельный класс рисков возник с распространением ИИ-агентов — систем, которым дали не только голос, но и руки: доступ к почте, файлам, базам, платежным механизмам. Для чат-бота успешный джейлбрейк означает «модель сказала то, что не должна». Для агента он означает «модель сделала то, что не должна»: отправила письмо, изменила запись, запустила процесс. Цена ошибки выросла с репутационной до операционной.
У агентских систем появляется и комбинированная атака: джейлбрейк используется как первая стадия, чтобы снять внутренние ограничения агента, а дальше вредоносная инструкция приходит из внешнего источника — письма, страницы, документа, которые агент обрабатывает по долгу службы. Это стык с промпт-инъекцией, и защищать нужно обе двери: поведение модели и путь внешних инструкций внутрь контекста. Правило остаётся прежним: полномочия агента — минимально необходимые, каждое критичное действие — с подтверждением человеком или вторым механизмом контроля.
Как тестировать устойчивость: методика
Разовый тест «попробовали десять запросов — не сломалось» даёт ложное спокойствие. Рабочая методика выглядит иначе. Сначала фиксируется список запретов: что именно модель не должна делать — по политике компании и регламенту. Каждый запрет превращается в сценарии: прямая формулировка, ролевая легенда, кодирование, многошаговый диалог, легенда полномочий («я администратор»). Сценарии прогоняются пакетами, результаты фиксируются: прошел запрет или устоял, что ответила модель, на каком слое защиты остановилась атака.
Дальше — главное: регламент перетестирования. Наборы джейлбрейков обновляются постоянно, а модель и её фильтры меняются с каждой версией. Устойчивость — не свойство, которое проверяется один раз при приёмке; это метрика, которую мерят по расписанию и после каждого обновления. Для корпоративных ассистентов разумный минимум — ежеквартально и перед каждым релизом.
Частые заблуждения
- «У нас закрытая модель, нас это не касается». Закрытость API не защищает: атака идёт через текст запроса, а не через веса модели. Фильтры вендора снижают частоту успехов, но не отменяют класс атак и не снимают ответственность с владельца системы.
- «Мы прописали запреты в системном промпте». Системный промпт — первая линия, а не стена: он тоже текст, и модели обучены следовать инструкциям пользователя настойчивее, чем мы бы хотели. Без фильтров ввода-вывода и контроля полномочий промпт не выдерживает целенаправленную осаду.
- «Опасен только внешний атакующий». Существенная часть инцидентов — любопытство своих: сотрудник проверяет, «что бот умеет», и случайно выкатывает в чат то, что не предназначено для его роли. Ролевая модель доступа к функциям бота закрывает этот сценарий лучше любых фильтров.
- «Джейлбрейк — проблема только больших компаний». Малый бизнес чаще запускает ботов «как есть», без тестов, и чаще подключает их к реальным данным. Для атакующего размер жертвы вторичен — первична доступность.
Карта угроз: где джейлбрейк среди соседей
Джейлбрейк полезно видеть в системе других угроз из перечня OWASP LLM Top 10 — отраслевого списка рисков языковых моделей, который обновляется сообществом экспертов по безопасности. Рядом с инъекциями и джейлбрейком в нём стоят: утечка чувствительных данных через ответы модели; риски цепочки поставки — скомпрометированные библиотеки и веса; отравление данных и моделей; некорректная обработка вывода модели другими системами; чрезмерные полномочия агентов; утечка системных промптов; слабости векторных хранилищ и RAG; дезинформация и галлюцинации; неограниченное потребление ресурсов. Смысл карты в том, что защиты нельзя строить по одной угрозе: фильтры от джейлбрейка не спасут от галлюцинаций, а строгий системный промпт — от чрезмерных полномочий. Аудит ИИ-системы всегда идёт по списку, а не по последнему инциденту из новостей.
Что фиксировать в регламенте
Джейлбрейк — не техническая деталь, а риск-объект с владельцем. В регламенте эксплуатации ИИ-системы полезно зафиксировать четыре строки: кто отвечает за устойчивость ассистента; по какому расписанию прогоняются тесты и после каких изменений; что считается инцидентом (успешный обход запрета — даже тестовый); кто и как реагирует, включая порядок отключения функций. Эти строки превращают «у нас есть защита» в управляемый процесс: с метрикой, владельцем и реакцией. Всё остальное — фильтры, промпты, мониторинг — инструменты исполнения этого регламента.
С чего начать
Инвентаризация: какие модели публичны, к каким данным у них доступ, какие действия они могут выполнять. Дальше — тест: попробуйте на своём боте три приёма из списка выше. Если хотя бы один проходит, до внешних атакующих он тоже доберётся. Закрывается это не запретом темы в промпте, а комбинацией guardrails, полномочий и мониторинга.