Day 27｜Vector 與 Embedding 可能有哪些安全問題？

上一篇介紹了 Embedding、Vector Database，以及它們在 RAG 中扮演的角色。

但當資料都被轉換成 Vector，再透過 Similarity Search 找資料時，也會產生一些新的安全問題。

1. 不同使用者的資料被混在一起

假設一個 SaaS 平台使用同一個 Vector Database 存放不同公司的資料。

如果權限控管設計不當，搜尋可能先在整個 Vector Index 中進行，再到後面才檢查使用者權限。

這樣就可能讓攻擊者透過搜尋結果、數量或相似度等資訊，推測其他使用者是否存在某些資料。

這類問題可以稱為 Cross-Tenant Leakage（跨租戶資料洩漏）。([turn773238search0])

2. Embedding 本身也可能洩漏資訊

很多人可能會覺得：

「我沒有把原始文件給攻擊者，只給他 Vector，應該沒關係吧？」

但實際上，研究已經證明某些 Embedding 可以透過 Embedding Inversion 嘗試還原部分原始文字。

因此，Embedding 並不一定只是「沒有意義的一串數字」，它本身仍可能包含原始資料的語意資訊。([turn773238search0])

3. Retrieval Poisoning

如果攻擊者可以把資料加入知識庫，就可能刻意製造一份 Embedding 很接近特定問題的內容。

當使用者之後提出相關問題時，系統可能優先把攻擊者的資料找出來，再交給 LLM。

也就是：

攻擊者不是直接攻擊 LLM，而是先想辦法讓錯誤資料「被搜尋到」。 ([turn773238search0])

4. Retrieval Jamming

另外一種情況是，攻擊者不是想讓 AI 相信錯誤資訊，而是想讓它找不到正確資訊。

例如放入一份特別設計的文件，讓它在特定問題下經常被搜尋到，導致 LLM 最後回答「沒有相關資料」或拒絕回答。

這可以視為對 RAG Retrieval Layer 的一種可用性攻擊。([turn773238search0])

5. 資料存在也可能被推測出來

還有一種比較特別的問題叫 Membership Inference。

攻擊者可能不需要知道文件內容，只想知道：

「這份文件到底有沒有存在這個 Vector Database 裡？」

例如醫療紀錄、法律文件或公司內部資料，即使只知道「某份資料存在」，本身也可能具有敏感性。([turn773238search0])

可以看到，Vector 和 Embedding 的問題不只是「資料庫被駭」。

Similarity Search 本身就是一個新的攻擊面。

從跨租戶資料推測、Embedding 還原，到 Retrieval Poisoning 與 Membership Inference，都可能在傳統 Database Security 之外產生新的風險。

所以當我們使用 RAG、Vector Database 時，也不能只考慮：

「資料有沒有加密？」

還要開始思考：

「這些 Vector 被搜尋、比對和使用的方式，本身安全嗎？」