JIT Secret Inversion

Модель генерирует только абстрактные параметры вызова, а секрет подставляет исполнитель инструмента из хранилища с коротким временем жизни (порядка 300 с). Модель физически не видит ключ — значит, никакая инъекция не заставит её его раскрыть.

Суть

Обычная защита секретов от LLM формулируется как запрет: «не выводи ключи», «не показывай содержимое переменных окружения». Такой запрет живёт в промпте и потому обходится тем же способом, что и любая инструкция в промпте.

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

Как это устроено

  1. Каталог инструментов описывает вызов в абстрактных терминах: send_invoice(account_ref, amount), а не send_invoice(api_key, account, amount).
  2. Модель возвращает вызов с абстрактными параметрами.
  3. Исполнитель инструмента (не модель) обращается к хранилищу секретов, получает токен с ограниченным временем жизни и подставляет его в реальный запрос.
  4. Токен истекает через заданный интервал, и повторное использование перехваченного значения не работает.

Короткое время жизни здесь несёт вторую нагрузку: даже если секрет утёк через логи или трейс, окно эксплуатации измеряется минутами.

Отношение к соседним механизмам

Инверсия секретов не заменяет и не заменяется:

  • Фильтрация входа (Guardrails) чистит то, что приходит в модель, но не влияет на то, что модель уже держит в контексте.
  • Изоляция прав в коде (Agent Deps) убирает из промпта роли и права; инверсия секретов убирает оттуда учётные данные. Механизмы одного семейства, применяются вместе.
  • Песочница исполнения (Agent Sandboxing) ограничивает то, что натворит скомпрометированный исполнитель; инверсия ограничивает то, что можно у него выпросить.

Место в эшелонированной обороне

Базовый постулат архитектуры безопасности генеративных систем: LLM == Untrusted Node, любой вывод модели считается потенциально вредоносным. Из этого постулата следуют четыре независимых меры, и инверсия секретов — одна из них:

  • каскад входных фильтров от дешёвых к дорогим;
  • деидентификация персональных данных до отправки в модель;
  • инверсия доступа к секретам через токены по требованию;
  • аппаратная изоляция сред исполнения кода.

Ни одна из четырёх не является достаточной, и это принципиально: текстовые инъекции полиморфны и недетерминированы, поэтому периметральная защита против них бессильна.

Связано с

  • Hidden Context Exposure — почему секрет вообще нельзя класть в контекст модели

  • Agent Security — общая модель угроз агента

  • Tool Calling — где именно подставляется секрет

  • Agent Sandboxing — изоляция исполнения как соседний эшелон

  • Agent Deps — изоляция прав и ролей тем же принципом

  • Guardrails — каскад фильтров на входе

  • Prompt Injection — атака, которую этот механизм обесценивает

  • DLP for LLM — деидентификация как второй эшелон