Сколько живет промпт-инъекция в вашем корпоративном чат-боте? Большинство безопасников и архитекторов ответят с уверенностью: ровно одну сессию, пока юзер не закроет диалоговое окно. Ошибка.
Если у вас внедрен поиск по внутренней базе знаний, отравление RAG-индекса живет ровно до тех пор, пока вы не пересоздадите всю векторную базу с нуля.
Один чанк ломает выдачу всем.
Полтора года назад я приехал спасать on-prem RAG в крупном финтехе. Проект продавали совету директоров как абсолютно безопасный. Железо стояло в подвале, данные за периметр не уходили, открытые эмбеддинги крутились локально на собственных серверах — идеальная картина для аудиторов ФСТЭК и комплаенса по 152-ФЗ. Проблема вскрылась, когда юрдепартамент начал выдавать клиентам безумные отказы, дословно ссылаясь на выдуманные пункты корпоративного регламента.
Оказалось, источником галлюцинаций стала не генеративная нейросеть. Векторная база прилежно цитировала загруженный документ. Этим авторитетным источником был гневный тикет из техподдержки, который техлид скормил пайплайну индексации вместе с огромным дампом писем и пользовательских файлов. Внутри тикета лежал зашитый белым шрифтом промпт, переопределяющий логику скоринга и ответов.
Механика data poisoning и 7 проверок целостности RAG-индекса
Это классическая механика непрямой инъекции, или indirect prompt injection. Хакеру не нужно пробивать сетевой файрвол. Достаточно загрузить PDF на корпоративный портал или отправить письмо, которое ваш заботливый краулер утянет в индекс. Дальше в дело вступает физика поиска.
Злоумышленник набивает свой текст ключевиками под топовые запросы сотрудников. Когда модели обрабатывают текст, они слепы: алгоритм не понимает авторитетности источника. Для него условный регламент ЦБ и спам-рассылка — это просто наборы точек в многомерном пространстве. Наивный chunking лишь усиливает эффект: нарезая файл на куски, мы плодим мусор. Дубли из отравленного файла кучно ложатся вокруг целевого вектора, вытесняют реальные документы и захватывают top-k выдачи.
Джейлбрейк сессии ломает контекст одного скучающего студента. Отравленный чанк заражает ответы системы для всей корпорации.
Как мы это разгребали и что необходимо контролировать перед пуском в прод. Первая линия обороны — контроль происхождения данных, он же provenance. Каждый чанк обязан нести в метаданных криптографическую подпись и тег источника, чтобы система отличала утвержденный комплаенсом договор от хлама из пользовательской корзины. Второе правило требует жесткой изоляции. Пользовательский контент должен лежать в изолированном индексе с пониженным приоритетом.
Третий рубеж закрывает уязвимость манипуляции релевантностью. Инъекция не пройдет, если перед отдачей LLM извлеченный контекст прогоняется через реранкер, оснащенный детектором вредоносных инструкций. Четвертое ограничение — жесточайший контроль доступа на уровне документа. Векторная база не имеет права скармливать модели контекст, если текущий пользователь не обладает правами на чтение оригинального файла. В том финтехе поиск шел от системного аккаунта, обходя все выставленные ACL на лету.
Пятое звено архитектуры — внедрение верификации цитирования. Нейросеть обязана сверять выданный факт с извлеченным чанком, и если факт притянут за уши — блокировать вывод. Шестая метрика требует агрессивной дедупликации контента на этапе векторизации, чтобы один огромный спам-файл не забил весь лимит генерации захваченными дубль-чанками. И седьмой слой — непрерывный мониторинг дрейфа ответов. Система обязана бить тревогу, если замечает аномальную релевантность какого-то свежего документа, внезапно всплывающего в половине ответов.
Та история закончилась полной остановкой сервиса и переписыванием архитектуры с нуля. Проектирование защищенного on-prem RAG с access-контролем и provenance — это не запуск контейнера с БД по интернет-мануалу. Это архитектурная паранойя и тотальное недоверие к каждому байту. Иначе ваша корпоративная база знаний неизбежно перейдет под контроль того, кто просто загрузит в нее правильный PDF.