文章 發布於 AIA: 2026年4月29日

Kimi 隱私外洩報導：翻譯圖片卻回傳陌生人的履歷

《每日經濟新聞》報導，一名 Kimi 使用者原本只是請模型翻譯一張 PPT 圖片，最後卻收到一份陌生人的真實履歷，裡面有姓名、電話、email、工作經歷、專案經驗和業績細節。報導指出，當事人後來聯絡到履歷上的本人，對方確認內容屬實；截至文章發布時，Kimi 母公司月之暗面尚未給出正式回覆。

這件事不應該只被當成一般「幻覺」。幻覺通常是模型編出不存在的內容；但如果模型把另一個使用者上傳過的真實檔案回給無關使用者，問題就比較像 AI 服務路徑裡的隔離、快取（cache）、擷取綁定、暫存物件存取、非同步任務身分，或記錄回放出了問題。

Privacy LeakageSession IsolationData GovernanceMulti-Tenant AIRAG Security
8 項對應的 AIDEFEND 防禦手法
來源: “我的简历竟在大模型上‘裸奔’”，个人隐私为何遭“开盒”式泄露？ 
作者 每日经济新闻 · 原文發布: 2026年4月23日 上午11:37

威脅分析

  • 這不是單純答錯，而是隱私資料被送錯人。 模型亂編內容是一回事；把真實履歷回給無關使用者是另一回事。後者代表系統可能把某個使用者的檔案、上下文或擷取結果，帶進了另一個使用者的回答裡。
  • 可能出錯的位置不只模型本身。 報導引用的專家提到幾種可能路徑：資料隔離失效、多使用者上下文混在一起、RAG 擷取結果綁到錯的使用者、檔案解析或暫存物件儲存空間的存取控制失效、非同步任務 ID 和使用者 ID 對不起來、記錄回放異常，以及分享連結或搜尋索引設定不當。
  • 多模態輸入讓身分綁定更容易在中途掉線。 這次使用者上傳的是 PPT 圖片。一次看似簡單的翻譯，背後可能經過圖片上傳、OCR 或檔案解析、任務佇列、暫存物件、模型上下文組裝、輸出生成和記錄。每一站都要保留「這是誰的檔案、哪個工作階段、哪個租戶、目前有沒有權限讀」這些綁定。
  • 輸出掃描是最後一道防線。 就算錯的履歷真的進到模型上下文裡，姓名、電話、email、工作經歷和專案經驗這類結構化個資，也應該在回應顯示給另一個使用者前被擋下來。
  • 事後調查不能只停在「小機率」。 防禦方需要能追到 request ID、檔案 ID、擷取 ID、快取 key、佇列 job ID 和模型輸出記錄，才能判斷這是單一 request、單一租戶、某一類快取，還是更廣泛的隔離缺陷。

適用的 8 項 AIDEFEND 防禦手法

AID-I-004.001
Runtime Context Isolation & Hygiene
極高
最直接的控制，是讓執行中的上下文不可能不小心跨使用者共用。工作記憶、OCR 結果、解析後的檔案文字、上傳檔案參照和對話狀態，都應該用租戶 ID、使用者 ID 和工作階段 ID 綁住，並加上存活時間和預設拒絕的讀取規則。只要翻譯請求有機會讀到別人的履歷，這條上下文邊界就還不夠強。
AID-H-028
Inference Cache Integrity, Isolation & Poisoning Prevention
極高
報導提到快取重用是可能路徑之一。提示詞回應快取、語意快取、prefix cache、KV cache 或其他推論時快取，都不能只靠內容相似度決定能不能重用；key 裡必須包含租戶、使用者、工作階段、模型、政策和授權上下文。對 A 使用者有效的中間結果或回答，不能因為 B 使用者問了相似問題就被拿去重用。
AID-I-004.002
Persistent Memory Partitioning (Trust & Tenant Isolation)
高
如果履歷是從 RAG 索引、向量資料庫、上傳檔案索引或長期記憶裡被抓出來，重點就是租戶和使用者分區。每個使用者上傳的檔案和切好的 chunk，都要放在分開的 namespace 或 collection；擷取時還要重新檢查目前使用者是否有權限讀那個 chunk。
AID-H-033.002
Cross-Tenant Serving-State Isolation
高
大型 AI 服務常為了效能共用佇列、批次、暖機 worker、prefix cache、KV cache、failover state 或工作階段 namespace。這些最佳化如果沒有以租戶為邊界，就可能把上一個使用者的狀態帶到下一個使用者的請求裡。對大規模消費者 AI 服務來說，這是必須明確設計和測試的隔離面。
AID-H-030.002
Lifecycle-Stage Authorization Gate
高
某份履歷可以被原上傳者拿來翻譯或摘要，不代表它可以進到另一個使用者的推論上下文、RAG 索引、記錄、長期記憶或記錄回放流程。每次資料要跨到下一個 AI 生命週期階段前，系統都應該檢查資料使用標籤：這個檔案能不能在這個使用者、這個工作階段、這個目的下被使用。不能，就拒絕並留下政策事件。
AID-H-019.005
Value-Level Capability Metadata & Data Flow Sink Enforcement
高
把回答顯示給錯的人，本身就是資料流到錯的出口。從上傳檔案、OCR、RAG chunk 或工具輸出來的每個值，都應該帶著來源和機敏程度標籤；在它被放進最終回答前，系統要確認目前收件者真的可以看到這份資料。
AID-D-003.002
Sensitive Information & Data Leakage Detection
高
一份含姓名、電話、email、工作經歷和專案細節的履歷，是很明顯的輸出 DLP 目標。就算模型因為內部擷取或快取錯誤產生了這段文字，輸出掃描也應該在顯示前偵測到結構化個資，然後封鎖、遮罩或升級人工審查。
AID-D-005.004
Specialized Agent & Session Logging
中
這類事件如果沒有端到端追蹤，很難查清楚。平台需要結構化記錄，把使用者 ID、租戶 ID、工作階段 ID、上傳 ID、OCR / 解析 job ID、擷取 ID、快取 key、佇列 job ID 和輸出 ID 串起來。這些證據才能回答：履歷到底是從快取、擷取綁定、暫存物件，還是記錄回放進來的。

身為資安防禦者，我們應該這麼做

  • 拿一個上傳檔案請求做端到端追蹤：upload ID、解析 job、OCR 結果、暫存物件、RAG chunk、快取 key、模型請求、最後輸出和記錄。確認每一站都有使用者、租戶、工作階段和授權資訊。
  • 檢查所有提示詞回應快取、語意快取、prefix cache、KV cache 和解析結果快取。快取 key 必須包含租戶、使用者、工作階段和授權上下文；如果缺少這些資訊，先停用跨請求重用。
  • 在任何擷取文件、上傳檔案、暫存物件或記錄回放進入模型上下文前，加一道預設拒絕的授權檢查。問題要很簡單：這份資料能不能給這個使用者、這個工作階段、這個目的使用。
  • 替履歷和個人資料加輸出 DLP。姓名加電話、email、工作經歷段落、專案經歷或身分證號格式，都應該在顯示前被擋下或升級審查。
  • 做種子測試來驗證跨使用者隔離。用 A 使用者上傳一份帶 canary 的測試履歷，再用 B 使用者發出無關的翻譯與摘要請求，確認 canary 不會出現在上下文、擷取結果、快取命中、記錄或輸出裡。
  • 先把事件鑑識準備好。保留 request trace、快取決策、擷取決策和刪除 / 保留證據，下一次隱私事件發生時，回應才會是具體說明，而不是猜測。

1 個額外的防禦考量

使用者通知與事件範圍說明

除了上面對應的技術，處理個人檔案的消費者 AI 服務也應該準備好面向監管與使用者的事件說明流程：到底發生什麼事、影響哪些使用者和檔案、哪些資料被回傳給誰、已經完成哪些補救。
建議做法: 準備一份 AI 隱私事件 playbook，把技術鑑識和使用者通知接起來：request 時間線、受影響 asset ID、收到資料的對象、外洩資料類別、阻斷措施、保留與刪除狀態，以及客服可以對外說明的內容。

結論

這篇 Kimi 報導提醒我們，AI 隱私事件看起來像模型在回答，但真正的失效點常常在產品架構裡。模型只是最後說出口的那一層；問題可能藏在上傳處理、OCR、暫存物件、RAG 綁定、快取重用、工作階段狀態或輸出控管。AIDEFEND  在這個案例中對應到上下文隔離、快取完整性、資料使用授權、每筆資料送出前的出口檢查、輸出 DLP 和鑑識用的 session logging。實務目標很簡單：除非每一層都能證明這份資料屬於目前這個使用者的請求，否則它就不應該出現在回答裡。