Исследование · Безопасность RAG

RAG без доверенного контура: пять контрольных точек базы знаний

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

Иллюстрация к материалу «RAG без доверенного контура: пять контрольных точек базы знаний»
Темы:RAGутечка данныхзащита данныхвнедрение инструкций

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

01

Определите границы знаний

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

02

Проверяйте доступ до поиска

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

03

Отделяйте данные от инструкций

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

04

Сделайте ответ проверяемым

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

Граница применимости. Это защитно-ориентированное объяснение, а не гарантия предотвращения инцидентов. Контроли следует адаптировать через моделирование угроз, требования к данным и процессы реагирования вашей организации.

Продолжите исследование

Связанные риски

Карточки связывают материал с конкретными угрозами, признаками и мерами защиты на интерактивной карте.

A02 · Высокий

Indirect Prompt Injection via web pages

Недоверенный ввод или внешний контент влияет на поведение модели, нарушая границы заявленной задачи.

Открыть карточку
A08 · Высокий

System Prompt Leakage

Недоверенный ввод или внешний контент влияет на поведение модели, нарушая границы заявленной задачи.

Открыть карточку
A12 · Высокий

Shadow AI data leakage

Управление AI-системой, поставщиком, конфигурацией или принятием решения не даёт достаточной доказательности риска и контроля.

Открыть карточку
A52 · Высокий

Prompt injection through uploaded files

Недоверенный ввод или внешний контент влияет на поведение модели, нарушая границы заявленной задачи.

Открыть карточку
A53 · Высокий

Malicious URL in prompt or retrieved content

Недоверенный ввод или внешний контент влияет на поведение модели, нарушая границы заявленной задачи.

Открыть карточку
Открыть интерактивную карту угроз
Первоисточники

Международные источники и практики

Сначала мы объясняем практический смысл материала на русском. Ниже — первоисточники для проверки и детального изучения границ применимости.

OWASPLLM04:2025 Data and Model PoisoningОтравление данных и моделей.OWASPLLM08:2025 Vector and Embedding WeaknessesRAG, embeddings и векторные хранилища.arXivLayered Security Framework Against Prompt Injection in RAG-Based ChatbotsDefense-in-depth для RAG prompt injection.