Пока голосовой AI только отвечает на вопросы, ошибка чаще всего остаётся проблемой качества. Ситуация заметно меняется, когда агент получает доступ к CRM, внутренним API и другим системам компании и может выполнить действие от имени пользователя. Теперь входящий разговор способен влиять не только на текст ответа.
В Neuro.net решили отдельно рассмотреть эту сторону агентных систем. Голос становится ещё одним каналом, через который AI получает инструкции. Поэтому вместе с новыми возможностями появляются уже знакомые для LLM-агентов риски: prompt injection, злоупотребление инструментами, избыточные полномочия и попытки заставить систему выйти за разрешённый сценарий.
Языковая модель не должна быть границей безопасности системы. Решение модели и разрешение выполнить операцию должны оставаться разными этапами.
Почему голос меняет модель угроз
После распознавания речи слова пользователя становятся входными данными для AI-системы. Поэтому попытка изменить поведение агента с помощью специально сформулированной инструкции возможна и в голосовом канале.
Сам по себе такой запрос ещё не означает успешную атаку. Риск появляется там, где нежелательная инструкция может превратиться в реальное действие.
Это особенно важно для систем, которые работают не только с разговором, но и с корпоративными сервисами. Например, корпоративный голосовой помощник может быть связан с CRM, календарями, внутренними базами и другими инструментами. Чем больше таких возможностей, тем точнее должны быть определены права агента.
Что такое prompt injection
Prompt injection — попытка повлиять на поведение языковой модели через инструкции, которые противоречат правилам приложения.
Инструкция может прийти напрямую от пользователя или оказаться внутри внешнего документа, страницы, сообщения или другой информации, которую агент использует в работе.
OWASP относит прямую и косвенную prompt injection к основным рискам агентных систем. В тот же набор входят злоупотребление инструментами, повышение привилегий, утечка данных, отравление памяти и чрезмерная автономность.
Почему инструменты повышают цену ошибки
Возьмём самый простой пример.
Если AI умеет только назвать часы работы, попытка вывести его за сценарий может закончиться странным ответом.
Если тот же агент получил возможность искать клиента в CRM, менять запись или отправлять команду во внутренний сервис, последствия уже выходят за пределы диалога.
Microsoft в исследованиях безопасности агентных фреймворков показывала сценарии, где prompt injection в сочетании с небезопасно подключёнными инструментами могла привести к выполнению нежелательных операций. Самая важная мысль из таких случаев касается архитектуры: модель лишь формирует вызов инструмента, а реальная уязвимость возникает там, где приложение слишком сильно доверяет полученным параметрам.
Поэтому формулировка «мы написали модели, что ей нельзя это делать» не заменяет контроль прав.
Модель не должна выдавать права сама себе
| Задача | Разумный уровень доступа |
|---|---|
| Сообщить статус заказа | Чтение ограниченного набора данных |
| Найти свободный слот | Чтение расписания |
| Перенести запись | Изменение конкретной записи после проверки |
| Изменить чувствительные данные | Дополнительная авторизация или участие сотрудника |
| Массово изменить записи | Не должно быть доступно обычному пользовательскому диалогу |
В корпоративных проектах имеет смысл придерживаться принципа минимально необходимых полномочий. Если агенту требуется только читать один тип данных, ему не нужен полный доступ к системе.
Отдельный вопрос — размещение решения и контроль данных. Для компаний с повышенными требованиями к инфраструктуре у Neuro.net есть сценарии on-premise-развёртывания голосовых систем, когда обработка остаётся внутри корпоративного контура.
Какие данные нужно считать недоверенными
Очевидный источник — слова самого пользователя. Но для агентных систем этого мало.
Недоверенным входом может быть найденный документ, внешняя веб-страница, письмо, ответ API или информация, извлечённая из памяти.
Поэтому полезно разделять инструкции системы и внешние данные, проверять параметры вызовов и не позволять содержимому документа менять правила самого агента.
Когда требуется дополнительное подтверждение
Чем труднее отменить последствия действия, тем меньше оснований выполнять его только на основании свободного разговора.
Изменение персональных данных, подключение платной услуги, финансовая операция или другое чувствительное действие могут требовать повторного подтверждения, отдельной авторизации или передачи сотруднику.
NIST в работе по идентификации и полномочиям программных и AI-агентов отдельно рассматривает вопросы авторизации, аудита и защиты от prompt injection.
Эта логика хорошо сочетается с архитектурой AI-контакт-центра: агент может самостоятельно закрывать часть задач, но правила доступа к действиям должны задаваться конкретным бизнес-процессом.
Что нужно журналировать
Если AI способен выполнять действия, одной записи разговора уже мало.
Для разбора инцидента полезно понимать:
- какой запрос получил агент;
- какой инструмент решил использовать;
- какие параметры передал;
- какие проверки были выполнены;
- что вернула корпоративная система;
- каким оказался итог операции.
Особенно важно фиксировать высокорисковые действия и отклонённые попытки обращения к инструментам.
Как проверять голосового агента до запуска
Обычного успешного сценария недостаточно.
Нужно отдельно тестировать ситуации, когда пользователь пытается заставить систему нарушить правила, получить чужие данные, повторяет запрещённый запрос в разных формулировках или пытается представить инструкцию как часть обычной беседы.
Проверять стоит и косвенный сценарий: что произойдёт, если подозрительная инструкция попадёт из внешнего документа или сохранённого контекста.
Подготовка реальных данных и негативных сценариев вообще играет большую роль в голосовом AI. Об этом подробнее можно прочитать в материале о подготовке данных для голосового AI.
Что защищает AI-агента от prompt injection
Защита строится слоями: недоверенный ввод, минимальные права, проверка параметров действий, дополнительное подтверждение чувствительных операций, изоляция памяти и журналирование.
Если один уровень пропустил нежелательную инструкцию, следующий должен ограничить её последствия.
Поэтому безопасность голосового AI уже нельзя рассматривать только как защиту данных или выбор закрытого контура. Чем больше действий получает агент, тем важнее становится архитектура прав и контроля вокруг модели.
FAQ
Можно ли провести prompt injection голосом?
После распознавания голосовая реплика становится входом для AI-системы. Поэтому требования к обработке недоверенных инструкций применимы и к голосовому каналу.
Почему нельзя просто прописать запреты в системном промпте?
Промпт задаёт поведение модели, но права на данные и реальные операции должны контролироваться на уровне приложения и подключённых инструментов.
Нужно ли запрещать AI любые действия?
Нет. Для каждого инструмента имеет смысл выдавать только те права, которые необходимы конкретному сценарию, и отдельно защищать чувствительные операции.
Что такое косвенный prompt injection?
Это ситуация, когда вредоносная инструкция приходит не напрямую от пользователя, а внутри внешнего документа, страницы, сообщения или другого контента, который обрабатывает агент.
Нужно ли повторять тестирование после запуска?
Да. Изменение модели, набора инструментов, памяти или правил доступа может изменить поверхность риска системы.
