RAG и prompt injection: защита от вредных документов

Ограничьте происхождение и права источников

Индексируйте только источники с понятным владельцем, назначением и политикой обновления. Для каждого документа храните внутренний ID, версию, уровень доступа, время загрузки и безопасный hash, но не делайте текст доступным всем пользователям поиска. Перед выдачей chunk ваш backend обязан отфильтровать его по правам текущего пользователя и проекту. Векторная близость не отменяет ACL: похожий документ из другой команды не становится допустимым контекстом.

Новые загрузки полезно помещать в карантин до проверки типа файла, размера, OCR и владельца. Не позволяйте документу менять системную инструкцию, конфигурацию endpoint, список инструментов или политику хранения. Подозрительные фразы сами по себе не доказывают атаку, но являются поводом для пометки, ручной проверки или исключения из production-индекса. Не отправляйте в RAG секреты, upstream key, cookie, пароли, коды подтверждения или необработанные персональные данные.

Отделяйте контекст от правил приложения

В prompt явно маркируйте retrieved content как недоверенный материал и задавайте неизменяемую server-side политику: отвечать только по разрешённым источникам, не выполнять инструкции из документов и честно обозначать отсутствие доказательства. Но текстовая инструкция — лишь дополнительный барьер. Она не должна быть единственным контролем, потому что модельный вывод остаётся вероятностным. Важные действия нельзя выбирать по ответу модели без независимой проверки.

Сократите контекст до релевантных фрагментов с источником и версией. Большая выдача повышает шанс, что вредная или устаревшая часть повлияет на ответ. Для вопросов без покрытия разрешите безопасный отказ и ссылку на владельца базы знаний вместо обобщения из памяти модели. Оцените эту ветку отдельными тестами: она важна так же, как и правильное нахождение ответа. Метрики поиска и непокрытые вопросы разобраны в оценке RAG.

Проверяйте действия вне модели

Если RAG предлагает tool call, модель передаёт только предложение. Сервер сверяет имя инструмента с allowlist, права пользователя, типы аргументов, лимит, цель и ожидаемый побочный эффект. Для удаления, отправки письма, изменения биллинга или выгрузки данных добавьте явное подтверждение пользователя и отдельную бизнес-проверку. Никогда не превращайте свободный текст из документа в SQL, shell-команду, URL или разрешение на доступ без строгой схемы и серверной валидации.

Сохраняйте безопасный аудит решения: внутренний request ID, выбранный документ, версию политики, имя разрешённого инструмента и итоговый статус. Не пишите prompt целиком, токен Authorization или содержимое секретной базы. При неопределённой ситуации возвращайте контролируемый отказ. Избыточный retry не делает рискованный tool call безопасным; он может только повторить побочный эффект. Разбор function calling и схемы доступен в тесте tools.

Тестируйте защиту и готовьте остановку

Соберите обезличенный red-team набор: документ с просьбой раскрыть секрет, поддельная «системная» инструкция, конфликтующие версии политики, ссылка на запрещённое действие и вопрос без источника. Для каждого кейса зафиксируйте ожидаемый безопасный результат: отказ, цитата без выполнения, исключение источника или запрос подтверждения. Прогоняйте набор при изменении retrieval, модели, шаблона, инструментов или прав доступа. Удачный один раз отказ не доказывает универсальную безопасность.

Наблюдайте агрегированные сигналы: долю заблокированных источников, отказы tool validation, ошибки прав и возраст документа. Не собирайте production prompts ради этой метрики. При росте риска остановите feature flag, исключите подозрительный индекс и разберите версию политики; не пытайтесь обойти закон, санкции, региональные, платёжные или платформенные ограничения. Тестируйте на собственном server-side ключе и подтверждайте маршрут в текущем каталоге RussiaAPI.

Server-side пример

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

const allowedTools = new Set(['searchTicket', 'getPublicStatus']);
export function validateToolProposal({ tool, args, user }) {
  if (!allowedTools.has(tool)) return { ok: false, reason: 'tool_not_allowed' };
  if (!user?.permissions?.includes(tool)) return { ok: false, reason: 'permission_denied' };
  if (!args || typeof args !== 'object' || Array.isArray(args)) return { ok: false, reason: 'invalid_args' };
  return { ok: true, tool, args: { id: String(args.id ?? '').slice(0, 64) } };
}

// Model output and retrieved documents are untrusted input; execute only after this check.

Проверьте синтаксис командой node --check, добавьте аутентификацию своего маршрута, rate limit, ограничение входа и негативные тесты. Не логируйте тело запроса или заголовки только ради отладки.

Что фиксировать в рабочем контуре

До запуска назначьте владельца сценария, версию адаптера, внутренний ID операции, разрешённый model ID и измеримый критерий результата. В безопасном журнале обычно достаточно времени, HTTP-класса, нормализованного кода, latency и request ID, если он есть. Не записывайте Authorization, полный prompt, ответ пользователя, временные URL или выгрузку заголовков: для первичной диагностики они не нужны и повышают риск утечки.

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