Как защитить ИИ-агента от prompt injection: пошаговый план

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

Шаг 1. Разделите источники

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

Шаг 2. Сузьте инструменты

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

Шаг 3. Добавьте подтверждение

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

Шаг 4. Проведите атаки

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

Шаг 5. Отслеживайте отказ

Хороший агент объясняет, что контент недоверенный, и возвращает управление человеку. Молчаливое выполнение и бесконечные повторы считаются провалом.

Шаг 6. Закрепите правила

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

FAQ

Как ограничить инструменты агента?

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

Как понять, что пилот удался?

Сравнить время до принятого результата, ошибки и стоимость с прежним процессом.

Что делать при регрессии?

Остановить расширение, сохранить трассу и вернуть проверенную конфигурацию.

Что почитать дальше

Связанные материалы: гайд по replay-тестам, обзор MAI-Transcribe-2 и каталог инструментов.

Карта доверия

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

Тест отказа

Подготовьте набор атак, которые выглядят правдоподобно: «срочно оплатить счёт», «отправить файл новому адресу», «удалить старую запись». Разместите их в тексте, метаданных и вложении. Ожидаемый результат — агент сообщает о конфликте, показывает источник и ждёт человека. Проверьте также повторную попытку и смену языка.

Наблюдаемость

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

Запуск

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

Практический сценарий

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

Рабочая заметка редакции

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