tgoop.com/llmsecurity/519
Last Update:
The Dual LLM pattern for building AI assistants that can resist prompt injection
Simon Willison, 2023
Блог
Начал разбирать статью от DeepMind про CaMeL, систему защиты LLM-агентов от промпт-инъекций, но по пути решил вспомнить старый блог Саймона Уиллисона, на идеи из которого очень сильно опирается новый метод (если что, уже сейчас есть разбор CaMeL от Бориса).
Автор рассматривает в качестве модели угроз атаку на модель, которая имеет в распоряжении инструменты, вызываемые стандартными методам (генерацией вызова, который обрабатывает внешний парсер), и которая обрабатывает недоверенные 3rd-party-данные. Например, модель может читать электронные письма (недоверенный вход) и отправлять письма. Это может привести к эксфильтрации данных как через вызов инструмента отправки писем, так и, например, через рендеринг изображения.
Метод состоит в следующем: давайте заведем для нашей LLM два контекста. Один мы назовем привилегированной LLM (Privileged LLM, P-LLM), второй – LLM в карантине (Quarantined LLM, Q-LLM). В теории это могут действительно быть разные LLM, но на деле это, скорее всего, именно два контекста одной LLM. P-LLM имеет доступ к инструментам: она может отправлять письма или менять содержимое календаря, но никогда не взаимодействует с недоверенными данными. Q-LLM, напротив, может взаимодействовать с недоверенными данными, но не может вызывать инструменты. К ним добавляется третий компонент: контроллер, который осуществляет интеграцию наших двух LLM. Его цель – передавать данные, которые потенциально могут быть загрязнены инъекцией, в виде специальных переменных, так что P-LLM видит их только как специальные токены.
Например, если мы просим систему дать нам выжимку из последнего письма, то P-LLM вызывает инструмент получения письма, но текст письма остается у контроллера – P-LLM узнает, что он присвоен переменной $VAR1. Затем P-LLM просить Q-LLM дать саммари – контроллер передает этот запрос в Q-LLM с реальным текстом письма, и сообщает в P-LLM, что результат суммаризации присвоен переменной $VAR2. P-LLM решает, что задача выполнена, и дает контроллеру команду отдать результат пользователю, который уже видит на экране значение $VAR2.
Несмотря на увеличившуюся сложность системы и необходимость поддерживать контроллер, система дает достаточно небольшой оверхед по токенам. С другой стороны, она все еще не защищает от любых атак – я не вполне понимаю, как в данном случае работает защита от эксфильтрации через изображения, да и то, что информация внутри переменных не генерируется под влиянием потенциальных инъекций, никто не обещает. Что обещается – так это то, что под воздействием инъекций не произойдет никакого незапланированного вызова инструментов. Хотя это ограничивает возможности для open-ended-агентов, которые должны строить план выполнения на основе данных, а не заранее, для более простых ассистентов это может стать важным компонентом защиты.
BY llm security и каланы
Share with your friend now:
tgoop.com/llmsecurity/519