^{Материал подготовлен для будущих студентов курс "NLP / Natural Language Processing".}

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

Согласно исследованию, опубликованному на USENIX Security 2025 (или см. github репо), всего пять тщательно подготовленных документов, нацеленных на конкретный запрос, могут манипулировать ответами ИИ с успешностью более 90% даже в базе из миллионов документов. 

OWASP LLM08:2025 теперь формально признает слабые места в векторах и эмбеддингах одним из рисков топ-10, включая атаки с обратным восстановлением эмбеддингов, которые при компрометации векторов позволяют восстановить 50–70% исходных слов во входных данных. 

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

Если вы уже развернули систему генерации с дополнением из поиска (Retrieval-Augmented Generation, RAG), ваша команда безопасности, скорее всего, сосредоточилась на очевидном векторе атаки: вредоносных пользовательских запросах. Вы добавили проверку ввода, внедрили защитные ограничения, то есть фильтры, которые выявляют и блокируют вредоносные промпты, а возможно, даже развернули классификатор промпт-инъекций. Дверь со стороны пользователя заперта.

Но есть и вторая граница доверия. И ее часто оставляют без защиты.

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

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

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

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

Математика атаки: пять документов среди миллионов

Насколько эффективны такие атаки на практике? Согласно PoisonedRAG (Zou et al.), исследованию, опубликованному на USENIX Security 2025 исследователями из Пенсильванского государственного университета и Иллинойсского технологического института, всего пять тщательно подготовленных документов, нацеленных на конкретный запрос, могут манипулировать ответами ИИ с успешностью более 90% даже в базе знаний, содержащей миллионы документов.

Это не широкая компрометация всей системы. Атака очень точечная и работает только при выполнении двух условий. 

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

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

Векторные базы данных: созданы для скорости, а не для противостояния злоумышленникам

В редакции OWASP Top 10 for LLM Applications за 2025 год появился новый пункт, который командам безопасности стоит внимательно изучить: LLM08:2025 Vector and Embedding Weaknesses, то есть слабые места в векторах и эмбеддингах. Эта категория признает, что инфраструктура, лежащая в основе RAG-систем, а именно векторные базы данных и конвейеры построения эмбеддингов, создает собственный класс уязвимостей.

Векторные базы данных хранят документы в виде эмбеддингов: многомерных числовых векторов, которые отражают семантический смысл. Когда вы строите эмбеддинг для предложения, получившийся вектор размещает его в математическом пространстве, где похожие предложения группируются рядом друг с другом. Именно благодаря этому работает извлечение. И именно из-за этого такие системы становятся уязвимыми.

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

Обратное восстановление эмбеддингов: ваши векторы раскрывают больше, чем кажется

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

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

Согласно исследованию переносимых атак обратного восстановления эмбеддингов, представленному на ACL 2024, Huang et al. показали, что такие атаки работают даже без прямого доступа к исходной модели эмбеддингов. 

Опираясь на более ранние работы, где был установлен уровень восстановления 50–70% исходных слов во входных данных, их исследование показало, что атакующие могут использовать вспомогательные модели, чтобы выводить содержимое только по векторам. Имена собственные, технические термины и уникальные фразы особенно уязвимы, поскольку занимают характерные области пространства эмбеддингов.

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

Ошибки изоляции в многопользовательской среде

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

Представьте финансовую SaaS-платформу, где документы каждого клиента превращаются в эмбеддинги и хранятся в общем векторном хранилище. Пользователь из компании A задает безобидный вопрос о прогнозах квартальной выручки. Если векторы не изолированы по клиенту, поиск по сходству может извлечь семантически связанный контент из конфиденциальных финансовых документов компании B, раскрыв ее данные о выручке пользователю из компании A. Запрос не был вредоносным – вредоносной оказалась архитектура.

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

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

Когда теория встречается с продакшеном

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

Slack AI: непрямая промпт-инъекция через публичные каналы

В августе 2024 года исследователи безопасности раскрыли уязвимость в Slack AI, которая сочетала непрямую промпт-инъекцию с извлечением в стиле RAG. Slack AI обрабатывает сообщения из каналов, чтобы формировать ИИ-сводки и ответы. При этом по замыслу системы сообщения из публичных каналов доступны для поиска всем участникам рабочего пространства, независимо от того, вступили они в канал или нет.

Атака использовала это поведение: злоумышленник публиковал в публичном канале сообщение с вредоносными инструкциями. Когда Slack AI извлекал это сообщение как контекст для ответа на пользовательский запрос, встроенные инструкции могли заставить ИИ сформировать фишинговую ссылку, через которую утекали данные из контекста пользовательского разговора. 

Уязвимость была реальной, но ее масштаб был уже, чем может показаться: атакующему уже требовалась учетная запись в том же рабочем пространстве Slack, а поведение с извлечением данных из публичных каналов было проектным решением, а не ошибкой в контроле доступа.

Slack признала проблему 20 августа 2024 года и в тот же день выпустила патч. В своем уведомлении компания описала это как сценарий, при котором «при очень ограниченных и специфических обстоятельствах злоумышленник с существующей учетной записью в том же рабочем пространстве Slack мог фишинговать пользователей для получения определенных данных». Компания сообщила, что не обнаружила признаков несанкционированного доступа к клиентским данным.

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

Память ChatGPT: устойчивое шпионское ПО через отравленный контекст

В сентябре 2024 года исследователь безопасности Йоханн Ребергер продемонстрировал SpAIware – технику устойчивой эксфильтрации данных из ChatGPT через отравление функции памяти. Обманом заставив пользователя перейти на вредоносный сайт или проанализировать специально подготовленный вредоносный документ, злоумышленник мог внедрить инструкции в память ChatGPT. Эти инструкции сохранялись между сессиями и заставляли ИИ отправлять все последующие разговоры на сервер под контролем атакующего.

Эшелонированная защита для RAG-систем

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

Контроль на этапе загрузки данных: относитесь к документам как к коду

База знаний теперь стала частью вашей поверхности атаки. К каждому входящему документу нужно относиться с той же осторожностью, с какой вы относитесь к пользовательскому вводу.

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

Предварительная обработка для поиска скрытых инструкций предполагает сканирование документов перед построением эмбеддингов на наличие паттернов, похожих на попытки промпт-инъекции. Сюда относятся фразы вроде «игнорируй предыдущие инструкции», «теперь ты» и похожие командные конструкции – и это только самые очевидные примеры. Инструменты вроде открытого PromptGuard от Meta могут помочь выявлять попытки инъекций в содержимом документов. Фильтры на основе регулярных выражений дают первую линию обороны, но классификаторы на базе больших языковых моделей обнаруживают более сложные попытки.

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

Шифрование эмбеддингов означает, что векторы рассматриваются как чувствительные данные, которые нужно защищать при хранении и передаче. Многие векторные базы данных отдают приоритет производительности, а не безопасности, и не шифруют эмбеддинги по умолчанию, полагаясь вместо этого на безопасность на уровне приложения.

Если злоумышленник получит сетевой доступ или украденный API-токен, он сможет выгрузить весь индекс эмбеддингов и запускать атаки обратного восстановления офлайн. Шифрование эмбеддингов при хранении и обязательное использование TLS для всех подключений к векторной базе данных повышают сложность кражи данных.

Контроль на этапе извлечения: поиск с учетом прав доступа

Уровню извлечения нужны механизмы контроля доступа, которые учитывают пользовательский контекст, а не только сходство с запросом.

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

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

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

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

Контроль на этапе генерации: защитные ограничения и мониторинг

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

Обнаружение инъекций в контексте отслеживает подозрительные паттерны в собранном промпте до его отправки в LLM. Здесь можно использовать те же классификаторы промпт-инъекций, что и на этапе загрузки данных, например упомянутый выше PromptGuard. Только в этом случае они сканируют уже полностью собранный контекст, а не отдельные документы.

Цель – поймать попытки инъекций, которые прошли через фильтры загрузки, например потому, что вредоносная инструкция становится очевидной только в сочетании с определенными извлеченными документами.

Мониторинг вывода относится к ответам LLM с подозрением, если в них появляются неожиданные элементы: URL-адреса, запросы чувствительной информации, инструкции выполнить действия или содержимое, которое заметно отклоняется от ожидаемых паттернов ответа. 

Например, если ответ на вопрос «Какова наша политика возврата?» внезапно содержит https://attacker.example.com/?data=... или просит пользователя указать пароль, это сильный признак успешной инъекции. Автоматическое сканирование URL-адресов, ведущих на внешние домены, строк в кодировке base64 или запросов учетных данных может перехватить попытки эксфильтрации до того, как они дойдут до пользователя.

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

Выводы

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

• Отравление корпуса удивительно эффективно. Академические исследования показывают, что пять документов среди миллионов могут давать успешность атаки выше 90%. Злоумышленникам не нужно компрометировать всю вашу базу знаний, чтобы манипулировать ответами на ценные запросы.

• Векторные базы данных привносят собственные уязвимости. Атаки обратного восстановления эмбеддингов позволяют восстанавливать значительные фрагменты исходного текста из векторов. В многопользовательских средах без извлечения с учетом прав доступа возникает риск утечки между контекстами.

• Продакшен системы уже сталкивались с такими проблемами. Инциденты с непрямой промпт-инъекцией в Slack AI и отравлением памяти ChatGPT показывают, что эти паттерны атак не ограничиваются академическими работами. Даже когда отдельные находки ограничены по масштабу, они демонстрируют, как извлечение в стиле RAG может усиливать проблемы, которые иначе выглядели бы незначительными.

• Защита требует трех уровней. Контроль на этапе загрузки данных рассматривает документы как код. Контроль на этапе извлечения применяет права доступа во время запроса. Контроль на этапе генерации исходит из того, что часть вредоносного содержимого все равно попадет к LLM, и обнаруживает его до генерации или после нее.

В контексте RAG и LLM важно не только понимать риски, но и разбираться, как вообще устроены основные методы работы с такими системами.

6 мая в 18:00 на бесплатном демо-уроке «Методы работы с LLM: промпт-инжиниринг, Lora и RAG» мы вместе с Марией Тихоновой разберём базовые сценарии применения LLM, принципы LoRA, промпт-инжиниринг и RAG. Формат полезен тем, кто хочет закрыть пробелы, задать вопросы эксперту и посмотреть, как устроено обучение на курсе «NLP / Natural Language Processing». Записаться на урок

Немного практики в тему — пройдите вступительный тест по NLP и узнаете, есть ли пробелы в знаниях.