Telegram Group & Telegram Channel
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-агентов, которые должны строить план выполнения на основе данных, а не заранее, для более простых ассистентов это может стать важным компонентом защиты.



group-telegram.com/llmsecurity/519
Create:
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 и каланы


Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260

Share with your friend now:
group-telegram.com/llmsecurity/519

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

These entities are reportedly operating nine Telegram channels with more than five million subscribers to whom they were making recommendations on selected listed scrips. Such recommendations induced the investors to deal in the said scrips, thereby creating artificial volume and price rise. "The argument from Telegram is, 'You should trust us because we tell you that we're trustworthy,'" Maréchal said. "It's really in the eye of the beholder whether that's something you want to buy into." For Oleksandra Tsekhanovska, head of the Hybrid Warfare Analytical Group at the Kyiv-based Ukraine Crisis Media Center, the effects are both near- and far-reaching. Channels are not fully encrypted, end-to-end. All communications on a Telegram channel can be seen by anyone on the channel and are also visible to Telegram. Telegram may be asked by a government to hand over the communications from a channel. Telegram has a history of standing up to Russian government requests for data, but how comfortable you are relying on that history to predict future behavior is up to you. Because Telegram has this data, it may also be stolen by hackers or leaked by an internal employee. "There is a significant risk of insider threat or hacking of Telegram systems that could expose all of these chats to the Russian government," said Eva Galperin with the Electronic Frontier Foundation, which has called for Telegram to improve its privacy practices.
from it


Telegram llm security и каланы
FROM American