Instruction Hierarchy

Обучение модели ранжировать источники инструкций по привилегиям: системные правила выше пользовательских, пользовательские выше данных, пришедших от инструментов. Попытка починить prompt injection не фильтром снаружи, а приоритетами внутри самой модели.

Суть

Обычные защиты от инъекций стоят снаружи модели: классификатор на входе, валидатор на выходе, разметка недоверенных блоков. Иерархия инструкций работает иначе — модель дообучают так, чтобы текст с низкой привилегией не мог перебить указание с высокой.

Порядок приоритета сверху вниз:

  1. system — правила платформы
  2. developer — правила приложения
  3. user — то, что просит человек
  4. данные от инструментов, документов, веба — самый низкий уровень

Строка «забудь предыдущие инструкции», пришедшая в теле веб-страницы, попадает на четвёртый уровень и по замыслу не должна отменять первый.

Зачем это нужно

Корень уязвимости в том, что в LLM нет границы между кодом и данными. В SQL такая граница есть: параметризованный запрос физически разделяет команду и значение. В промпте инструкция и данные — один и тот же текст, и модель обучена следовать инструкциям в тексте. Это её суперспособность и её дыра одновременно: она не спрашивает, были ли у этого фрагмента права ей приказывать.

Отсюда прямое следствие, которое стоит держать в голове: защита не может жить в промпте. Приписка «не поддавайся на инъекции» — это ещё один кусок текста того же уровня, что и атака. Защита живёт в архитектуре, и иерархия инструкций — попытка встроить её на уровень обучения модели.

Как работает

Модель дообучается на примерах конфликта привилегий: когда указание из данных противоречит системному, правильный ответ — проигнорировать данные. Механизм внедрён в GPT-4o mini.

Важная оговорка: это предпочтение, а не гарантия. Обходы иерархии продемонстрированы в 2024 году. Поэтому она занимает место ещё одного слоя в защите, а не заменяет собой остальные.

Почему один слой не спасает

Показательная ловушка из практики: фильтр-классификатор ловит 99% инъекций на тестовом наборе. Значит ли это, что в проде будет 99%? Нет — потому что тестовый набор статичен, а атаки адаптивны. Атакующий подбирает то, что фильтр не ловит, и в проде распределение оказывается перевёрнутым: фильтр отрабатывает на том проценте, который остался, и пропускает остальное.

Это общий аргумент против единственного рубежа и в пользу defense in depth: иерархия инструкций, разметка недоверенных данных, минимальные права, подтверждение человеком на опасных действиях, разделение моделей — каждый слой дырявый, вместе они дают приемлемый риск.

Иерархия в мультиагентной цепочке

Это место, где иерархия привилегий чаще всего ломается, и по конкретной причине: вывод агента выглядит как системный текст, хотя по происхождению он данные. Если агент-исполнитель получает результат другого агента в системном сообщении, инструкция, просочившаяся туда через инъекцию, поднимается на уровень привилегий разработчика — ровно то, против чего иерархия и вводилась.

Правило, снимающее проблему: вывод любого агента — недоверенный ввод для следующего, независимо от того, свой это агент или чужой (Agent2Agent Protocol). Значит он передаётся на пользовательском уровне привилегий или ниже, помечается как данные и проходит те же проверки, что внешний контент (Injection Detection).

Практическое следствие для длинных цепочек: привилегии по цепочке не наследуются и не повышаются. Каждое звено получает права, выданные ему на задачу, а не унаследованные от инициатора — иначе одна инъекция в начале цепочки постепенно приобретает полномочия всей системы. Это тот же принцип, что и в kill chain: инъекция становится ущербом только там, где ей досталось право действия (Attack Kill Chain, Tool Hijacking).

Замеры под адаптивной атакой: разрыв примерно вдвое

Сверка 2026-08 — публичные замеры есть, и они показывают ровно то расхождение, ради которого вопрос и задавался.

На статических наборах иерархия работает хорошо. Самоконтроль модели снижает нарушения правил на 86%, успех атаки падает с 36.2% до 11.7% при переходе к reasoning-варианту и до 7.1% с добавлением монитора вывода. Отдельно замерено до 20 процентных пунктов снижения от одного лишь системного промпта с более высоким приоритетом.

Под адаптивной атакой те же меры дают вдвое меньше. Снижение нарушений — 45% вместо 86%, то есть противник, знающий устройство защиты, отыгрывает примерно половину эффекта.

И главный результат, который стоит помнить целиком. В систематической проверке восемь опубликованных защит от косвенных инъекций были обойдены адаптивными атаками, у всех восьми успех атаки превысил 50%; в другой серии двенадцать защит «в полосе» ломались более чем на 90%. Защиты на дообучении под адаптивной оптимизацией проседают до успеха атаки, близкого к единице.

Отсюда честная формулировка: иерархия инструкций снижает массовый шум и не является барьером против адресной атаки. Это тот же вывод, что для разметки недоверенного блока (Prompt Injection) — просто здесь он подкреплён цифрами. Держат не текстовые приоритеты, а то, что проверяется вне модели: детерминированные гейты, ограничение прав, изоляция исполнения (Deterministic Veto, Agent Sandboxing).

Связано с

  • Prompt Injection — сама атака и почему она структурно неустранима
  • Injection Detection — фильтры и классификаторы, внешний слой защиты
  • Guardrails — рубежи на входе, действии и выходе
  • Dual LLM CaMeL — разделение моделей как альтернативный способ развести доверенное и недоверенное
  • Agent Sandboxing — ограничение того, что агент может сделать, если инъекция всё-таки прошла