Prompt-инъекции: что это, чем опасны и как защитить агентов

Prompt-инъекция — это атака, при которой вредоносные инструкции прячут не в вашем сообщении, а внутри контента, который ИИ-агент читает по ходу работы: веб-страница, PDF, письмо, тикет, комментарий, вывод инструмента. Расчёт на то, что модель не отличит «данные, которые надо проанализировать» от «команд, которые надо выполнить», и послушается текста из источника вместо вас. Это самый верхний пункт в OWASP Top 10 для LLM-приложений (LLM01) — и пока без полного решения: фильтры, RAG и дообучение снижают риск, но не закрывают его.

Руководство покрывает обе стороны: что важно знать обычному пользователю агентов и как выстроить защиту тому, кто эти агенты настраивает.

Что такое prompt-инъекция

Языковая модель получает на вход один поток текста: системную инструкцию, ваш запрос и любой подтянутый контент. Внутри этого потока нет жёсткой границы «вот это приказы, а вот это просто данные» — всё это просто токены. Prompt-инъекция эксплуатирует именно это: атакующий вставляет в данные текст, который выглядит как команда, и модель может принять его за инструкцию.

NIST формулирует это так: инъекция «переопределяет» системную инструкцию, эксплуатируя склейку недоверенного ввода с доверенным системным промптом, чтобы вызвать непредусмотренное поведение.

Ключевое следствие, которое часто недооценивают: инъекция не обязана быть видимой человеку. Достаточно, чтобы её распарсила модель. Белый текст на белом фоне, скрытый блок, символы нулевой ширины, текст в alt-атрибуте картинки — для вас этого на странице не видно, а модель прочитает.

Инъекция против джейлбрейка

Эти термины часто путают, но различать их полезно.

Грубо: джейлбрейк ломает «нельзя» внутри модели, а инъекция перехватывает поведение через подсунутый контент. По формулировке OWASP, джейлбрейк — это форма prompt-инъекции, при которой модель полностью игнорирует свои защитные протоколы.

Важная оговорка: OWASP относит джейлбрейк к формам инъекции, но часть исследователей (в их числе Саймон Уиллисон) проводит более резкую границу — инъекция бьёт по архитектуре приложения (границе «инструкция/данные»), а джейлбрейк — по слою безопасности самой модели. На практике это пересекающиеся, но не строго вложенные категории.

Анатомия атаки

Любая инъекция проходит через четыре шага:

1. Источник. Атакующий контролирует данные, которые агент прочитает: страницу сайта, репозиторий, письмо, тикет, документ, сообщение в чате, описание PR.
2. Доставка. Эти данные попадают в контекст модели штатным путём — агент сам их подтянул, потому что это его работа (суммаризировать страницу, разобрать тикет, проверить PR).
3. Срабатывание. Модель интерпретирует вставленный текст как инструкцию.
4. Цель. Утечка данных (эксфильтрация), несанкционированное действие (отправка письма, коммит, удаление), искажение ответа или тихий саботаж.

Главная коварность: на шаге 2 ничего «не взламывается» в классическом смысле. Агент делает ровно то, для чего создан, — читает контент. Поэтому это не лечится санитизацией как SQL-инъекция: естественный язык нельзя «обезвредить», не убив саму функцию.

Виды инъекций

Прямые и непрямые

• Прямая инъекция — вредоносный текст в самом запросе пользователя (часто это и есть джейлбрейк).
• Непрямая (indirect / data-borne) — самая опасная для агентов: инструкции лежат во внешнем источнике, который модель потребляет. Microsoft описывает риск прямо: атакующий подсовывает специально сделанные данные, которые LLM принимает за инструкции, а последствия — от утечки данных пользователя до действий под его правами.
• Хранимая (stored) — подвид непрямой: вредоносный промпт оседает в памяти агента, в базе RAG или в обучающих данных и срабатывает позже.

Техники маскировки

На что смотреть в исходнике подозрительной страницы или документа:

• белый текст на белом фоне, font-size: 0, opacity: 0;
• скрытые элементы (display:none, visibility:hidden, off-screen, aria-hidden);
• HTML-комментарии <!-- ... -->;
• атрибуты alt, title, aria-label у картинок и ссылок;
• символы нулевой ширины и хитрый Unicode;
• закодированный текст (base64, URL-encoding, HTML-entities), который выглядит мусором, но декодируется в команды.

Типовые цели

Живые примеры

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

Notion и «смертельная троица». В сентябре 2025 года исследователи CodeIntegrity (Abi Raghuram) показали атаку на агентов Notion 3.0: PDF со скрытым белым текстом на белом фоне подталкивал агента (на Claude Sonnet 4) использовать инструмент веб-поиска, чтобы вывести приватные страницы на сервер атакующего — классический сценарий эксфильтрации. На разбор сослался и Simon Willison.

Claude Code GitHub Action. В июне 2026 Microsoft Threat Intelligence показала, как агент, обрабатывающий недоверенный GitHub-контент (тело issue, описание и комментарии PR), мог быть подведён к чтению переменных окружения и утечке секретов CI/CD. Урок: в агентных пайплайнах любой пользовательский ввод (issue, PR, комментарий) — это недоверенный источник.

Почему агенты особенно уязвимы: «смертельная троица»

Чистый чат-бот без инструментов инъекцией испортить можно, но ущерб ограничен текстом. У агента есть инструменты — и вот тут появляется реальная опасность.

Исследователь Simon Willison описал «смертельную троицу» (lethal trifecta) — три свойства, опасные именно в комбинации:

1. Доступ к приватным данным (ваша почта, файлы, база, репозитории).
2. Чтение недоверенного контента (веб, письма, тикеты — куда атакующий может что-то вписать).
3. Возможность отправить данные наружу (отправка письма, запрос к внешнему URL, публикация).

К этому добавляется избыточная агентность (OWASP LLM06): чем больше у агента прав и автономии, тем выше цена успешной инъекции. Цепочки субагентов, MCP-серверы и сторонние плагины расширяют поверхность атаки.

Как защищаться — пользователю

Вы не обязаны строить систему, но несколько привычек резко снижают риск:

• Считайте внешний контент данными, а не приказами. Не просите агента «прочитай эту страницу и сделай, что там написано».
• Давайте чувствительные права точечно. Не подключайте агенту всю почту/диск/репозитории «на всякий случай».
• Держите подтверждение на опасных действиях (отправка, удаление, публикация, трата денег) — не включайте общий auto-approve.
• Проверяйте источники. Подозрительную страницу смотрите в исходнике (View Source / DevTools), ищите скрытый или закодированный текст.
• Разрывайте троицу. Если агент читает недоверенный контент — не давайте ему одновременно и приватные данные, и канал наружу.
• Не пересылайте «вслепую». Прежде чем дать агенту переслать или опубликовать его вывод, просмотрите содержимое.

Как защищаться — тому, кто строит агентов

Здесь работает только глубокая оборона (defense in depth): ни один слой не закрывает проблему сам по себе (Microsoft, OpenAI).

1. Проектируйте так, чтобы успешная инъекция мало что давала

Ключевая идея от OpenAI: цель не в том, чтобы идеально ловить все вредоносные вводы, а в том, чтобы ограничить ущерб, даже если манипуляция удалась. Стройте систему вокруг этого.

2. Минимум привилегий (least privilege)

• Давайте агенту доступ только к тем данным и инструментам, которые нужны для задачи.
• Сегментируйте права по пользователю/роли, избегайте «щедрых» дефолтов.
• Сначала оцените blast radius: какие источники доступны и каков максимальный ущерб при компрометации одного из них.

3. Человек в контуре (human-in-the-loop)

Чувствительные и необратимые действия (отправка наружу, удаление, деплой, оплата) — только через явное подтверждение человека, а не на усмотрение модели.

4. Разделяйте инструкции и данные на уровне архитектуры

Самый перспективный подход — не фильтровать «плохой текст», а лишать недоверенные данные возможности влиять на ход программы. Это идея CaMeL от Google DeepMind и ETH Zürich: control- и data-flow извлекаются из доверенного запроса, а недоверенные данные физически не могут переключить логику; права (capabilities) ограничивают, куда вообще можно отправить данные (разбор).

5. Изоляция и песочницы

• Запускайте инструменты с побочными эффектами в изолированном окружении.
• Скрабьте переменные окружения и секреты из контекста, доступного агенту (урок кейса с GitHub Action).
• Автономные режимы — только в чистых ветках и временных окружениях.

6. Контроль вывода (improper output handling, OWASP LLM05)

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

7. Детектирование и мониторинг

Специализированные детекторы инъекций, поведенческий мониторинг, аномалии — полезны как слой, но это реактивная мера, не замена архитектуре.

8. Провенанс и стоп-линии

Отмечайте источник данных (откуда пришёл контент и какой у него уровень доверия). Прописывайте явные стоп-линии: чего агент не делает никогда.

Как это настроено у меня

Чтобы было предметно — вот принципы, по которым я работаю с этим риском:

• Внешний и рабочий контент по умолчанию недоверенный. Страницы, результаты поиска, заметки со встреч, комментарии — я их анализирую и цитирую, но не исполняю инструкции оттуда.
• Команды принимаю от вас и явных источников инструкций. Текст «сделай то-то», найденный внутри страницы или тикета, для меня данные, а не приказ, — пока вы прямо не попросите это выполнить.
• Слежу за уровнем доступа (bucket). Если действие переносит контент из более закрытого места в более открытое (приватное → командное → рабочее пространство → публичное), я останавливаюсь и спрашиваю подтверждение.
• Настораживаюсь на типичные признаки инъекции. Если страница «просит» опубликовать что-то, скрыть это от вас или пропустить подтверждение — я отношусь к этому как к вероятной атаке и переспрашиваю.
• Загрузчик страниц обезвреживает явные инъекции до того, как текст дойдёт до меня (как в примере выше — я получил пометку вместо полезной нагрузки).

Это ровно та логика «контент — это данные» и «подтверждение на расширение доступа», о которой речь в разделе для архитекторов.

Чеклист безопасности

Пользователю:

Архитектору:

Глоссарий

• Prompt-инъекция — подмешивание вредоносных инструкций во ввод или сторонний контент.
• Джейлбрейк — инъекция, нацеленная на обход правил безопасности модели.
• Непрямая (indirect) инъекция — инструкции в данных, которые агент читает штатно.
• Эксфильтрация — скрытый вывод приватных данных наружу.
• Смертельная троица — приватные данные + недоверенный контент + канал наружу в одном агенте.
• Least privilege — выдача минимально необходимых прав.
• Human-in-the-loop — обязательное участие человека в чувствительных действиях.
• Провенанс — происхождение и уровень доверия данных.
• Defense in depth — многослойная защита без опоры на один механизм.

Полезные ссылки и источники

• OWASP Top 10 для LLM — LLM01: Prompt Injection: genai.owasp.org/llmrisk/llm01-prompt-injection
• OWASP Top 10 для LLM (обзор 2025): genai.owasp.org/llm-top-10
• NIST AI 100-2e2025, Adversarial Machine Learning: csrc.nist.gov (PDF)
• Simon Willison — The lethal trifecta: simonwillison.net/2025/Jun/16/the-lethal-trifecta
• CodeIntegrity — The Hidden Risk in Notion 3.0 AI Agents: codeintegrity.ai/blog/notion
• Google DeepMind & ETH Zürich — CaMeL: Defeating Prompt Injections by Design: arxiv.org/abs/2503.18813
• Microsoft — How Microsoft defends against indirect prompt injection: microsoft.com/en-us/msrc/blog
• OpenAI — Designing AI agents to resist prompt injection: openai.com/index/designing-agents-to-resist-prompt-injection
• Microsoft Security — Claude Code GitHub Action case (2026): microsoft.com/en-us/security/blog

По теме

• База знаний: Claude Code — кодинг-агент от Anthropic

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

Если захотите обсудить, как применить это у себя или в команде — пишите в Telegram @pimenov