史丹佛研究人員揭示AI API中的提示快取風險：揭露安全缺陷和數據漏洞

大型語言模型 (LLMs) 的處理需求帶來了相當大的挑戰，尤其是在需要快速回應的即時應用中。每次處理問題都需要重新計算，這樣既耗時又低效，還需要大量資源。為了克服這些低效，人工智慧 (AI) 服務提供商使用快取系統來儲存重複的查詢，這樣就能立即回答問題，無需等待，從而提高效率並減少延遲。然而，雖然這樣可以加快回應速度，但也會帶來安全風險。科學家們研究了大型語言模型 API 的快取習慣，發現這可能無意中洩露機密信息。他們發現用戶的查詢和商業機密模型信息可能會通過基於時間的側信道攻擊被洩露，這些攻擊是基於商業 AI 服務的快取政策。

快取查詢的一個主要風險是它可能會揭示先前用戶查詢的信息。如果快取的提示在多個用戶之間共享，攻擊者可能會根據回應時間的差異來判斷其他人是否最近提交了類似的提示。這種風險在全球快取的情況下更大，因為一個用戶的提示可能會使另一個提交相關查詢的用戶獲得更快的回應時間。通過分析回應時間的變化，研究人員展示了這種漏洞如何使攻擊者能夠揭露機密商業數據、個人信息和專有查詢。

不同的 AI 服務提供商有不同的快取方式，但他們的快取政策對用戶來說並不一定透明。一些服務限制快取僅限於單一用戶，這樣快取的提示僅對發佈者可用，從而不允許數據在帳戶之間共享。其他服務則實施按組織快取，這樣一家公司或組織中的多個用戶可以共享快取的提示。雖然這樣更有效，但如果某些用戶擁有特殊的訪問權限，仍然有洩露敏感信息的風險。最具威脅的安全風險來自全球快取，所有 API 服務都可以訪問快取的提示。因此，攻擊者可以操縱回應時間的不一致性來確定之前提交的提示。研究人員發現大多數 AI 提供商對其快取政策不透明，這使得用戶對其查詢所伴隨的安全威脅一無所知。

為了調查這些問題，史丹佛大學的研究團隊開發了一個審計框架，能夠在不同的訪問層級檢測提示快取。他們的方法是向各種 AI API 發送控制的提示序列，並測量回應時間的變化。如果一個提示被快取，當再次提交時，回應時間會明顯更快。他們制定了統計假設檢驗來確認是否發生了快取，並確定快取共享是否超出了單個用戶。研究人員通過系統性地調整提示長度、前綴相似性和重複頻率來識別快取的模式。審計過程中測試了 17 個商業 AI API，包括 OpenAI、Anthropic、DeepSeek、Fireworks AI 等。他們的測試重點是檢測快取是否實施，以及它是否僅限於單一用戶或在更廣泛的群體中共享。

審計程序包括兩個主要測試：一個測量快取命中時的回應時間，另一個測量快取未命中時的回應時間。在快取命中測試中，將相同的提示多次提交，以觀察第一次請求後回應速度是否改善。在快取未命中測試中，使用隨機生成的提示來建立未快取回應時間的基準。這些回應時間的統計分析提供了多個 API 中快取的明確證據。研究人員在 17 個 API 提供商中識別出 8 家具有快取行為。更重要的是，他們發現這 7 家提供商的快取是全球共享的，這意味著任何用戶都可以根據回應速度推斷其他用戶的使用模式。他們的發現還揭示了關於 OpenAI 的 text-embedding-3-small 模型的一個先前未知的架構細節——提示快取行為顯示它遵循解碼器專用的變壓器結構，這一信息之前並未公開披露。

快取提示與非快取提示的性能評估突顯了回應時間的顯著差異。例如，在 OpenAI 的 text-embedding-3-small API 中，快取命中的平均回應時間約為 0.1 秒，而快取未命中則延遲達 0.5 秒。研究人員確定快取共享的漏洞可能使攻擊者能夠幾乎完美地區分快取和非快取的提示。他們的統計測試產生了高度顯著的 p 值，通常低於 10⁻⁸，這表明快取行為的可能性很高。此外，他們發現，在許多情況下，單次重複請求就足以觸發快取，而 OpenAI 和 Azure 需要多達 25 次連續請求，才會顯示出快取行為。這些發現表明，API 提供商可能使用分佈式快取系統，提示不會立即在所有伺服器上存儲，而是在重複使用後才會被快取。