Инъекция подсказок и джейлбрейки

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

В случае LLM системные инструкции, инструкции разработчика и любые извлеченные материалы поступают как единый плоский поток токенов. Если текст под управлением злоумышленника содержит Ignore previous instructions and..., модель может ему подчиниться, поскольку для нее это всего лишь еще один фрагмент языка.

• Доверенные: системные инструкции и политика Вашего приложения.
• Недоверенные: ввод пользователя, веб-страницы, файлы, вывод инструментов, электронные письма.

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

Типичная атака на бота поддержки клиентов выглядит так:

• Боту велят отвечать только на вопросы о выставлении счетов.
• Пользователь вставляет текст, который переопределяет роль модели и просит раскрыть ее системные инструкции или выполнить действия вне предусмотренной области.

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

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

Пользователь-жертва никогда не видит полезную нагрузку. Когда конвейер RAG или агент просмотра веб-страниц добавляет эти материалы в контекст, скрытые инструкции выполняются с правами пользователя-жертвы.

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

Эти понятия пересекаются, но не идентичны:

• Внедрение инструкций направлено на границу приложения — оно подменяет инструкции разработчика данными злоумышленника.
• Обход ограничений направлен на настройки безопасности модели — он побуждает модель создавать содержимое, которое провайдер обучил ее отклонять.

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

Злоумышленники используют предсказуемые схемы манипуляции. Знание этих схем помогает ответственно проверять собственную систему на атаки:

• Ролевая игра / персонаж: представление запроса как вымысла или обращения к вымышленному персонажу без ограничений.
• Маскировка: кодирование в шестидесятичетверичной системе, л33т-стиль, перевод или разделение токенов для обхода фильтров по ключевым словам.
• Разделение полезной нагрузки: распределение запроса между несколькими ходами диалога, чтобы ни одно отдельное сообщение не выглядело вредоносным.
• Гипотетические сценарии: For a security class, describe how one would...
• Внедрение префикса: принуждение к началу ответа с утвердительной фразы, например Sure, here is.

Многие команды сначала обращаются к списку запрещенных фраз, например ignore previous instructions. Такой подход ненадежен, поскольку пространство возможных вводов практически бесконечно.

Естественный язык позволяет выразить одно и то же намерение бесчисленным количеством способов, на разных языках, с использованием разных кодировок и метафор. Злоумышленники перебирают варианты быстрее, чем Вы успеваете исправлять регулярные выражения.

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

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

• Предоставьте LLM только минимально необходимые привилегии. Агенту суммирования не нужны учетные данные для отправки электронной почты.
• Не допускайте попадания недоверенных материалов в привилегированные контуры. Если агент читает внешние веб-данные, он не должен в том же ходу диалога иметь возможность выполнять необратимые действия без контрольной точки.
• Разделяйте контуры данных и контуры управления: извлеченный текст должен быть данными, а не командами.

Хотя такая мера не обеспечивает полной защиты, структура инструкций повышает требования к успешной атаке. Четко отделяйте недоверенные данные и указывайте модели, как с ними обращаться.

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

Вывод модели также является недоверенным. Если приложение передает вывод LLM в командную оболочку, базу данных, браузер или другой инструмент, внедрение может привести к удаленному выполнению кода или выводу данных.

Саймон Уиллисон описывает опасное сочетание, называемое смертельной триадой:

• доступ к конфиденциальным данным;
• контакт с недоверенными материалами;
• возможность внешней связи (вывода данных).

Агент, обладающий всеми тремя возможностями, можно превратить в инструмент кражи данных с помощью одной внедренной инструкции. Устраните любой элемент триады, чтобы остановить атаку.

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

• Ведите журнал полного контекста (инструкций, извлеченных фрагментов, вызовов инструментов), чтобы анализировать инциденты.
• Используйте дополнительный классификатор или защитную модель для выявления подозрительных вводов и выводов.
• Следите за аномальным использованием инструментов: внезапными исходящими запросами, неожиданным доступом к данным, признаками утечки системных инструкций.
• Добавляйте токены-приманки в системные инструкции; если такой токен появляется в выводе, произошла утечка.

Рассматривайте оповещения как реальные инциденты и реагируйте на них согласно рабочей инструкции.

Проверка собственных систем на внедрение необходима и законна. Проводите ее ответственно:

• Проверяйте только системы, которыми Вы владеете или на проверку которых уполномочены.
• Используйте контролируемую среду и синтетические данные; никогда не выводите реальные пользовательские данные.
• Документируйте результаты и добавляйте их в регрессионные проверки, чтобы исправленные обходы оставались исправленными.
• Согласовывайте раскрытие информации, если обнаружили проблемы в моделях или приложениях сторонних разработчиков.

Цель состоит в повышении устойчивости приложения, а не в создании опасных возможностей.

Проверьте, насколько хорошо Вы понимаете границы доверия при внедрении инструкций.

Главные выводы о внедрении инструкций и обходе ограничений:

• Внедрение возникает из-за смешивания доверенных инструкций с недоверенными данными в одном канале.
• Прямое внедрение исходит от пользователя, а косвенное скрывается в извлеченных материалах и его труднее обнаружить.
• Обходы ограничений атакуют настройки безопасности модели, а внедрение атакует границу приложения. Они могут сочетаться.
• Фильтрация ввода — лишь один из уровней многоуровневой защиты, а не основная мера.
• Защищайтесь на архитектурном уровне: используйте минимально необходимые привилегии, отделяйте данные от управления и устраняйте смертельную триаду (конфиденциальные данные + недоверенные материалы + вывод данных).
• Считайте вывод модели недоверенным, ведите журнал всего происходящего и этично проверяйте систему на атаки.