Информационная безопасность LLM: в чем разница между Prompt Injection и Jailbreaking

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

Одной из распространённых угроз является Prompt Injection. Если объяснять, что такое промпт инъекция, это атака, при которой злоумышленник пытается изменить поведение модели через входные данные или инструкции внутри контекста. Например, конфликтующие инструкции могут находиться в пользовательском запросе, документе или другом источнике данных, который система передаёт модели для обработки.

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

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

Prompt Injection — это тип атаки на LLM, при которой злоумышленник пытается повлиять на поведение модели через специально сформированный ввод. Если разобрать, что такое prompt injection атака, её цель заключается в изменении обработки запроса или приоритетов инструкций. Цель такой атаки — изменить обработку запроса, нарушить заданную логику работы системы или заставить модель учитывать инструкции, которые не должны иметь приоритет.

Принцип работы связан с тем, как модель обрабатывает разные источники информации. LLM получает системный промпт с правилами работы, пользовательский запрос и дополнительные данные из подключённых источников. Если в этих данных находятся конфликтующие инструкции, модель может неправильно определить их приоритет и учесть нежелательные указания.

Риск Prompt Injection особенно актуален для систем, где LLM работает не только с прямыми запросами пользователей, но и с внешними источниками: документами, базами знаний, веб-страницами или подключёнными инструментами. Например, корпоративный AI-ассистент может обрабатывать внутренние файлы и использовать их для формирования ответа.

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

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

При прямом Prompt Injection пользователь сам добавляет инструкции в запрос к модели, пытаясь изменить заданные правила работы ассистента. Например, пользователь может попытаться заставить систему игнорировать установленную логику обработки запроса или изменить формат ответа.

Если рассматривать, что такое косвенное prompt injection, то это сценарий, при котором конфликтующие инструкции находятся не в запросе пользователя, а во внешнем источнике данных, а во внешнем источнике данных, который система передаёт модели для анализа. Это может быть документ, веб-страница, письмо или запись в корпоративной базе знаний. В таком случае модель может обработать эти инструкции как часть входной информации.

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

Такой промт инъекция пример показывает, почему при создании LLM-систем необходимо учитывать не только пользовательские запросы, но и все источники данных, с которыми работает модель. Особенно это важно для решений, которые используют корпоративные документы и базы знаний. Для таких сценариев применяются RAG-системы для бизнеса, где контролируются источники информации и правила доступа к данным.

Косвенный Prompt Injection особенно важен для корпоративных систем с доступом к документам и внутренней информации, поскольку модель работает не только с текстом пользователя, но и с дополнительным контекстом из внешних источников.

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

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

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

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

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

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

При agent jailbreak риск связан не только с содержанием ответа модели. Если результат работы LLM передаётся другим компонентам системы, успешное воздействие может повлиять на дальнейшие действия агента: обращение к данным, вызов подключённых сервисов или выполнение разрешённых операций.

Например, AI-агент с доступом к внутренней базе знаний и внешним инструментам требует более строгого контроля, чем обычный чат-ассистент. Уровень риска зависит от архитектуры решения, набора доступных функций и предоставленных прав.

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

Prompt Injection и Jailbreaking относятся к разным типам рисков для языковых моделей и работают по разным принципам. В первом случае воздействие направлено на изменение обработки инструкций и данных, во втором — на обход ограничений, установленных для модели.


Главное различие заключается в цели воздействия. Prompt Injection пытается повлиять на то, как модель обрабатывает инструкции, контекст и внешние данные. Например, риск возникает, когда LLM получает дополнительную информацию из документов, баз знаний или подключённых источников и неверно определяет приоритеты между данными и правилами работы.

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

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

Безопасность LLM требует учитывать не только саму модель, но и всю архитектуру решения: источники данных, систему доступа, подключённые инструменты и способы контроля результатов. Для RAG-систем и AI-агентов это особенно важно, поскольку последствия ошибки могут зависеть от того, какие функции доступны модели.

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

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

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

К основным рискам корпоративных LLM-систем относятся неправильная обработка документов, раскрытие части системных инструкций, некорректная работа AI-ассистентов и потенциальное получение доступа к корпоративным данным. Поэтому информационная безопасность должна учитывать не только поведение самой модели, но и всю архитектуру решения: источники данных, механизмы доступа, подключённые инструменты и контроль результатов.

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

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

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

Контроль модели включает проверку результатов, тестирование сценариев и регулярную оценку поведения системы. Один из подходов — red teaming, при котором специалисты проверяют устойчивость решения к различным сценариям воздействия.

Защита LLM должна строиться на основе модели угроз и регулярно обновляться вместе с изменением системы. Новые источники данных, инструменты и бизнес-сценарии могут создавать дополнительные риски, поэтому тестирование безопасности становится постоянным процессом.

Фильтрация пользовательских запросов помогает снизить часть рисков, но не закрывает все возможные сценарии воздействия на LLM. Система может получать данные не только напрямую от пользователя, но и из документов, веб-страниц, баз знаний и других внешних источников. Если эти данные используются как контекст для модели, они также требуют проверки.

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

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

Подход AI Security предполагает постоянную оценку рисков, поскольку корпоративные LLM-системы изменяются вместе с новыми источниками данных, интеграциями и сценариями использования. Поэтому защита должна быть частью всего процесса разработки и эксплуатации решения.

Аспирити разработала для страховой компании систему речевой аналитики, которая работает в корпоративном контуре и помогает анализировать клиентские звонки с помощью ИИ. Решение размещается on-premise, поэтому данные не передаются во внешние облачные сервисы. В системе используются модель Qwen 32B, собственная технология распознавания речи и настраиваемые критерии оценки диалогов.

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

При этом on-premise-размещение само по себе не устраняет все возможные риски, включая Prompt Injection или Jailbreaking. Безопасность зависит от всей архитектуры решения: источников данных, настроек доступа, способов обработки информации и контроля результатов.

В рамках проекта более 40% агентов улучшили показатели продаж после получения AI-инсайтов, а более 50% сотрудников стали использовать систему ежедневно. Эти результаты относятся к конкретному внедрению и не могут напрямую переноситься на другие LLM-системы.

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

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

Процесс тестирования включает несколько этапов:

1. Определить возможные угрозы и сформировать модель рисков.
2. Проверить основные сценарии использования системы.
3. Провести тестирование запросов и оценить реакцию модели на разные типы входных данных.
4. Проверить работу с реальными данными и внешними источниками, включая RAG-системы.
5. Настроить контроль качества после запуска.

Отдельно проверяются:

• ограничения и поведение самой модели;
• обработка пользовательского ввода;
• внешние источники данных;
• права AI-агента;
• работа подключённых инструментов;
• контроль вывода модели;
• журналирование и мониторинг действий системы.

Для комплексной оценки применяются подходы AI Security, включая red teaming — проверку системы через моделирование потенциальных сценариев воздействия. Это помогает выявить слабые места до использования решения в рабочих процессах.

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

Prompt Injection и Jailbreaking относятся к разным типам угроз для LLM-систем. Prompt Injection связан с воздействием через инструкции и контекст, когда злоумышленник пытается изменить обработку данных или поведение модели. Jailbreaking направлен на обход ограничений и правил безопасного поведения LLM.

Безопасность LLM требует комплексного подхода: настройки архитектуры, управления доступом, контроля источников данных, проверки результатов и регулярного тестирования системы. Защита должна учитывать не только саму модель, но и все компоненты решения, включая внешние данные и подключённые инструменты.

При разработке корпоративных LLM-систем важно заранее оценивать возможные сценарии риска и выстраивать защитные механизмы на уровне всей инфраструктуры.