Защита AI-агента от prompt injection: документы, права и действия

Что такое prompt injection в рабочем процессе

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

В описании OWASP Prompt Injection различаются прямое воздействие через запрос и косвенное воздействие через внешнее содержимое. Там же отмечено, что использование RAG или дополнительного обучения само по себе не устраняет эту уязвимость. Поэтому качество ответов и безопасность действий нужно рассматривать как разные задачи.

Для бизнеса последствия зависят от возможностей агента. Помощник, который только готовит черновик, и агент, способный отправлять письма или менять CRM, имеют разный уровень риска. Ошибочный текст можно заметить при чтении. Ошибочное действие может уже изменить данные или раскрыть информацию. Защиту следует проектировать вокруг конкретного процесса, а не абстрактного «безопасного AI».

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

Документ сообщает факты, но не выдаёт полномочия

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

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

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

Ограничения должны работать вне модели

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

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

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

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

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

Подтверждение должно относиться к конкретному действию

Для значимых операций предусмотрите проверку человеком. Экран подтверждения должен показывать действие, объект, изменяемые данные или получателя. Общая кнопка «Продолжить» без содержания не даёт сотруднику возможности оценить последствия. Важно, чтобы текст проверки формировался из фактических параметров операции, а не только из объяснения модели.

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

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

Как организовать работу с базой знаний

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

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

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

Как безопасно проверить устойчивость процесса

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

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

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

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

Что делать при подозрительном поведении

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

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

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

Защита от prompt injection начинается с вопроса, что агент вообще может сделать. Инструкции модели важны, но наиболее существенные ограничения должны оставаться проверяемыми свойствами приложения. Такой подход помогает сохранить полезность AI и уменьшить последствия ошибок при работе с неоднородными документами и внешними источниками.