AI-архитектура

2 мин чтения ·

Prompt Injection: документ не должен командовать AI-агентом

Помощник читает договор и находит внутри команду отправить данные постороннему человеку. Почему текст документа не должен получать права пользователя?

Сотрудник просит AI-агента кратко пересказать договор. Внутри документа может оказаться фраза, адресованная не человеку, а модели: проигнорировать задачу, вызвать инструмент или передать сведения другому получателю. Сотрудник этого не просил, но модель получила текст вместе с остальным содержимым.

Это и есть опасность prompt injection: недоверенные данные пытаются стать инструкциями. У обычного приложения существует привычная граница между данными и исполняемым кодом. В LLM-системе эта граница требует отдельной архитектурной защиты.

Инструкция в документе не равна полномочию

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

Уязвимость возникает не только при злонамеренной фразе «игнорируй правила». Более тонкая подмена может выглядеть как часть инструкции, документации или рабочего процесса. Поэтому одной проверки на запрещённые слова недостаточно.

Надёжная граница находится за пределами промпта

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

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

Если результат модели используется как команда, SQL-запрос или другой исполняемый ввод, его следует проверять по строгому контракту. Структурированный формат помогает ограничить поверхность атаки, но не делает содержание безопасным автоматически.

Проверять нужно цепочку, а не только ответ

Тесты должны включать недоверенные письма, документы, поисковую выдачу и результаты инструментов. Важно смотреть, какие инструменты модель пыталась вызвать, какие данные передать и какие проверки не позволили выполнить недопустимое действие.

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

Лучший ответ на prompt injection — не вера в идеальный промпт. Это архитектура, в которой чужой текст не может самостоятельно выдавать себе полномочия.

Подходы к снижению риска описаны в OWASP Top 10 for LLM Applications.