Подключить RAG к агенту легко, а сделать его безопасным — нет. Три из пяти пилотов в 2025–2026 сломались не на моделях, а на данных: векторная база отдала чанки без проверки прав, логи унесли фрагменты договоров, а «доверенный» документ оказался с инструкцией внутри. Агент усиливает каждую из этих ошибок: он читает больше, запоминает дольше и передает дальше.
Где утекает RAG
Цепочка длинная, и утечка может случиться на каждом звене:
- Индексация. Документ загружен без метаданных доступа — считается доступным всем.
- Векторное хранилище. Эмбеддинги инвертируются в исходный текст; база без шифрования — готовая копия чувствительных данных.
- Retrieval. Фильтр по правам после поиска уже поздно — закрытые чанки уже в памяти сервиса и логах.
- Передача в модель. Весь документ вместо двух релевантных фрагментов — лишние PII в контексте.
- Логи и наблюдаемость. Промпты, чанки, ответы и системные подсказки уходят в APM/лог-платформу за периметр.
Одна ошибка tenant_id в метаданных — и ретривер возвращает документы соседнего клиента. ФСТЭК в Приказе №117 в 2026 прямо назвал источники RAG, журналы и системные промпты объектами защиты — не случайно.
Контроль доступа на уровне чанка, а не интерфейса
Самая частая архитектурная ошибка — проверять права в UI, а не в ретривере. Пользователь не должен получить через агента то, к чему у него нет доступа в исходной системе. Это значит:
- наследование прав корпоративной системы на каждый чанк;
- фильтр по ролям/атрибутам до векторного поиска, а не пост-фильтр;
- провенанс на каждом чанке: владелец, версия, классификация, источник.
Без провенанса аудит невозможен: нельзя ответить кому принадлежит половина договора, попавшая в ответ. С ним — можно удалить данные по требованию (152-ФЗ) и доказать что агент видел только свое.
Шифрование и изоляция контуров
Вектор — не абстрактные числа, а обратимое представление текста. Потому:
- шифруйте чанки, метаданные и транспорт между сервисами (диск + application level);
- держите сырые документы, эмбеддинги, индексы и логи в разных контурах с разными политиками;
- минимизируйте логирование: храните идентификаторы и атрибуты, а не полный текст чанков;
- используйте отдельные service accounts для ретривера, индексации и LLM-вызовов.
Принцип «одна модель на всех» ломается: публичная модель + внутренние данные требует разделения контуров и явной политики какой контекст куда может идти.
Poisoning и качество поиска
RAG уязвим к отравлению базы знаний: документ с высокой семантической близостью к популярным запросам, но с вредоносным содержимым или скрытой инструкцией. В multi-tenant схеме один ядовитый файл всплывает в чужих диалогах. Защита — гибридный поиск (вектор + ключевые слова), reranker для переоценки релевантности, версионирование и криптографическая проверка целостности источников.
Дополнительно тестируйте «утечку через перефразирование»: атакующий обходит фильтр десятком формулировок. Регулярные промпт-пентесты — часть валидации RAG, а не опция.
Чеклист безопасного RAG для агента
- Права проверяются до
retrieval, фильтр на уровне чанка с наследованием. - В модель уходит минимум релевантных фрагментов, не целые документы.
- Векторы, чанки и логи зашифрованы, ключи отдельно.
- Логи содержат 5 полей аудита: кто спросил, что спросил, откуда источники, какие чанки использованы, что сгенерировано.
- DLP на промпт и ответ, секреты и PII маскируются до модели.
- Регулярные тесты на poisoning, перефразирование и tenant-leak.
- План удаления данных и ротации ключей проверен, а не написан.
Без этого агент превращается в элегантный инструмент кражи данных с дружелюбным интерфейсом.
Где Codenik
Codenik выступает как policy-aware слой между агентом и RAG: фильтрует retrieval по правам human delegator до попадания в контекст, минимизирует передаваемые фрагменты, маскирует PII на шлюзе и пишет аудит по пяти полям. Агент вызывает «найди в базе знаний», не получая прямой доступ к векторной БД — и не видя того, что ему не положено.
Короткий вывод
Безопасность RAG — это управление маршрутом данных от загрузки до ответа и логов. Чем раньше права спускаются на уровень чанка и чем меньше лишнего попадает в контекст, тем ниже шанс утечки через вспомогательный компонент.