Как проверить ИИ службы поддержки на инъекции инструкций

Проверяйте ИИ службы поддержки на инъекции инструкций по тому, что недоверенное сообщение способно заставить раскрыть, изменить или выполнить всю систему. Проводите такие проверки в тестовой среде с синтетическими клиентами, ограниченными инструментами и записанными результатами. Вежливый отказ на один очевидный запрос ещё не доказывает безопасность агента.

Инъекция инструкций возникает, когда недоверенный ввод непредусмотренно меняет поведение модели. Он может поступить прямо из сообщения клиента или косвенно из статьи базы знаний, вложения, веб страницы, ответа инструмента либо сохранённого разговора. Проект OWASP по безопасности генеративного ИИ ставит эту угрозу на первое место LLM01 в списке 2025 года и подчёркивает, что поиск по базе знаний и дополнительное обучение не устраняют риск полностью.

Для поддержки это не отвлечённая проблема модели. ИИ агент может видеть клиентские записи, обращаться к базе знаний, добавлять метки, менять тикет или предлагать перевод оператору. Проверка должна пройти весь путь от входящего сообщения до действия и ответа.

Сначала определите границы действий

До создания тестов запишите, что агент вправе читать, решать и изменять. Отделите обычные ответы от действий с повышенными полномочиями.

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

Для каждой проверки проследите цепочку:

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

Проверьте каждый путь недоверенного содержимого

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

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

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

Не затрагивайте реальных клиентов

Создайте отдельное тестовое пространство с вымышленными именами, заказами, адресами, платежами и историями обращений. Его учётные данные не должны открывать производство. Отключите настоящие письма, сообщения, возвраты денег, бронирования и удаление записей либо направьте действия в контролируемый тестовый сервис.

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

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

Оценивайте возможный ущерб

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

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

Различайте заблокированные, обнаруженные, сдержанные и успешные попытки. Детектор способен подать сигнал уже после опасного вызова инструмента. Сдерживание означает, что окружающие механизмы остановили последствие, даже если модель последовала недоверенной инструкции.

Исправляйте систему вокруг модели

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

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

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

Пример с прокатом камер

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

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

В DripTell AI команды управляют знаниями, намерениями, созданием лидов и переводом оператору, а настройки безопасности задают роли и доступ. Но каждому внедрению всё равно нужен тестовый план, соответствующий реально доступным данным и действиям.

Часто задаваемые вопросы

Можно ли полностью предотвратить инъекции инструкций

Нет, ни один современный механизм не даёт полной гарантии. Минимальные права, детерминированная проверка доступа и действий, одобрение человека, наблюдение и повторные тесты уменьшают вероятность и последствия сбоя.

Нужны ли для теста реальные данные клиентов

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

Что делать после неудачного теста

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