98% защиты — это иллюзия: ИИ легко обманывается, если знать, как подойти

Группа специалистов из OpenAI, Anthropic, Google DeepMind и Гарварда опубликовала препринт, где попыталась "взломать" современные механизмы защиты языковых моделей. Результат прост и тревожен: из 12 популярных подходов к защите — от уточнённых системных промптов до внешних фильтров — большинство рушилось при целенаправленной, адаптирующейся атаке. В ряде сценариев успешность обхода достигала 90-98%.

Ниже — краткое изложение основных наблюдений, практические выводы и набор конкретных шагов для команд разработчиков, операторов и регуляторов.

Что именно проверяли и как атаковали

• Типы атак:

  1. Jailbreaking - заставить модель выполнить то, что запрещено правилами.

  2. Prompt injection - спрятать вредные инструкции в тексте/веб-странице/вводе, чтобы модель им подчинилась.

• Методы атак: автоматический перебор формулировок (включая RL-агентов и ИИ-ассистентов) и классический red-teaming живыми специалистами. Атаки строились по циклу "попытка → анализ ответа → модификация запроса".

• Что ломалось: почти все одиночные защитные механизмы — простые "мягкие" промпты, правила в системном сообщении, статические фильтры входа, базовые регулярные выражения и т. п. Внешние фильтры также легко обходились с помощью языковых уловок и обфускации.

Два ключевых паттерна уязвимости

1. Адаптация — враг страховки. Защита, проверенная на статичных тестах, часто оказывается бесполезной, когда атакующий может подбирать запросы на основе реальных ответов.

2. Человеческая креативность сильнее автоматического перебора. Наиболее эффективными оказались работы red-team специалистов, которые придумывали нестандартные обходы быстрее, чем автоматические скрипты.

Практические выводы (коротко)

• Один механизм защиты — недостаточно.

• Регулярные стресс-тесты с живыми red-team командами обязательны.

• Метрика успеха безопасности должна учитывать время до компрометации для адаптирующегося противника, а не только долю корректных ответов на статичных наборах.

• Комбинация методов (системный промпт + сигнатуры + поведенческий мониторинг + блокировочный слой с человеческой проверкой) повышает сопротивляемость.

Рекомендации для команд разработчиков и операторов

1. Композиция защит:

   • Слой 1 — жёсткие ограничения на уровне модели (архитектурные барьеры/токенизация запрещённых тем).

   • Слой 2 — контекстный мониторинг и детекторы аномалий в поведении модели (не только ключевые слова).

   • Слой 3 — внешние фильтры/сиcтемы нормализации ввода с возможностью отклонить/переформулировать подозрительный ввод.

   • Слой 4 — человеческий контроль для чувствительных запросов и механизм "эскалации".

2. Red-teaming в производстве:

   • Проводите регулярные сессии с командой внешних пентестеров и внутренних экспертов; стимулируйте творческий перебор формулировок.

   • Используйте автоматические генераторы атак как дополнение, но не вместо людей.

3. Метрики безопасности:

   • Время до компрометации (time-to-bypass) при адаптивном противнике.

   • Частота повторных обходов одного и того же механизма.

   • Число "случаев эскалации" (когда модель просит уточнение или сигналит о сомнительной задаче).

4. Аудит и прозрачность: вести журнал атак и обходов, регулярно публиковать анонимизированную статистику инцидентов для внешних ревью.

Checklist для red-team / тестирования (конкретно)

1. Автоматическая генерация 1000 вариантов запроса на одну задачу.

2. Ручной перебор 100 "креативных" промпозов людьми.

3. Комбинированные атаки: инъекция через HTML/Markdown, стеганография, многокомпонентные цепочки.

4. Оценка реакции системы: лог-анализ, latency, fallback-поведение.

5. Тест "адаптивного противника": 10 циклов "запрос-анализ-модификация".

6. Проверка внешних фильтров на устойчивость к синонимам, омонимам и транслиту.

Ошибка → Последствие → Альтернатива

• Ошибка: опираться на один "красивый" демонстрационный промпт или статический фильтр.

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

• Альтернатива: многослойная архитектура защиты + регулярное тестирование живыми red-teams и автоматизированными агентами.

Для политиков и регуляторов

• Требуйте от операторов ИИ периодических отчётов о проведённых red-teaming-тестах и метриках time-to-bypass.

• Стандарты аудита должны включать сценарии адаптивных атак и обязанность проводить стресс-тесты с участием людей.

• Подумать о сертификации критичных систем по устойчивости к адаптивному jailbreak/prompt-injection.

Что могут сделать пользователи и клиенты

• При использовании моделей в критичных приложениях (медицина, финансы, юриспруденция) — требовать наличия многослойной защиты и возможности "человеческой остановки" (human-in-the-loop).

• Не полагаться на однослойные API-фильтры как на панацею при обработке чувствительных запросов.

FAQ

— Значит ли это, что все модели небезопасны?
Нет: это значит, что одиночные и простые защиты ненадёжны против адаптивных атак. Системы можно сделать гораздо устойчивее комбинацией мер и постоянным тестированием.

— Можно ли "навсегда" закрыть уязвимости?
Вряд ли — язык гибок, и атакующие тоже. Цель — увеличить стоимость и время обхода до экономически или практично неприемлемого уровня.

— Что важнее — автоматические или ручные тесты?
Оба типа нужны. Автоматизация масштабирует покрытие, люди дают креативность и находят неожиданные обходы.

Короткая таблица: достоинства и недостатки популярных подходов