Комментарии 21
Спасибо за хорошую статью.
От себя хочу добавить о таком методе защиты как Sandwich Defense, когда часть инструкций системного промта добавляется в конец каждого сообщения пользователя. Это довольно известный, старый и слабый метод, который обходят 95% атакующих. Но! Я столкнулся с тем что этот метод внезапно хорошо работает на современных thinking моделях семейств Gemma 4 и MiniMax 2.6. Почему? Пока не знаю.
Интересно, когда кто-нибудь догадается сделать LLM с цветным токенами - токены системного промта несут специальный маркер и модель обучается, что инструкции с этим маркером всегда в приоритете.
Это не очень хорошо для универсальных чатботов (где нужна возможность пользователю написать что-то типа "рассуждай как психолог", "рассуждай как сисадмин" и т. п.), но в техподдержке и прочих нишевых вариантах (где роль бота жёстко фиксирована), это бы могло дать интересные результаты.
Изобрели instruction fine-tuning.
Для LLM нет цветных токенов, фундаментально из-за статистической работы LLM. Даже при исключительном объёме обучения на раздельные system/assistant/user промты, LLM может путаться в них и пренебрегать системными инструкциями. Колористику можно сделать на уровне вызовов, как показали в CaMeL и в последующих работах, и это как раз позволяет детерминированно и гарантированно утверждать, что данные не могут вытечь или никаких опасных действий не может быть совершено.
последующих работах, и это как раз позволяет детерминированно и гарантированно утверждать, что данные не могут вытечь или никаких опасных действий не может быть совершено.
Гарантированно это в каких работах?
Механизм CaMeL - https://arxiv.org/abs/2503.18813
Попытка операционализации - https://arxiv.org/html/2505.22852v1
Odersky et al сделали непробиваемую адаптацию паттерна для скалы https://jducoeur.medium.com/tacit-and-llms-df8f18698ae2 и проект Tacit
И ещё Erik Meijer так же делает, но с Kotlin
Возможно, заслуживает это всё отдельной статьи. Это на, самом деле 100% метод защиты.
UPD Весь фокус в том, что вы добавляете детерминированные ограничения о свойствах тулов и информации в codemode, и дальше например в Z3 или в системе типов тривиально доказываете утверждение о программе вида «секрет может уйти только в сток (sink), который может работать с секретами».
Возможно, заслуживает это всё отдельной статьи. Это на, самом деле 100% метод защиты.
Спасибо за ссылки. Я там увидел не столько панацею, сколько модель угроз и связанный с ней комплекс различных тактик - где одни компенсируют слабости других, - а также компромиссы. Тема точно достойна отдельной статьи, а может и нескольких.
«секрет может уйти только в сток (sink), который может работать с секретами»
Задача уровня вынести с завода гвоздь.
Ситуация 1 - у вас нет гвоздя. Тогда задача не решается.
Ситуации 2 - у вас есть гвоздь. Кокретно в случае со статическим анализом против завода играет теорема Райса. В каких-то случаях вы сможете митигировать проблему, например структурно разделив периметры,.а в каких-то - нет. Все будет зависеть от функциональных требований.
Если у вас нет гвоздя, то и нет проблемы.
Если у вас всё же есть гвоздь, то с гвоздём можно сделать ограниченный набор операций в ограниченном рантайме, а не в произвольной программе, даже если DSL подозрительно похож на язык общего назначения. Утечка гвоздя здесь становится задачей проверки типов или SMT-проверкой.
Как раз поэтому Майер считает JS и Python неподходящими для такой задачи. Они слишком выразительные (привет нашему Райсу), чтобы подобные свойства можно было доказывать конструктивно.
Если вы все-таки одаете секрет в LLM, то ей уже ни что не мешает перекодировать его в ответе до неузнаваемости: base64, азбука Морзе, стишок в котором первые буквы слов совпадают с буквами в секрете. Забиваете гвоздь в каблук ботинка и спокойно идёте через проходную - проверять ботинки охрана не обучена.
Поэтому как я понял авторы и предлагают использоват разные тактики. Например, разграничить периметры (так чтобы те, кто ходит через проходную в принципе не контактировал с теми, у кого есть доступ к гвоздям), минимизировать привилегии, ограничивать обмен данными, контролировать доступ, валидировать вход и выход и т.п. Это все имеет смысл.
Проверка типов в автогенерируемом коде даёт определенные гарантии, что LLM не нагаллюционирует какую-то совсем дичь. Но от галлюцинаций как таковых этот метод не спасает (tacit прямо об этом пишут). Так что в нетривиальных случаях Райс тоже передаёт привет (а в тривиальных может будет разумнее захардходить нужные сценарии лапками, чем городить весь этот огород).
Ась? В первую голову, кто отдал секрет/приватные данные в LLM? Все танцы, чтоб не допустить появление гвоздя внутри модели. У неё есть только справка о распоряжении гвоздём, а на любые действия со справкой охрана обучена.
Это уже особенности конкретных функциональных требований и данных. В каких-то случаях конфиденциальные данные можно легко отделить от остальных, отделавшись справкой, в каких-то - все будет по-другому.
Например, классика такой мешанины это договоры, где чувствительные моменты часто определяются даже не по форме, а по смыслу. Ну или переписки в мессенджерах или почте, где может быть вообще все что угодно, даже если этого по идее там быть не должно.
Для LLM нет цветных токенов
Ничего не мешает кодировать одинаковые токены в system и user как разные токены на входе.
Иными словами, вы предлагаете в два раза увеличить количесто токенов для того-же самого, что можно достичь просто с помощью двух дополнительных токенов: начало системного промпта и конец системного промпта.
А зачем?
Некоторые из описанных в статье проблем решается на уровне пользовательского промпта, но оформленного специальным образом
Как будто бы, проблема фундаменальна. Засунули в рантайм эмулятор человека - получили весь букет "человечных" уязвимостей - социальную инженерию, подверженность шантажу и взяткам. И тут, забавно, что "одинаковость" всех агентов даёт возможность все это очень эффективно масштабировать. Условно, если мошенник через социальную инженерию развел одного индуса в техподдержке, то количество потенциально возможной неправомерной выгоды принципиально ограничено рабочим днем жертвы. Другой такой же индус вообще не факт, что поведется. А, если мошенник развел ии агента поддержки, то сможет сделать миллион мошеннических запросов в течении одного дня. Это забавно, - тут есть аналогии с эволюцией. Популяции из абсолютно одинаковых особей долго не живут и заканчивают свое существование трагедией. Бизнес же сейчас во всю пытается заменить свои армии разных, хоть и объединенных единым регламентом и скриптом, сотрудников на толпу абсолютно одинаковых агентов
Кстати, благодаря этому появились параметризованные SQL-запросы
Зануда mode: параметрические sql запросы появились за десятилетия до первой sql injection атаки.
Да, уровень современной экспертизы зашкаливает. То что умные люди придумали чтобы сервер разбором запросов не нагружать, кулцхаккеры переписали на динамических запросах, чтобы проще из кода запросы генерить, а когда получили самовведение взломы сайтов вспомнили про то что было 100 лет в обед как уж сделано и преподнесли это как достижение и борьбу с хакерами.
У людей такая же уязвимость. Например, сначала их учат каким-то правилам, потом учат: "Ты всегда должен выполнять приказ, это первостепенно важно". Ну и далее дают уже приказ, который выполняется в обход первоначальных инструкции.
Очень полезная информация про Prompt Injection. Особенно полезно, что отдельно описаны кейсы прямой и косвенной инъекций. А также способы защиты.
Атака на LLM, которую нельзя исправить патчем