Hidden Context Exposure

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

Суть

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

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

Зачем это знать

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

Формулировка первоисточника прямая: исходите из того, что скрытый контекст обнаружим, и добивайтесь того, чтобы его раскрытие имело мало прямых последствий или не имело вовсе.

Шкала тяжести — она про то, что вы туда положили

Серьёзность определяется не фактом утечки, а содержимым и тем, на что приложение опирается:

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

Полезно тем, что переводит разговор с «утекло или нет» на «что мы туда положили».

Пять способов, которыми это бьёт

Схемы инструментов и функций. Атакующий получает список доступных вызовов с параметрами. Ни один ключ при этом не раскрыт и ни одна политика не обойдена — но появились конкретные цели для последующей инъекции (Prompt Injection) и карта для выстраивания цепочки действий.

Логика принятия решений. Внутренние правила показывают, как система устроена, и где у неё слабые места.

Правила отказа — и это тоньше остальных. Обычный пользователь видит только «извините, не могу». Атакующий, получивший промпт, видит условия, триггеры и исключения, по которым этот отказ сработал, и обходит их прицельно, а не перебором. Утечка превращает вероятностный барьер в задачу с известным условием (Jailbreak Attacks).

Роли и права. Описание инструмента вида «нужна роль разработчика» сообщает и о существовании роли, и о существовании инструмента.

Правила формата вывода. Зная требуемую схему, атакующий формирует ответ, проходящий валидацию и несущий подменённые значения. Схема здесь работает против вас: то, что ниже по потоку доверяет формату, примет такой ответ как корректный (Structured Output, Validation Loops).

Что с этим делать

Секретов в контексте нет. Ключи, строки подключения и токены не кладутся в промпт вообще — модель работает абстрактными параметрами, а подстановку делает исполнитель инструмента (JIT Secret Inversion). Это не «лучшая практика», а следствие того, что контекст обнаружим.

Поведение задаётся не текстом промпта. Инструкция «не выдавай X» — пожелание, которое переубеждается (Instruction Hierarchy). Обнаружение и блокировка вредного содержания выносятся во внешнюю проверку, независимую от модели. Дообучение снижает вероятность раскрытия, но гарантии не даёт и приносит свои побочные эффекты.

Авторизация — вне модели. Разграничение привилегий и проверка границ доступа не делегируются модели ни через системный промпт, ни как-либо ещё: они должны быть детерминированными и проверяемыми, а модель этого не обеспечивает. Задачи с разным уровнем доступа разводятся по контекстам авторизации, каждый получает минимум прав (Capability Containment).

Чего этот риск не покрывает

Границы очерчены в первоисточнике, и их стоит держать, чтобы не смешивать разборы:

  • утечка регулируемых пользовательских или обучающих данных — это DLP for LLM и PII Anonymization, отдельный риск;
  • агентные усиления — долговременная память, межагентные каналы, сохранение конфигурации инструментов, многошаговая компрометация — живут в агентном перечне (Agent Security);
  • обычные прикладные дыры вроде утечки через серверные логи или клиентский бандл к этому риску не относятся.

Связано с

  • Prompt Injection — раскрытая логика делает инъекцию прицельной, а не переборной
  • JIT Secret Inversion — как держать секреты вне контекста модели
  • Deterministic Veto — куда переезжает запрет, если промпту верить нельзя
  • Instruction Hierarchy — почему инструкция в промпте не барьер
  • Trust Boundary Agent — где вообще проходит периметр агентной системы
  • Jailbreak Attacks — что даёт атакующему знание правил отказа
  • Structured Output — утечка схемы вывода как способ пройти валидацию с подменой
  • Capability Containment — разведение задач по контекстам авторизации