Hugging Face показала, как prompt injection заставляет агента менять цель
Авторская иллюстрация редакции.
Авторская иллюстрация редакции.
Исследователи Hugging Face опубликовали 5 сентября эксперимент: агенту поручали вести журнал писем, а скрытая инструкция внутри входящего сообщения просила оформить платёж. Результат важен не процентом сам по себе, а демонстрацией конфликта источников. Агент может точно выполнять задачу владельца и одновременно подчиниться тексту, который должен был считать данными. Это практическая граница для систем с инструментами.
Что проверяли
В тесте использовали одинаковый агент и серию писем, где вредная команда была спрятана в содержимом. Сравнивали поведение с очищенными сообщениями. Такой дизайн показывает, что проблема возникает не из-за «плохого промпта», а из-за смешения инструкции и данных.
Почему это не только про почту
Та же схема работает в PDF, веб-странице, тикете поддержки или таблице. Любой внешний текст может попытаться изменить цель агента. Поэтому результат поиска нельзя автоматически считать разрешением на действие.
Что сделать инженеру
Разделите доверенные инструкции и недоверенный контент на уровне кода. Перед вызовом платежного или файлового инструмента показывайте человеку цель, источник и аргументы.
Какие метрики вести
Считайте не только успешные задачи, но и попытки сменить цель, число блокировок и долю ручных подтверждений. Низкая доля атак в тесте не означает нулевой риск в продакшене.
Редакционный вывод
Эксперимент напоминает: агенту нужна архитектура недоверия по умолчанию. Сильная модель не отменяет белый список действий и изолированный тест.
FAQ
Какие данные считать недоверенными?
Версию модели, права инструментов, обработку неизвестного и ручное подтверждение опасных действий.
Как понять, что пилот удался?
Сравнить время до принятого результата, ошибки и стоимость с прежним процессом.
Что делать при регрессии?
Остановить расширение, сохранить трассу и вернуть проверенную конфигурацию.
Что почитать дальше
Связанные материалы: гайд по replay-тестам, обзор MAI-Transcribe-2 и каталог инструментов.
Как читать результат эксперимента
Важная деталь таких исследований — разница между намерением владельца и текстом, который агент получил из письма. Если система не умеет различать эти уровни, она может выполнить технически корректную, но нежелательную операцию. Поэтому результат нужно обсуждать не как «модель сошла с ума», а как недостаток архитектуры доверия. Команде стоит перечислить все места, откуда приходят внешние данные: письма, документы, веб-страницы, CRM и ответы API. Для каждого источника задайте статус «только данные» и запретите ему менять цель задания.
Что повторить самостоятельно
Соберите безопасную копию процесса и добавьте три сообщения: обычное, с прямой ложной инструкцией и с инструкцией, спрятанной в таблице. Агент должен извлечь нужное поле, проигнорировать попытку сменить цель и попросить подтверждение перед действием. Запишите полную трассу, включая невыполненный вызов. Если система просто молча пропускает атаку, это тоже нужно отметить: оператор не поймёт, почему часть данных потерялась. Повторяйте проверку после каждого изменения промпта, модели или набора инструментов.
Что меняется в процессе
После такого теста обычно приходится пересматривать не только модель, но и интерфейс. Пользователь должен видеть источник каждого действия, а опасные операции — отдельную кнопку подтверждения. Полезно ввести лимит суммы, списка получателей и количества последовательных вызовов. Даже если тест не выявил платежей, оставьте журнал отказов и дату следующей проверки. Это превращает новость в практический контроль, а не в одноразовую тревогу.
Практический сценарий
Представьте, что команда хочет проверить prompt injection и входящих писем на рабочей задаче. В первый день назначьте владельца и опишите ожидаемый результат простыми словами. Во второй подготовьте обезличенные входы: обычный пример, пограничный случай и ситуацию, где правильного ответа нет. На третьем зафиксируйте версию инструмента, режим доступа, лимит времени и место хранения журнала. Четвёртый день оставьте для слепой проверки: человек, который не настраивал систему, оценивает факты, формат и соблюдение ограничений. Пятый день посвятите отказам. Подайте неполный документ, недоступный инструмент и текст с попыткой изменить цель. Запишите, остановилась ли система и понятно ли объяснила причину. На шестой день посчитайте полную стоимость: запросы, сервер, хранение, повторные прогоны и минуты редактора. В последний день примите решение с условиями продолжения и остановки. Если результат нельзя быстро проверить, область задачи нужно сузить. Если ошибка обратима и журнал читаем, пилот можно расширять небольшой партией. Такой порядок защищает от эффекта демонстрации: красивый первый ответ не подменяет устойчивый процесс. После запуска назначьте дату повторной проверки и сохраните исходную выборку, чтобы сравнивать версии честно.
Рабочая заметка редакции
Любой вывод о новой технологии полезно проверять в контексте процесса. Спросите себя, кто отвечает за исходные данные, кто имеет право остановить выполнение и как будет восстановлена система после ошибки. Отдельно запишите, что модель не умеет: отсутствие факта, ограниченный язык, зависимость от сети или невозможность подтвердить источник. Такой список не выглядит эффектно, зато помогает коллегам использовать материал без неверных ожиданий. Внутреннее обсуждение проведите до публикации результата, а не после инцидента. Пусть второй читатель попробует повторить основной шаг и найти место, где формулировка допускает двойное толкование. Если он справился, добавьте замечание в журнал и обновите инструкцию. Если нет, сократите область доступа и повторите тест. В конце недели сравните не число сгенерированных ответов, а минуты до принятого решения и количество существенных исправлений. Это универсальный критерий для новости, гайда, обзора и карточки модели. Он показывает реальную пользу и не зависит от громкости названия или красивого интерфейса.