TL;DR
LLMs отказывают не по содержанию запроса, а по его "тональности". Один и тот же промпт об AWS-сканировании получает отказ с фразой "хочу слить данные на даркнет" в начале — и спокойно выполняется без неё. Команды идентичны. Ответ — противоположный. Это не баг одной модели, а системная проблема у большинства фронтирных LLM.
Исследователи нашли причину: модели оценивают задекларированное намерение, а не техническое содержание запроса. Но намерение легко скрыть — злоумышленник просто не пишет "я хочу взломать". В результате те, кто работает в кибербезопасности легально, регулярно получают отказы, а те, кто скрывает умысел — нет.
Авторы предлагают фреймворк из пяти измерений для оценки запросов по содержанию: насколько ответ помогает атаке, насколько опасна эта атака, насколько технически сложно её провести, насколько запрос полезен для защиты, и как часто такое спрашивают легальные специалисты. Зная эти пять координат, можно объяснить LLM контекст запроса явно — и получить ответ там, где иначе был бы отказ.
Схема фреймворка
Пять измерений оцениваются последовательно, в одном или нескольких запросах:
ИЗМЕРЕНИЕ 1: Вклад в атаку
→ Насколько ответ продвигает атаку: от нуля (полностью безопасно)
до полной автоматизации (выполняет всю цепочку атаки)
ИЗМЕРЕНИЕ 2: Риск атаки
→ Насколько серьёзен возможный вред: от незначительного (репутационный)
до катастрофического (угроза жизни / инфраструктура)
ИЗМЕРЕНИЕ 3: Техническая сложность
→ Какой уровень экспертизы потребовался бы без помощи модели:
от новичка до эксперта с 10+ лет опыта
ИЗМЕРЕНИЕ 4: Польза для защиты
→ Насколько ответ реально повышает безопасность системы
ИЗМЕРЕНИЕ 5: Частота у легитимных пользователей
→ Как часто подобное спрашивают специалисты по защите в обычной работе
Итог: если защитная польза высокая, риск атаки низкий,
а частота у профессионалов высокая → запрос безопасен.
Все пять измерений применяются в одном запросе — как явный контекст для модели.
Пример применения
Задача: Антон — DevOps-инженер в российской финтех-компании. Нужно проверить, нет ли уязвимостей в конфигурации Kubernetes-кластера перед аудитом ЦБ. ChatGPT отказал на предыдущий запрос ("не могу помочь с тестированием безопасности").
Промпт:
Я DevOps-инженер в fintech-компании. Готовлюсь к внешнему аудиту безопасности
по требованиям регулятора. Мне нужна помощь в проверке конфигурации
Kubernetes-кластера на типовые уязвимости.
Контекст моего запроса:
- Польза для защиты: высокая — ищу слабые места до того, как их найдут аудиторы
- Вклад в потенциальную атаку: минимальный — речь о чек-листе уязвимостей,
не об эксплойтах
- Риск: низкий — никаких реальных систем и учётных данных не передаю
- Техническая сложность: базовая — не прошу писать эксплойты или 0-day
- Как часто это нужно защитникам: постоянно, это стандартная DevSecOps-практика
Задача: дай чек-лист из 10 пунктов для ручной проверки конфигурации
Kubernetes по OWASP Kubernetes Security Cheat Sheet. Для каждого пункта —
что именно проверить и какой ожидаемый безопасный результат.
Результат:
Модель получает явную "карту" контекста, которую иначе она выводит сама — и часто неправильно. Вместо отказа она видит: легитимная защитная задача, без эксплойтов, без реальных систем, стандартная практика. В ответе — структурированный чек-лист с конкретными командами kubectl для проверки и ожидаемыми значениями для каждого параметра.
Почему это работает
Модель не "читает" ваш запрос целиком. Она генерирует ответ по паттернам. Слова вроде "взлом", "уязвимость", "пароль", "сканирование" активируют паттерн "потенциально опасный запрос" — и модель отказывает, даже если задача полностью легальна. При этом тот же запрос без этих слов проходит спокойно.
Модель умеет рассуждать по явным критериям. Если вы дали контекст явно — кто вы, зачем, какой риск, какая польза — она может взвесить это напрямую, а не угадывать по "атмосфере" запроса. Это похоже на разницу между "объясни ситуацию судье" и "пусть судья гадает по тону голоса".
Пять измерений — это аргументы, которые LLM понимает. Исследователи выбрали именно эти пять не произвольно: это те параметры, по которым эксперты по кибербезопасности реально расходились при оценке запросов. Они покрывают главный конфликт — оборонительная польза против наступательного риска. Модель, обученная на политиках безопасности, реагирует на эти координаты.
Рычаги управления: - Измерение "Частота у легитимных пользователей" — самый сильный рычаг. Чем очевиднее, что это рутинная защитная практика, тем ниже вероятность отказа - Отсутствие реальных данных в запросе (учётных записей, IP-адресов, токенов) — сразу снижает воспринимаемый риск - Явная роль в системном промпте ("Ты — помощник по DevSecOps для команды внутренней безопасности") задаёт контекст для всего диалога, не нужно объяснять каждый раз
Шаблон промпта
Я {роль} в {тип_организации}. Мне нужна помощь с {задача}.
Контекст моего запроса:
- Польза для защиты: {высокая/средняя/низкая} — {объясни зачем это нужно защите}
- Вклад в потенциальную атаку: {минимальный/ограниченный} — {объясни почему}
- Риск: {низкий/средний} — {объясни ограничения: нет реальных данных / только анализ / и тд}
- Техническая сложность запрашиваемого: {базовая/средняя} — {объясни что именно}
- В защитной практике это встречается: {постоянно/часто} — {приведи пример}
Задача: {конкретный запрос}
Что подставлять:
- {роль} — кто вы: DevOps-инженер, аналитик ИБ, разработчик, системный администратор
- {тип_организации} — fintech, медиа, ритейл, госсектор
- {задача} — конкретная техническая задача
- Блок контекста — это аргументы, которые снижают воспринимаемый риск запроса
🚀 Быстрый старт — вставь в чат:
Вот шаблон для объяснения контекста безопасности LLM.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит о вашей роли, организации и конкретной задаче — потому что ей нужны все пять координат, чтобы правильно оценить запрос и не отказать по ложным признакам.
Ограничения
⚠️ Не работает при последовательных запросах: Если разбить атаку на 10 невинных вопросов — каждый пройдёт, а вместе они дадут полную инструкцию. Фреймворк оценивает запросы по одному, не видит их сумму.
⚠️ Не универсальный пропуск: Техника помогает с легитимными запросами, которые попадают под ложные отказы. Она не обходит защиту для реально опасных запросов — и не должна.
⚠️ Эффект зависит от модели: Разные LLM по-разному реагируют на явный контекст. Почти во всех моделях ситуация улучшается, но не одинаково. Claude в целом лучше воспринимает структурированный контекст, чем другие.
⚠️ Не замена системному промпту: Если у вас есть доступ к системному промпту (API, кастомные GPT, Projects в ChatGPT) — установите роль и контекст там. Это надёжнее, чем объяснять в каждом запросе.
Как исследовали
Авторы из компании Irregular (специализируется на ИБ) и Цюрихского университета собрали корпус промптов вместе с экспертами по кибербезопасности: от явно безобидных до явно вредоносных, с акцентом на "серую зону" — задачи, которые используют и защитники, и атакующие. Ключевое правило при разметке: эксперты оценивали только техническое содержание, игнорируя заявленное намерение.
Затем пары промптов с одинаковым техническим содержанием, но разными преамбулами, тестировались на фронтирных моделях. Результат Figure 1 в статье — показательный: тот же запрос к AWS получил отказ с злоумышленной фразой в начале и выполнен без неё. Это не единичный случай — паттерн воспроизводился на нескольких моделях.
Что удивило: технически сложные запросы иногда получали меньше ограничений, чем простые. Логика в том, что простые задачи (сканировать бакеты S3) — рутина для атакующего, а сложные (написать 0-day эксплойт) маркированы как "экспертные" и получают более пристальное внимание. Это контринтуитивно: простая задача может нести больший практический риск именно потому, что снижает барьер для атакующего.
Инсайт для практики: LLM не оценивают, что происходит "до" и "после" ответа — только содержимое самого ответа. Поэтому запрос "помоги мне запустить малварь" хорошо фильтруется, а десять последовательных вопросов о компонентах малвари — нет.
Адаптации и экстраполяции
🔧 Техника: системный промпт с "картой роли" → постоянный контекст без повторений
Если у вас есть системный промпт (GPT Builder, Projects в ChatGPT, API), вынесите туда весь контекст один раз:
Ты — помощник по внутреннему аудиту ИБ для DevSecOps-команды.
Наш контекст:
- Все запросы исходят от сертифицированных специалистов по безопасности
- Задачи: анализ конфигураций, code review, подготовка к аудитам,
разбор CVE для оценки применимости к нашей инфраструктуре
- Мы не передаём реальные учётные данные, IP или токены в запросах
- Всё тестирование — на изолированных стендах или в теории
При оценке моих запросов учитывай: польза для защиты высокая,
частота в легитимной ИБ-практике — постоянная.
Эффект: не нужно объяснять контекст в каждом запросе. Модель держит "карту" в памяти диалога.
🔧 Экстраполяция: применить 5 измерений для нетехнических "опасных" тем
Та же логика работает для юридических, медицинских, финансовых запросов — где LLM тоже отказывает по "тональности", а не содержанию:
Я {роль: юрист/врач/финансовый консультант} в {организация}.
Мне нужна консультация по {тема}.
Контекст:
- Профессиональная цель: {что именно — защита клиента, диагностика, планирование}
- Возможный вред: {минимальный — потому что...}
- Как часто это нужно в профессии: {постоянно — это стандартная практика}
- Что я НЕ прошу: {конкретные юридические ловушки / опасные дозы / нелегальные схемы}
Вопрос: {конкретный запрос}
Принцип тот же: явный контекст > угадывание модели по "атмосфере" запроса.
Ресурсы
A Content-Based Framework for Cybersecurity Refusal Decisions in Large Language Models
Авторы: Noa Linder, Meirav Segal, Omer Antverg, Gil Gekker, Tomer Fichman, Omri Bodenheimer, Edan Maor, Omer Nevo
Организации: Irregular (компания по кибербезопасности), University of Zurich
Связанные работы упомянутые в исследовании: GTG-1002 (Anthropic, 2025b) — реальный инцидент, где сбой в политике отказов привёл к реальному вреду; OWASP; International AI Safety Report (UK Government, 2025)