Локальный контур не делает найденный документ доверенным

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

OWASP ставит prompt injection на первое место в списке рисков для приложений с языковыми моделями. Организация отдельно подчёркивает: RAG и дообучение улучшают релевантность, но не устраняют уязвимость. NIST описывает косвенную инъекцию как атаку, при которой вредная инструкция заранее помещается в данные, которые приложение впоследствии найдёт и передаст модели. Атакующему не обязательно общаться с ассистентом напрямую.

Для малого и среднего бизнеса главный вывод прост: документ из почты, сайта, общего диска или базы знаний остаётся недоверенным вводом, даже если его загрузил сотрудник. Модель не должна получать право действовать только потому, что текст оказался релевантным запросу.

Как выглядит атака на RAG

Обычная цепочка состоит из шести шагов:

1. внешний файл попадает в почту, CRM, папку обмена или систему заявок;
2. конвейер извлекает текст, режет его на фрагменты и создаёт векторы;
3. пользователь задаёт безобидный вопрос;
4. поиск возвращает фрагмент с полезными фактами и скрытой либо явной инструкцией;
5. модель смешивает системные правила, вопрос и найденный текст в одном контексте;
6. ответ раскрывает лишние данные или агент предлагает опасный вызов инструмента.

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

Опасность возрастает, когда RAG соединён с агентом. Ошибочный ответ неприятен; ошибочная отправка письма, изменение цены, выгрузка клиентской базы или запуск команды уже меняют состояние бизнеса.

Архитектура из четырёх границ

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

Вторая — **доступ к знаниям**. Каждый фрагмент наследует права исходного документа. Поиск фильтрует результаты по роли и личности пользователя до передачи модели. Нельзя сначала найти всё, а затем попросить модель «не показывать лишнее»: модель уже увидит секрет.

Третья — **граница инструкций и данных**. Системный prompt прямо объявляет найденные фрагменты цитируемыми данными, а не командами. Контекст передаётся в структурированном поле с идентификаторами источников. Модель должна отвечать фактами со ссылками, игнорировать инструкции внутри документов и отказываться, когда подтверждения нет. Эта мера полезна, но сама по себе не является защитой.

Четвёртая — **шлюз действий**. Модель лишь предлагает вызов. Отдельный сервис проверяет пользователя, разрешённый инструмент, схему аргументов, область данных, лимиты и необходимость подтверждения. Токены и пароли хранятся в шлюзе, а не в prompt и не в коде, сгенерированном моделью.

Минимальные права для агента

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

Операции записи делят по риску:

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

Документация MCP рекомендует минимизировать области доступа, проверять токены на каждом маршруте и запускать серверы с ограниченным доступом к файловой системе, сети и другим ресурсам. Сессия не должна заменять аутентификацию. Для локального HTTP-транспорта необходима авторизация; где возможно, stdio или защищённый IPC уменьшают поверхность атаки.

Что журналировать

Разбор инцидента невозможен, если в логе остался только итоговый ответ. Для каждой операции сохраняют:

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

Сырые prompts могут содержать персональные данные и коммерческие секреты, поэтому журнал также требует разграничения доступа, срока хранения и маскирования. Для аналитики часто достаточно идентификаторов и обезличенных признаков, а полный контекст открывается только при расследовании.

Как проверить защиту за неделю

День 1: составьте карту источников и инструментов. Отметьте внешние документы, персональные данные, операции записи и владельцев процессов.

День 2: соберите тестовый набор из обычных документов и 50–100 инъекций: прямых, косвенных, многоязычных, в метаданных и внутри изображений. Добавьте случаи, где документ одновременно содержит полезный факт.

День 3: проверьте доступы. Пользователь отдела продаж не должен получать фрагменты финансового или кадрового индекса, даже если запрос семантически близок.

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

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

Дни 6–7: запустите теневой режим, измерьте ложные блокировки, пропущенные атаки и время проверки. Повторяйте набор после смены модели, prompt, парсера, источника или инструментов.

Модельная экономика защиты

Предположим, внутренний RAG обрабатывает 8 000 запросов в месяц. Без автоматизации сотрудник тратил бы три минуты на поиск; система экономит две минуты в 60% запросов, высвобождая 160 часов. При полной стоимости часа 1 000 рублей ресурсный эффект равен 160 000 рублей.

Шлюз инструментов, журналирование, контроль индекса и ежемесячные тесты стоят 70 000 рублей. Чистый модельный эффект — 90 000 рублей в месяц. Если пилот и защитный контур обошлись в 720 000 рублей, простой срок окупаемости составляет восемь месяцев.

Это пример, а не рыночная цена. Исключать защиту из расчёта нельзя: небезопасный агент не является более дешёвым решением, он просто переносит стоимость в будущий инцидент. Сравнивать следует безопасный автоматизированный процесс с текущим процессом, включая проверку человеком.

Что взять руководителю

Prompt injection нельзя «закрыть» одной инструкцией модели или антивирусом для текста. Нужны независимые барьеры: карантин источников, фильтрация по правам до retrieval, чёткая маркировка недоверенных данных, минимальные инструменты, отдельный шлюз действий и подтверждение человеком.

Практичный первый шаг — выбрать один RAG-сценарий и отключить все операции записи. За неделю проверьте 50–100 атакующих документов, права пользователей и журнал вызовов. Только после прохождения порогов добавляйте один узкий инструмент записи. Внутренняя модель защищает канал передачи данных, но безопасность решений создаёт архитектура вокруг неё.