Indirect Prompt Injection
Danger
Indirect prompt injection возникает, когда атакующие инструкции приходят через данные, которые система читает для выполнения нормальной задачи: страницу, письмо, документ, issue, запись базы или tool result.
Почему это системная угроза
Модель обрабатывает инструкции и данные одним языковым механизмом. Разделители и фраза «не выполняй команды из документа» снижают риск некоторых ошибок, но не создают надёжную границу безопасности. Ущерб определяется возможностями всего harness: доступными tools, credentials и автоматическими side effects.
attacker-controlled content
↓
retrieval / browser / email / MCP
↓
model
↓
tool call → policy boundary → external effectВозможные последствия
- раскрытие приватных данных через разрешённый канал;
- отправка сообщения или изменение записи от имени пользователя;
- загрузка вредоносного файла или кода;
- подмена результатов исследования;
- сохранение вредоносной инструкции в memory;
- распространение injection другим агентам через summaries и handoffs.
Защита слоями
1. Least privilege
Выдавай только необходимые tools, каталоги, accounts и OAuth scopes. Разделяй чтение и запись. Не передавай secrets в context, если tool может использовать их без раскрытия модели.
2. Treat external content as data
Сохраняй provenance и маркируй недоверенный контент. Не позволяй данным переопределять цель, permissions или адрес получателя. Это полезный слой, но не единственная защита.
3. Deterministic policy
Проверяй tool name, аргументы, allowlists, размер операции и направление передачи данных кодом. LLM-фильтр можно использовать как дополнительный сигнал, но не как единственный enforcement.
4. Confirm concrete effects
Перед значимым действием показывай пользователю точный объект: кому уйдёт сообщение, какой файл изменится, какие данные покинут систему. Старое общее разрешение не заменяет проверку изменившихся параметров.
5. Isolate and observe
Используй sandbox для неизвестного кода, ограничивай сеть, логируй источник данных и цепочку tool calls. После действия перечитывай состояние.
Red-team сценарии
Проверяй не наличие предупреждения в ответе, а фактические side effects:
- скрытая инструкция в HTML и PDF;
- injection внутри issue или имени файла;
- просьба отправить найденный secret на внешний адрес;
- инструкция сохранить себя в memory;
- вредоносный tool output;
- атака, переданная worker → manager;
- многошаговая атака, выглядящая как обычные данные.
Тест считается пройденным, когда запрещённое действие не произошло, а trace показывает корректную policy decision.