Почему ИИ-агенты уязвимы к prompt injection и как защитить их на уровне архитектуры

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

Ключевая проблема: ИИ-агенты объединяют то, что всегда было разделено — плоскость управления (control plane) и плоскость данных (data plane). В обычном приложении команда пользователя обрабатывается детерминированным кодом, и данные не могут переписать логику. В LLM-системе любой текст в контекстном окне потенциально влияет на поведение модели.

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

Принцип 1: Разделение доверия как архитектурный примитив

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

Система работает не со склеенными строками промпта, а с типизированными блоками контекста. Каждый блок получает метаданные о происхождении (provenance) и уровень доверия: системные инструкции — trusted, данные из внутренней БД — internal, внешний контент и RAG-документы — untrusted. Инструменты проверяют эти метки перед выполнением.

ОWASP называет это «segregation of trust» и в 2026 году подчеркивает, что это уже не просто хорошая практика, а архитектурное требование.

Принцип 2: Изоляция инструментов и минимальные полномочия

Опасная архитектурная ошибка — предоставление LLM доступа к инструментам с избыточными правами. Это может быть инструмент для чтения, способный удалять документы, или подключение к БД с правами администратора, когда нужен только SELECT. Решение: каждому инструменту — минимально необходимый набор прав и изолированный контекст выполнения.

Вместо передачи модели SQL-запросов система принимает структурированные параметры (таблица, фильтры, лимит) и сама строит параметризованный запрос. Это исключает целый класс атак на injection. Избегайте open-ended функциональности вроде выполнения shell-команд или произвольных URL-запросов. Используйте гранулярные инструменты с ограничениями: файловые инструменты пишут только в конкретную директорию и только с определенным расширением, email-инструменты отправляют только на адреса из разрешенного списка.

Принцип 3: Контроль памяти и RAG-корпуса

RAG-корпус — часть поверхности атаки, часто более опасная, чем сам промпт. Исследование WARP показало: можно внедрить «отравленные» документы в поисковый корпус, и при триггере RAG будет извлекать именно их. Исследование AgentPoison успешно в 82% случаев при частоте отравлений менее 0.1% — одного вредоносного документа на тысячу может быть достаточно.

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

Принцип 4: Human-in-the-loop как архитектурный компонент

Это не UI-фича с кнопкой подтверждения, а встроенный в runtime компонент. Действия классифицируются по уровню риска: LOW (read-only, внутренние данные), MEDIUM (write в sandbox, внутренние уведомления), HIGH (delete, external API calls, финансовые операции). Для HIGH-risk действий требуется подтверждение — агент не может их обойти.

Реальные инциденты подтверждают необходимость: CVE-2025-32711 (EchoLeak) — prompt injection в Microsoft Copilot с zero-click эксфильтрацией данных, CVE-2025-54135 и CVE-2025-54136 — RCE через prompt injection в MCP реализации Cursor IDE. Все они стали результатом архитектурных ошибок, а не недостатков модели.

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