Криптография определяет, кто может прочитать сообщение при передаче; контроль доступа и архитектура агента определяют, что получатель может сделать после прочтения.
Атака Prompt Injection в мессенджере происходит, когда текст сообщения побуждает ИИ-помощника игнорировать основные правила и выполнять несанкционированный запрос. Сквозное шифрование защищает сообщение при передаче, но если пользователь разрешил боту читать переписку или устройство скомпрометировано, шифрование не может ограничить поведение этого авторизованного получателя.
Ключевые выводы
- Сквозное шифрование препятствует чтению сообщения при передаче, но не злоупотреблениям со стороны виртуального помощника, которому разрешено видеть расшифрованный текст.
- Косвенная Prompt Injection может скрываться в личном сообщении, файле, подписи или цитате и после обработки превратиться в инструкцию.
- Риск утечки данных из ИИ-агента возрастает, когда агент одновременно имеет доступ к переписке, памяти, внешним инструментам и возможности отправлять данные или выполнять действия.
- Разделение данных и инструкций, минимизация разрешений, подтверждение человеком и ограничение выходных данных — важнейшие уровни защиты; ни один из них сам по себе не даёт полной гарантии.
- Согласно документации Livara, личные чаты и совместимые закрытые группы с активным статусом E2EE защищены сквозным шифрованием; старая несовместимая группа может оставаться вне этого покрытия. Такая защита не гарантирует безопасного поведения помощника после получения текста.
Как работает атака Prompt Injection в мессенджере?
Prompt Injection, или «внедрение инструкций», означает, что злоумышленник создаёт входные данные, которые языковая модель примет за инструкцию, а не за данные, и отклонится от исходной политики. Руководство OWASP по Prompt Injection относит к путям возникновения этого риска прямой ввод и внешний контент. В агентной системе искажение ответа может привести и к нежелательному использованию подключённых инструментов.
При прямой атаке сам пользователь говорит боту отбросить прежние правила. При косвенной атаке вредоносная инструкция помещается в контент, который помощник читает для выполнения другой задачи: входящее сообщение, цитируемый текст, подпись, документ или результат работы инструмента. Во втором случае злоумышленнику не нужно пользоваться общим с ИИ-агентом аккаунтом; достаточно, чтобы его контент попал в контекст, обрабатываемый агентом.
Например, пользователь просит помощника кратко изложить новые сообщения. Одно из них содержит текст, выдающий себя за «системную инструкцию» и требующий от агента прекратить составление сводки, взять из контекста другие сведения и отправить их внешнему адресату. Успех этого сценария не гарантирован и зависит от модели, архитектуры приложения, прав доступа и контроля выходных данных; однако даже такая возможность важна для безопасности помощника с инструментами.
Следует различать манипуляцию ответом модели и атаку на агента, способного совершать действия. Неверный ответ может раздражать; агент с разрешением отправлять сообщения, получать файлы или обращаться к сервисам может превратить ту же манипуляцию в раскрытие данных или нежелательное действие.
Почему безопасность ИИ-чат-бота зависит не только от шифрования?
Безопасность ИИ-чат-бота зависит от всей цепочки доверия: мессенджера, устройства, модели, памяти, инструментов, сервера поставщика и политики разрешений. Сквозное шифрование охватывает только одну определённую границу: предотвращает чтение личного содержимого на пути между отправителем и авторизованными получателями.
Когда сообщение поступает на авторизованное устройство, оно расшифровывается для показа пользователю. Если помощник имеет доступ к тексту на том же устройстве или через разрешённое подключение, он видит данные после расшифровки. С точки зрения протокола бот или приложение с разрешением может быть законным получателем; с точки зрения пользователя тот же получатель может обладать чрезмерными полномочиями.
Это различие можно сформулировать так: криптография определяет, кто может прочитать сообщение при передаче; контроль доступа и архитектура агента определяют, что получатель может сделать после прочтения. Чтобы понять первую границу, руководство «Сквозное шифрование и то, от чего оно не защищает» объясняет, что E2EE не устраняет угрозы вредоносного ПО, недобросовестного получателя или скомпрометированного экрана.
Фразу «зашифрованный мессенджер и искусственный интеллект» тоже не следует автоматически трактовать как признак безопасности или небезопасности. Локальный агент без постоянной памяти и инструментов вывода не имеет того же уровня риска, что облачный бот с доступом к истории, файлам и внешним аккаунтам. Результат определяют архитектура и объём разрешений.
Какие риски создаёт доступ ИИ-помощника к личной переписке?
Доступ ИИ-помощника к личной переписке переносит содержимое, которое раньше видели только участники разговора, в новую границу доверия. Главный риск в том, что помощник сможет не только читать текст, но и сохранять его, объединять с другими данными или передавать наружу по другому каналу.
Прежде чем включать такую функцию, нужно ясно ответить на пять вопросов:
- Какие именно разговоры, вложения и временной диапазон читает помощник?
- Обработка выполняется на устройстве или содержимое уходит на другой сервер?
- Какие данные хранит поставщик и использует ли он их для обучения?
- Какие инструменты есть у агента для отправки сообщений, загрузки файлов, поиска или выполнения действий?
- Требует ли каждое чувствительное действие явного подтверждения пользователя?
Разрешение «читать все чаты» для функции, которая должна лишь кратко изложить одно выбранное сообщение, нарушает принцип наименьших привилегий. Этот принцип означает, что каждый компонент получает только минимальный доступ, необходимый для текущей задачи. Ограничение разрешения одним сообщением, одним разговором и одним обращением уменьшает масштаб ущерба; при этом контент в этих пределах всё ещё может стать целью атаки.
Метаданные также отличаются от содержимого. Согласно документации Livara, служебные метаданные, такие как отправитель, адресат и время доставки, сохраняются для маршрутизации и синхронизации. Руководство «Метаданные мессенджера и сведения, которые они раскрывают» объясняет эту границу. Помощник может делать выводы не только из текста, но и из структуры контактов и времени общения; поэтому политика доступа должна учитывать и то и другое.
По каким каналам происходят утечки данных из ИИ-агента?
Утечка данных из ИИ-агента обычно происходит, когда агент видит конфиденциальное содержимое в своём контексте и имеет путь для передачи его в другое место. Само по себе внедрение инструкций не перемещает данные; утечка зависит от сочетания вредоносного ввода, доступа к данным и канала вывода.
Исходящее сообщение или файл
Агент может включить сведения в ответ, новое сообщение, черновик, файл или запрос к внешнему сервису. Если система отправляет выходные данные без ограничений или подтверждения пользователя, злоумышленник может попытаться придать конфиденциальным данным внешне обычную форму.
Долговременная память
Некоторые агенты сохраняют сводки разговоров, предпочтения или предыдущие результаты для дальнейшего использования. Вредоносная инструкция может пытаться записать данные в память или извлечь их в другом сеансе. Короткий срок жизни памяти, изоляция пользователей и возможность просматривать и удалять её снижают риск, но не устраняют ошибки модели.
Вызов инструментов
Агент с инструментами может выполнять поиск, читать файлы или совершать другие разрешённые действия. Чтение файлов, отправка сообщений и сетевые запросы должны иметь отдельные разрешения. Даже автоматическое отображение ссылки или загрузка внешнего ресурса в выходных данных может создать канал утечки; одного отсутствия кнопки «Отправить» недостаточно.
Скомпрометированное устройство
Вредоносное ПО с достаточным доступом может видеть отображаемый текст, уведомления, память приложения или пользовательский ввод. В такой ситуации злоумышленнику необязательно взламывать шифрование: он обходит его через конечное устройство. Защита операционной системы, обновления, контроль доступа и проверка установленных приложений — элементы обороны, а не возможности протокола мессенджера.
Каковы границы криптографической защиты Livara от этой угрозы?
В документации по безопасности Livara LVR1 описан для личных чатов, а LGS1 — для совместимых закрытых групп. Старая несовместимая группа может явно находиться вне E2EE; нужно проверить статус конкретного разговора. Публичные каналы также не входят в область личных чатов E2EE.
Даже в разговоре с E2EE, если пользователь предоставляет помощнику расшифрованный текст, криптография сообщений не контролирует цель последующей обработки. Проверка номера безопасности тоже предназначена для подтверждения ключа контакта, а не для обнаружения вредоносных инструкций в его тексте. Эта статья посвящена общему классу рисков и не подтверждает существование или безопасность конкретного подключения ИИ в Livara.
Это концептуальная схема, а не подтверждённая архитектура Livara; замки на изображении не доказывают, что помощник не имеет доступа к выбранному тексту.
Какая архитектура ограничивает Prompt Injection в мессенджере?
Безопасная архитектура должна считать входящее сообщение недоверенными данными, даже если оно пришло от знакомого контакта и находится в зашифрованном чате. Шифрование укрепляет подлинность пути передачи, но не доказывает, что контент отправителя безвреден для автоматического исполнения.
Отделяйте данные от инструкций
Приложение должно хранить неизменную инструкцию разработчика, явный запрос пользователя и прочитанный из чата контент в отдельных слоях. Предупреждение NCSC о внедрении инструкций подчёркивает, что нельзя считать эту проблему аналогом SQL Injection с таким же окончательным решением. Пометка контента как «недоверенных данных» полезна, но языковые модели не всегда безошибочно соблюдают эту смысловую границу; поэтому разделение нужно дополнять контролем вне модели.
Сокращайте полномочия агента
Агенту для составления сводок не нужна возможность автоматически отправлять сообщения или читать все файлы. У инструментов должны быть список разрешённых возможностей, узкая область действия, отдельные учётные данные и короткий срок разрешений. Одноразовое разрешение на выбранный контент лучше постоянного доступа, поскольку уменьшает и вероятность нежелательного доступа, и масштаб утечки.
Проверяйте выходные данные на детерминированном шлюзе
Модель не должна сама принимать окончательное решение об отправке чувствительных данных. Негенеративный слой может проверять адресата, тип данных, объём вывода и запрошенную операцию по детерминированным правилам. Структурные правила и списки разрешённых адресатов должны применяться вне модели; смысловое распознавание всей конфиденциальной информации всё равно может ошибаться. Также необходимы минимальная регистрация событий, оповещения и возможность остановки.
Требуйте подтверждения человеком для чувствительных действий
Прочитать черновик — не то же самое, что отправить его. Отправка сообщения, предоставление доступа к файлу, добавление участника, изменение настроек аккаунта или передача данных внешнему сервису должны сопровождаться ясным предварительным просмотром и осознанным подтверждением. Неясные или слишком частые запросы подтверждения превращаются в привычное нажатие кнопки; интерфейс должен точно показывать данные, адресата и результат.
Запускайте агента в ограниченной среде
Изоляция процессов, отключённый по умолчанию доступ к сети, временное хранилище и учётные данные с узкими правами ограничивают последствия сбоя. Эти меры не устраняют Prompt Injection; они не дают искажённому ответу непосредственно превратиться в широкий доступ.
Что делать пользователям и администраторам для безопасности ИИ-чат-бота?
Пользователям следует считать каждое подключение ИИ новым получателем личных данных. Администраторам также нужно изучать потоки данных и действия агента до внедрения и наблюдать за ними во время работы.
Для личного использования:
- Выбирайте только нужное сообщение или файл; не предоставляйте доступ ко всей истории.
- Проверяйте место обработки, срок хранения, использование для обучения и способ удаления данных.
- Оставляйте автоматическую отправку сообщений или файлов выключенной, если в ней нет явной необходимости.
- Обновляйте устройство, браузер и приложения и пересматривайте чувствительные разрешения.
Для организаций:
- Составьте модель угроз, отдельно охватывающую злоумышленника-отправителя, недобросовестного участника группы, сервис модели, внешний инструмент и скомпрометированное устройство.
- Регистрируйте вызовы инструментов, изменения разрешений, адресатов вывода и подтверждения пользователя, сохраняя минимум необходимых чувствительных данных.
- Тестируйте враждебные входные данные в сообщениях, документах, цитатах, изображениях с текстом и полученном из внешних источников контенте.
- Задайте для каждого агента предел числа действий, частоты запросов, разрешённые адресаты и аварийный выключатель.
- Сделайте безопасный отказ поведением по умолчанию: если политика неясна, агент должен остановиться, а не угадывать.
Ни один перечень мер не обеспечивает полной безопасности. Результат зависит от реализации, модели, настроек, поведения пользователя и развития методов атак. Цель хорошей защиты — уменьшить полномочия, сделать отклонения заметными и ограничить ущерб.
Могут ли зашифрованный мессенджер и ИИ быть безопасными вместе?
Да, зашифрованный мессенджер и ИИ могут работать вместе с контролируемым риском, если помощник имеет минимальный доступ и не выполняет чувствительных действий без подтверждения. Но подключение любой модели к личному содержимому создаёт новую границу доверия, которую нельзя скрывать под обозначением E2EE.
Архитектура с меньшим риском по возможности оставляет обработку на устройстве, ограничивает контекст явным выбором пользователя, делает память краткосрочной и отделяет инструменты вывода. Локальная обработка тоже не является абсолютной гарантией: скомпрометированное устройство, небезопасная модель или широкие разрешения по-прежнему создают риск.
Пользователь должен понимать, какие данные поступают в модель, где она работает, как долго что-либо хранит и какие действия может совершать. Если продукт не даёт ясных ответов на эти вопросы, из выражений вроде «приватный ИИ» нельзя делать однозначный вывод о безопасности.
Документация протокола или совпадение хеша приложения не являются проверкой безопасности подключённого помощника. Прежде чем включать подключение, отдельно изучите разрешения и путь данных именно этой функции. Результат одного успешного теста также сам по себе не охватывает все будущие входные данные.
Частые вопросы
Останавливает ли сквозное шифрование Prompt Injection?
Нет. Сквозное шифрование скрывает сообщение от посредников между отправителем и авторизованными получателями. Если авторизованный бот, приложение на устройстве или вредоносное ПО имеет доступ к расшифрованному тексту, оно может его обрабатывать. Для сдерживания Prompt Injection нужно ограничивать разрешения, инструменты, память и выходные данные агента.
Опасно ли составлять сводку личной переписки с помощью ИИ?
Риск зависит от архитектуры. Локальное составление сводки одного выбранного сообщения без памяти и инструментов вывода имеет меньший масштаб риска, чем облачный бот с постоянным доступом ко всем чатам. Перед использованием проверьте место обработки, хранение данных, объём разрешений и возможность автоматической отправки.
Может ли сообщение знакомого контакта содержать Prompt Injection?
Да. Доверие к личности отправителя не равнозначно доверию ко всему его контенту: его аккаунт могли захватить, либо он мог неосознанно переслать вредоносный текст. Любой контент, который читает агент, нужно считать недоверенными данными, даже внутри аутентифицированного и зашифрованного разговора.
Скрывают ли LVR1 и LGS1 информацию от ИИ-помощника?
В разговорах, действительно защищённых LVR1 или LGS1 с активным статусом E2EE, цель этих протоколов — скрывать содержимое от посредников без ключа. Если пользователь или приложение разрешает помощнику читать расшифрованное сообщение, эти протоколы не блокируют такой авторизованный доступ. Поэтому безопасность помощника следует оценивать отдельно от безопасности передачи сообщений.
Каков первый шаг для снижения утечек данных из ИИ-агента?
Сначала сократите область доступа агента: только выбранное сообщение, только для текущего обращения и без возможности автоматической отправки. Затем добавьте предварительный просмотр и подтверждение человеком для чувствительных операций, ограничьте адресатов вывода и регистрируйте вызовы инструментов. Эти уровни снижают риск, но не дают абсолютной гарантии.
