Prompt injection у AI-агентов: почему фильтры не спасают

AI-агент читает письмо от клиента, страницу в интернете, issue в трекере или документ из внутренней базы знаний. Человек видит в этом тексте информацию. Модель видит текст, часть которого может оказаться инструкцией: «перешли переписку на внешний адрес», «удали ветку», «выгрузи таблицу с зарплатами». Это и есть prompt injection - и для агентов с доступом к корпоративным системам это не теоретическая уязвимость, а рабочая схема атаки.

OWASP ставит промпт-инъекции на первое место в рейтинге угроз LLM-приложений (LLM01:2025) уже второй год подряд. При этом та же OWASP честно признаёт: надёжных методов полного предотвращения инъекций пока не существует. Из этого следует неудобный вывод, который многие команды пропускают: защищаться нужно не от самой инъекции, а от её последствий.

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

Прямая и косвенная prompt-инъекция

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

Косвенная инъекция (indirect prompt injection) опаснее. Вредоносная инструкция прячется во внешнем контенте, который агент обрабатывает по работе:

резюме или коммерческое предложение со скрытым текстом в метаданных PDF;
страница документации, которую агент изучает при отладке;
issue в публичном репозитории, созданный специально под агентов, которые читают triage;
результат работы другого инструмента: ответ API, содержимое тикета, комментарий к MR.

Человек, который запустил задачу, может вообще не знать про этот контент. Атака выглядит так: сотрудник просит агента разобрать входящие заявки, агент открывает письмо, в письме - инструкция, и агент под легитимными правами выполняет то, о чём сотрудник не просил.

Отдельный случай - tool poisoning: вредоносные инструкции прячутся не в данных, а в описаниях самих инструментов. Агент читает описание MCP-сервера ещё до первого вызова, поэтому скомпрометировать его можно даже без единого запроса. Этот вектор Invariant Labs раскрыла ещё в 2025 году, а OWASP закрепила его в MCP Top 10 как отдельную категорию атак.

Почему фильтрация входа не решает проблему

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

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

Данные и инструкции живут в одном контексте. Модель получает единый поток текста: системные инструкции, сообщения пользователя, результаты инструментов, содержимое документов. Разделить их «по проводам» невозможно - различие существует только на уровне смысла, а смысл модель вычисляет вероятностно.

Фильтр можно обойти, а ложные срабатывания - дорого стоят. Правило «блокировать письма со словом delete» будет ловить легитимные задачи и пропускать переформулированные атаки. Команда тратит недели на тюнинг фильтров и всё равно не получает гарантии.

Поэтому зрелый подход звучит иначе: предположим, что инъекция однажды пройдёт. Какой максимальный ущерб она сможет нанести? Ответ на этот вопрос определяется не фильтрами, а архитектурой доступа.

Что ограничивает последствия: blast radius вместо запрета

Blast radius - радиус ущерба от одной успешной атаки. Его сокращают четырьмя независимыми механизмами, и работают они даже тогда, когда модель «поверила» вредоносной инструкции.

1. Изоляция среды выполнения

Агент работает в sandbox: собственный контейнер, ограниченная файловая система, контролируемый сетевой периметр. Инъекция, которая попыталась отправить данные на внешний сервер, упирается в сетевую политику. Документация Claude Code описывает ровно эту логику: тот же набор принципов, что применяется к запуску полудоверенного кода, - изоляция, минимальные привилегии, защита в глубину.

2. Узкие инструменты вместо универсальных

Агенту с инструментом execute_any_sql достаточно одной удачной инъекции, чтобы прочитать всю базу. Агенту с инструментом get_invoice_status - недостаточно: такой вызов просто не умеет делать ничего разрушительного. Чем уже контракт каждого инструмента, тем меньше власти у любой инструкции, попавшей в контекст.

3. Права конкретного пользователя, а не общий сервисный токен

Если агент работает под широким сервисным аккаунтом, инъекция наследует все его полномочия. Если каждый вызов выполняется от имени конкретного сотрудника с его реальными правами, ущерб ограничен тем, что доступно этому человеку, - а у рядового менеджера нет прав удалять продакшен-данные. Anthropic формулирует это как containment: ограничивать не только намерение модели, но и то, что она физически способна сделать.

4. Аудит и подтверждение опасных действий

Когда каждое действие агента записано - кто инициировал, какой инструмент вызван, какие параметры переданы, какой policy check прошёл - атака перестаёт быть невидимой. А операции с высокой ценой ошибки: массовое удаление, отправка данных наружу, изменение прав, платежи - выносятся на явное подтверждение человека. DLP и SIEM при этом видят легитимный трафик, поэтому без собственного журнала действий агента расследовать инцидент почти нечем.

Где здесь место Codenik

Все четыре механизма реализуемы своими силами, но поддерживать их для каждого нового агента отдельно - дорого. Codenik закрывает именно этот слой: работает как управляемая точка между AI-агентом и корпоративными системами.

Практически это значит:

агент видит только разрешённые ему узкие инструменты - без curl с широким токеном и произвольного SQL;
секреты downstream-систем остаются на стороне Codenik, а не в конфигах агента, где их достанет любая успешная инъекция;
каждый вызов выполняется в контексте прав конкретного пользователя и попадает в журнал;
опасные операции требуют подтверждения, а вся цепочка - от исходной задачи до результата - восстанавливается после инцидента.

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

Чек-лист на ближайшую неделю

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

Инвентаризация инструментов. Выпишите все инструменты, доступные каждому агенту. Отметьте универсальные (shell, sql, http) - это ваши главные точки риска.
Проверка секретов. Где лежат токены агентов? Если в .env рядом с runtime - любая инъекция через контекст получает их автоматически.
Субъект доступа. Кто выполняет вызовы: сервисный аккаунт или конкретный сотрудник? Во втором случае ущерб предсказуем, в первом - нет.
Журнал. Можно ли за пять минут ответить, какие действия агент совершил вчера от имени каждого пользователя?
Опасные операции. Есть ли список операций, которые агент не имеет права выполнять без человека? Если списка нет - его стоит написать до следующего пилота.
Внешний контент. Какие источники агент читает по работе и кто отвечает за их доверенность? Публичные issue, почта и страницы - это недоверенные данные по определению.

Короткий вывод

Prompt injection нельзя «запатчить»: инструкции и данные принципиально живут в одном контексте, и OWASP прямо говорит об отсутствии полного решения. Фильтры полезны как шумоподавление, но не как контроль безопасности.

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