Embedding Attacks

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

Суть

Речь не только про RAG: та же механика лежит под памятью агента на векторах, семантическим кэшем (Semantic Cache) и конвейерами дедупликации. Везде, где поиск по сходству решает, что увидит модель, открывается эта поверхность.

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

Обратная сторона тоже полезна: система без векторов — только BM25 или обход по дереву — наследует негеометрические риски, но этой поверхности атаки у неё нет.

Инверсия: вектор восстанавливается в текст

Главный факт, меняющий отношение к хранилищу. Из сохранённых эмбеддингов восстанавливается исходный текст: порядка 50–70% слов из эмбеддингов предложений, а метод Vec2Text даёт 92% точной реконструкции коротких входов в 32 токена (Morris et al., 2023), обучая модель инверсии под конкретный энкодер.

Дальше хуже: ZSInvert (Zhang et al., 2025) и Zero2Text (Kim et al., 2026) работают без обучения под энкодер, в межпредметных и чёрноящичных постановках, и сохраняют эффективность против дифференциально-приватного шума, добавленного при хранении.

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

Утечка между арендаторами — до того, как сработал контроль доступа

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

Ключевое: атака работает, даже когда каждый документ размечен правильно и каждый вызов аутентифицирован, потому что решение о доступе принимается после того, как поиск по пространству уже отработал (Multi Tenancy AI).

Обычные дыры аутентификации в векторных СУБД сюда формально не входят, но усиливают последствия — CVE-2025-64513 (Milvus, подделка заголовка sourceID в обход аутентификации, CVSS 9.3) и CVE-2025-69286 (RAGFlow, предсказуемый вывод токена и захват учётной записи, CVSS 9.3). Важна логика: та же дыра в векторной базе тяжелее, чем в документной или ключ-значение, потому что утёкшее из векторной обращается обратно в документы.

Глушение: документ-затычка

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

Одного такого документа достаточно, и собирается он чёрноящичной оптимизацией, без доступа к целевой модели эмбеддингов и к самой LLM.

Вывод о членстве: индекс как оракул

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

Сам факт членства бывает чувствительнее содержания.

Что из этого следует

  • Секретность класса «документ», а не «служебный индекс». Векторы, бэкапы и выгрузки защищаются на уровне исходных данных, включая передачу подрядчику.
  • Разграничение до поиска, а не после. Фильтр по арендатору должен применяться в запросе к индексу, иначе утечка идёт через метаданные результата.
  • Оценки сходства наружу не отдаются. Это дешёвая правка с прямым эффектом.
  • Запись в корпус — привилегия. Поверхности отравления и глушения обе открываются возможностью положить документ (RAG Poisoning).

Связано с

  • Vector Databases — где всё это хранится и почему бэкап критичен
  • RAG Poisoning — отравление на извлечении, третья из четырёх механик
  • Multi Tenancy AI — разграничение арендаторов, которое здесь обходится геометрией
  • Semantic Cache — та же машинерия вне RAG
  • Model Poisoning — отравление самой модели эмбеддингов, это уже другая стадия
  • Embeddings — что именно превращается в вектор
  • DLP for LLM — почему выгрузка векторов считается утечкой данных