Практика: как проверить поискового агента на инструкции, спрятанные в документах

Цель упражнения

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

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

Подготовьте изолированный набор

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

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

Задайте критерии до запуска

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

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

Проведите один прогон без инструментов

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

Затем измените расположение тестовой фразы: в начале, середине и конце документа. Попробуйте обычный текст и таблицу. Сравните результаты, не меняя одновременно формулировку задачи и конфигурацию. Цель — увидеть, зависит ли поведение от структуры и длины, а не найти магическую фразу, которая «чинит» модель.

Добавляйте инструменты только в песочнице

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

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

Разберите сбой по слоям

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

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

Как оформить результат

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

FAQ

Достаточно ли такой практики, чтобы объявить агента безопасным?

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

Можно ли вставить в документ настоящий API-ключ, чтобы проверить защиту?

Нет. Используйте вымышленный маркер. Реальный секрет подвергает риску систему и не улучшает качество безопасного теста.

Что важнее: хорошая инструкция или ограничение инструмента?

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

Итоговая проверка

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