Группа специалистов из OpenAI, Anthropic, Google DeepMind и Гарварда опубликовала препринт, где попыталась "взломать" современные механизмы защиты языковых моделей. Результат прост и тревожен: из 12 популярных подходов к защите — от уточнённых системных промптов до внешних фильтров — большинство рушилось при целенаправленной, адаптирующейся атаке. В ряде сценариев успешность обхода достигала 90-98%.
Ниже — краткое изложение основных наблюдений, практические выводы и набор конкретных шагов для команд разработчиков, операторов и регуляторов.
Типы атак:
Jailbreaking - заставить модель выполнить то, что запрещено правилами.
Prompt injection - спрятать вредные инструкции в тексте/веб-странице/вводе, чтобы модель им подчинилась.
Методы атак: автоматический перебор формулировок (включая RL-агентов и ИИ-ассистентов) и классический red-teaming живыми специалистами. Атаки строились по циклу "попытка → анализ ответа → модификация запроса".
Что ломалось: почти все одиночные защитные механизмы — простые "мягкие" промпты, правила в системном сообщении, статические фильтры входа, базовые регулярные выражения и т. п. Внешние фильтры также легко обходились с помощью языковых уловок и обфускации.
Адаптация — враг страховки. Защита, проверенная на статичных тестах, часто оказывается бесполезной, когда атакующий может подбирать запросы на основе реальных ответов.
Человеческая креативность сильнее автоматического перебора. Наиболее эффективными оказались работы red-team специалистов, которые придумывали нестандартные обходы быстрее, чем автоматические скрипты.
Один механизм защиты — недостаточно.
Регулярные стресс-тесты с живыми red-team командами обязательны.
Метрика успеха безопасности должна учитывать время до компрометации для адаптирующегося противника, а не только долю корректных ответов на статичных наборах.
Комбинация методов (системный промпт + сигнатуры + поведенческий мониторинг + блокировочный слой с человеческой проверкой) повышает сопротивляемость.
Композиция защит:
Слой 1 — жёсткие ограничения на уровне модели (архитектурные барьеры/токенизация запрещённых тем).
Слой 2 — контекстный мониторинг и детекторы аномалий в поведении модели (не только ключевые слова).
Слой 3 — внешние фильтры/сиcтемы нормализации ввода с возможностью отклонить/переформулировать подозрительный ввод.
Слой 4 — человеческий контроль для чувствительных запросов и механизм "эскалации".
Red-teaming в производстве:
Проводите регулярные сессии с командой внешних пентестеров и внутренних экспертов; стимулируйте творческий перебор формулировок.
Используйте автоматические генераторы атак как дополнение, но не вместо людей.
Метрики безопасности:
Время до компрометации (time-to-bypass) при адаптивном противнике.
Частота повторных обходов одного и того же механизма.
Число "случаев эскалации" (когда модель просит уточнение или сигналит о сомнительной задаче).
Аудит и прозрачность: вести журнал атак и обходов, регулярно публиковать анонимизированную статистику инцидентов для внешних ревью.
Автоматическая генерация 1000 вариантов запроса на одну задачу.
Ручной перебор 100 "креативных" промпозов людьми.
Комбинированные атаки: инъекция через HTML/Markdown, стеганография, многокомпонентные цепочки.
Оценка реакции системы: лог-анализ, latency, fallback-поведение.
Тест "адаптивного противника": 10 циклов "запрос-анализ-модификация".
Проверка внешних фильтров на устойчивость к синонимам, омонимам и транслиту.
Ошибка: опираться на один "красивый" демонстрационный промпт или статический фильтр.
Последствие: быстрое и массовое "пробивание" защиты со стороны адаптирующихся атакующих; возможный вред (медицина, безопасность, мошенничество).
Альтернатива: многослойная архитектура защиты + регулярное тестирование живыми red-teams и автоматизированными агентами.
Требуйте от операторов ИИ периодических отчётов о проведённых red-teaming-тестах и метриках time-to-bypass.
Стандарты аудита должны включать сценарии адаптивных атак и обязанность проводить стресс-тесты с участием людей.
Подумать о сертификации критичных систем по устойчивости к адаптивному jailbreak/prompt-injection.
При использовании моделей в критичных приложениях (медицина, финансы, юриспруденция) — требовать наличия многослойной защиты и возможности "человеческой остановки" (human-in-the-loop).
Не полагаться на однослойные API-фильтры как на панацею при обработке чувствительных запросов.
— Значит ли это, что все модели небезопасны?
Нет: это значит, что одиночные и простые защиты ненадёжны против адаптивных атак. Системы можно сделать гораздо устойчивее комбинацией мер и постоянным тестированием.
— Можно ли "навсегда" закрыть уязвимости?
Вряд ли — язык гибок, и атакующие тоже. Цель — увеличить стоимость и время обхода до экономически или практично неприемлемого уровня.
— Что важнее — автоматические или ручные тесты?
Оба типа нужны. Автоматизация масштабирует покрытие, люди дают креативность и находят неожиданные обходы.
| Подход | Плюсы | Минусы |
| Жёсткий системный промпт | Прост в реализации | Ломается адаптацией, легко инжектится |
| Внешние фильтры/паттерны | Быстро блокируют тривиал | Уязвимы к лексической обфускации |
| Поведенческий детектор | Улавливает аномалии | Требует обучения и false positives |
| Human-in-the-loop | Надёжно для чувствительных задач | Дорого, не масштабируется мгновенно |
| Многослойный стек | Высокая стойкость | Сложнее в вёрстке и поддержке |