Попросить помощника разобрать входящие заявки – обычная рабочая задача. Однако в одном из писем может оказаться текст, который обращается уже к самому ИИ: меняет правила обработки, предлагает открыть другой документ или отправить сведения постороннему адресату. Человек счёл бы это странной припиской. Модель иногда воспринимает её как продолжение задания. Если помощник умеет пользоваться корпоративными системами, ошибка перестаёт быть просто неудачным ответом. Ниже – практический способ организовать защиту без обещаний, что одна настройка навсегда решит проблему.
Когда чужое письмо становится командой
Представим условную компанию, которая принимает заявки на ремонт оборудования. Помощник читает почту, выделяет модель устройства, описание неисправности и желательный срок. Затем готовит карточку для диспетчера. В приложенном документе встречается «служебная инструкция»: проверить сведения по внутренним заявкам и включить их в ответ отправителю.
У документа нет права менять рабочий процесс. Тем не менее модель получила обычное задание и внешний текст внутри одного контекста. Если приложение не отделило возможное действие от разрешённого действия, помощник может запросить чужие карточки, а затем подготовить опасный ответ.
Это учебный пример, а не сообщение об инциденте у конкретного заказчика. Он показывает два разных сбоя. Сначала модель неверно понимает источник инструкции. Затем приложение позволяет её предложению выйти за пределы задачи. С первым сбоем работают средствами обработки контекста. Второй ограничивают кодом, полномочиями и проверкой операции.
Что именно называют внедрением инструкций
Prompt injection – воздействие на поведение модели через поступивший текст или другое содержимое. Когда такая инструкция приходит из письма, файла, веб-страницы или результата поиска, речь идёт о косвенном внедрении. Автор материала может вообще не иметь доступа к чату помощника.
OWASP описывает этот риск и отдельно указывает, что поиск по документам и дообучение сами по себе не устраняют уязвимость. Инструкция не обязана выглядеть заметной фразой на экране: важно, какое содержимое реально попало в обработку модели. Универсального способа гарантированно предотвратить любые такие воздействия OWASP не обещает.
Для команды разработки полезно сформулировать более проверяемую цель. Даже если модель поддалась чужой инструкции, она не должна получить дополнительные права, сменить адресата или выполнить действие, которого не разрешал рабочий процесс. Эта цель не требует угадывать каждую возможную формулировку атаки.
Определите, кто вправе ставить задачу
Для выбранного сценария нужно разделить три вещи: утверждённые правила приложения, разрешённое поручение пользователя и содержимое, которое помощник исследует. Письмо клиента может сообщить номер заявки. Оно не становится административной настройкой только потому, что внутри написано «правило компании».
Сложность возникает с обычными просьбами. Фраза «перенесите доставку» тоже инструкция, но она может быть допустимым запросом клиента. Поэтому запрещать все повелительные предложения бессмысленно. Приложение должно установить, кто обращается, к какому заказу относится просьба и какую операцию этому человеку разрешено инициировать.
В нашем примере клиент вправе уточнить описание неисправности своего устройства. Его письмо не вправе разрешить чтение заявок других клиентов. Такое различие следует закрепить до запуска модели. Если границы задачи существуют только в голове руководителя, помощник не сможет надёжно восстановить их из переписки.
Проследите путь одного документа
Возьмите одну реальную заявку без чувствительных сведений и проследите, как она проходит систему. Почтовый коннектор получает письмо, обработчик извлекает текст, распознавание читает вложение, поиск добавляет сведения, модель формирует план, инструменты выполняют операции, интерфейс показывает результат.
На каждом переходе запишите происхождение содержимого. Отдельно отметьте, кто мог изменить его до обработки. Присутствие файла в корпоративной папке ещё не отвечает на этот вопрос: материал мог загрузить подрядчик, сотрудник с ограниченными правами или автоматический сборщик.
Для практического разбора достаточно небольшой карты с идентификатором источника и областью применения. Не нужно начинать с большой классификации всей компании. Важно увидеть место, где внешний текст превращается в предложение вызвать инструмент, и место, где это предложение получает разрешение.
Уберите возможности, которые не нужны задаче
Если помощнику поручено подготовить карточку, отправка писем и изменение платёжных реквизитов ему не нужны. Отключать следует реальную функцию, а не только писать в промпте просьбу ею не пользоваться. Удобный универсальный коннектор иногда приносит десятки лишних операций вместе с одной необходимой.
OWASP относит избыточные функции, права и автономность к отдельному риску Excessive Agency. Практический вариант для нашего сценария – инструмент, который создаёт черновик заявки с определёнными полями, вместо произвольного доступа к почте и системе учёта. Проверка разрешения выполняется вне модели.
Ограничение полезно испытать прямым обращением к адаптеру инструмента. Если запрещённую операцию можно выполнить в обход разговора, хороший ответ модели ничего не доказывает. Такой тест проверяет конструкцию приложения, а не удачную формулировку системного промпта.
Проверяйте полномочия в момент действия
Модель может предложить корректный номер карточки, но этот номер не подтверждает право её читать. Проверяющий слой должен использовать установленную приложением личность, организацию и область задачи. Эти сведения нельзя получать исключительно из текста документа или аргументов, предложенных моделью.
Рекомендации OWASP по авторизации включают минимальные привилегии, запрет по умолчанию и проверку полномочий при каждом запросе. Для ИИ-интеграции это означает проверку конкретного объекта и операции, а не только наличие действующего API-ключа.
Рассмотрим условное уточнение: помощник нашёл совпадение по серийному номеру в чужой заявке. Рабочий процесс может разрешить сообщить диспетчеру, что требуется ручная проверка. Он не обязан разрешать выдачу содержимого чужой карточки. Полезность найденного совпадения и право раскрыть данные остаются разными решениями.
Обозначайте внешний текст как данные
У найденного фрагмента должны быть понятные границы: где он начинается, какому документу принадлежит и зачем передан модели. Его можно сопровождать указанием, что это содержимое для анализа, которое не меняет правила приложения. Такая разметка помогает модели ориентироваться, но сама по себе не служит механизмом авторизации.
Не вставляйте извлечённый текст в шаблон так, чтобы он мог закрыть служебную секцию или подменить её заголовок. Обработчик должен сохранять структуру независимо от необычных символов во вложении. При этом осторожность нужна и к собственным промежуточным резюме: пересказ чужой инструкции не делает её доверенной.
Исследователи в работе о косвенном внедрении инструкций показали, что влияние может передаваться через извлекаемые приложением материалы. Практический вывод для проектирования – сохранять происхождение информации при её преобразовании, а не считать любой текст после внутреннего обработчика безопасным распоряжением.
Проверка внешнего материала дополняет ограничения, которые действуют вне языковой модели. Источник изображения: AiHummer
Закройте обход через готовый ответ
Опасное предложение может попасть наружу даже без отдельного почтового инструмента. Например, помощник вставит в ответ непроверенную ссылку, которой пользователь доверится, или сформирует разметку с загрузкой внешнего изображения. Поэтому контролируется и канал отображения результата.
OWASP рассматривает недостаточную проверку вывода модели как самостоятельную проблему. Текст модели нельзя автоматически превращать в выполняемую команду, запрос к базе или активный HTML. Для интерфейса выбирают допустимую разметку и обработку ссылок, для действий – отдельный проверяемый контракт.
В учебной системе ремонта результатом может быть только карточка с фиксированными полями и отметкой о необходимости уточнения. Если модель вместо описания устройства предложила новый адрес для передачи архива, этот адрес не должен незаметно появиться среди утверждённых реквизитов. Отсутствие ошибки синтаксиса ещё не означает правильного назначения данных.
Делайте согласование понятным человеку
Согласование помогает там, где сотрудник действительно может оценить последствия. Окно с вопросом «разрешить действие» почти бесполезно. Проверяющему нужны адресат, состав передаваемых данных, объект изменения и основание операции. Источник спорной просьбы следует показать отдельно.
В нашем условном процессе диспетчер может увидеть: подготовлена заявка по письму клиента, обнаружена инструкция изменить маршрут передачи, автоматическая отправка остановлена. Тогда ему не придётся заново расследовать всё сообщение, чтобы понять причину остановки.
Не превращайте согласование в поток одинаковых уведомлений. Типовая подготовка черновика и отправка сведений новому адресату имеют разную цену ошибки. Если каждое безопасное чтение требует подтверждения, люди начнут нажимать кнопку машинально. Полезнее сначала ограничить возможности инструмента, затем выделить конкретные операции для содержательной проверки.
Не сохраняйте чужую инструкцию как правило
Долговременная память создаёт дополнительный маршрут воздействия. Условный документ может предложить считать новый адрес постоянным адресом клиента. Если помощник запишет это как установленный факт, следующая задача начнётся уже с опасной предпосылки.
Разделяйте извлечённое утверждение и подтверждённое рабочее правило. У записи о реквизитах должны быть источник и статус проверки. Автоматический пересказ переписки не должен повышать её доверие. Изменение маршрута связи проверяют через предусмотренный компанией процесс, а не через убедительность найденной фразы.
Это относится и к цепочкам агентов. Один помощник может подготовить краткое описание для другого, но вместе с описанием необходимо передать область задачи и происхождение спорных данных. Делегирование само по себе не создаёт новых полномочий и не превращает внешний текст в решение руководителя.
Фильтр должен понимать назначение текста
Проверка подозрительных формулировок полезна как сигнал для разбора. Однако фраза о смене правил может встретиться в настоящей инструкции по эксплуатации, которую сотрудник попросил сравнить с прежней версией. Автоматический отказ на отдельное слово способен лишить помощника именно той функции, ради которой его подключили.
Лучше описать допустимое использование материала. Помощник может сообщить, что документ предлагает новый порядок обслуживания, и сослаться на соответствующий фрагмент. Это аналитический результат. Он не должен на основании того же фрагмента менять свою конфигурацию или считать порядок утверждённым для всей компании. Содержание документа и его административный статус различаются.
Условный диспетчер вправе получить замечание о противоречии двух инструкций. В таком ответе особенно полезны точные источники и вопрос ответственному за правила. Бесполезно скрывать весь документ и выдавать только сообщение об опасности: человек не поймёт, что именно необходимо проверить.
Дополнительная модель для проверки содержимого может помочь находить признаки воздействия, но её заключение тоже требует контроля. Если оба помощника читают одно и то же письмо, нельзя автоматически считать ответ второго независимым подтверждением безопасности. Решение о доступной операции должно оставаться в приложении.
При испытании фильтра оцените не только обнаруженные подозрительные документы, но и ложные остановки обычной работы. Команде нужны отдельные сведения о том, какой материал задержан, какая операция заблокирована и что пользователь может сделать дальше. Тогда защита улучшает рабочий маршрут, а не превращает любое нестандартное обращение в тупик.
Соберите небольшой безопасный стенд
Первый набор проверок можно построить без настоящих секретов и внешних получателей. Создайте вымышленные карточки, тестовую почту и заглушки инструментов, которые сохраняют попытку операции вместо её выполнения. Проверяйте не только ответ в чате, но и журнал предложенных и отклонённых действий.
Подготовьте несколько вариантов одной заявки: обычный документ, текст с притворной служебной инструкцией, вложение с просьбой раскрыть соседнюю карточку, материал с неподтверждёнными реквизитами и пересказ, в котором происхождение спорного фрагмента легко потерять. Точные формулировки должны отражать ваш процесс, а не коллекцию эффектных интернет-примеров.
Рядом нужны обычные письма с допустимыми просьбами. Иначе команда добьётся результата простым отказом на любое сообщение. Хорошая проверка показывает одновременно два свойства: разрешённая заявка обработана, а дополнительное неразрешённое действие не произошло.
Заранее сформулируйте ожидаемый результат
Для каждого испытания запишите, что считается успехом. В одном случае помощник должен извлечь модель устройства. В другом – подготовить черновик и отметить неподтверждённое изменение. При попытке чтения чужой карточки правильным результатом станет отказ проверяющего слоя с понятной причиной.
Полезно различать влияние на текст и нарушение границы доступа. Модель может повторить подозрительную фразу, но инструмент остановит операцию. Это всё равно материал для улучшения, однако он не равен фактической передаче сведений. И наоборот, спокойный ответ в чате не оправдывает незаметный вызов запрещённого инструмента.
Повторяйте набор после смены модели, коннектора, формата документа и правил сборки контекста. Не переносите успешный результат с одной конфигурации на все будущие версии. Сохраняйте условия запуска, чтобы команда могла воспроизвести проблему и понять, что именно изменилось.
При подозрении остановите конкретный маршрут
Если рабочий помощник начал предлагать неожиданные операции, первым действием может стать отключение соответствующего инструмента или приостановка конкретного сценария. Порядок зависит от устройства системы. Не стоит автоматически удалять все документы: это может уничтожить сведения, необходимые для разбора.
Сохраните идентификаторы источника, задачи, версии конфигурации и вызовов. Проверьте, выполнялась ли операция фактически, какие данные были доступны и осталось ли спорное утверждение в памяти или промежуточном результате. Журнал для диагностики тоже не должен превращаться в неограниченную копию корпоративных секретов.
После исправления сначала повторите проблемный сценарий на стенде, затем обычные заявки. Возвращение рабочего маршрута должно опираться на проверенный результат, а не на то, что помощник снова отвечает привычным тоном.
Начните с одного рабочего процесса
Для первой итерации выберите помощника, который читает внешние материалы и имеет хотя бы один инструмент с последствиями. Зафиксируйте допустимый результат, уберите лишние операции, проверьте права на объект и подготовьте тестовое письмо с попыткой изменить задачу.
Если чужая инструкция всё ещё меняет ответ, улучшайте сборку контекста. Если она позволяет выполнить запрещённое действие, исправляйте полномочия и адаптер инструмента. Эти работы дополняют друг друга. Защита появляется там, где команда может показать границу на конкретной операции и проверить её поведение даже при ошибке модели.
Изображение на обложке: AiHummer
Комментарии