Hosted LLM 稽核論文閱讀分析：真正該怕的，不只是模型答錯，而是供應商可能根本沒用你付錢的那顆
本文由 AI 產生、整理與撰寫。
論文基本資訊
- 論文標題：Committed SAE-Feature Traces for Audited-Session Substitution Detection in Hosted LLMs
- 作者：Ziyang Liu 等
- 年份：2026
- 來源：arXiv:2604.18179
- 論文連結：https://arxiv.org/abs/2604.18179
- DOI：10.48550/arXiv.2604.18179
- 主題：Hosted LLM Audit、Model Substitution、AI Supply Chain、Sparse Autoencoder、Merkle Commitment、Inference Integrity
這篇 paper 很對我胃口，因為它抓到一個現在很多人其實都知道存在、但很少真正正面處理的灰色地帶：當你買的是 hosted LLM 服務，而不是自己掌握模型權重時，你到底怎麼知道對方真的有照它宣稱的那顆模型在回你？
這不是單純的 benchmarking 問題，也不是一般意義上的 model eval。它更像是 AI 服務供應鏈裡的「誠信驗證」問題：供應商可以廣告自己用的是比較強、比較貴、比較安全的模型，但在實際 serving 時，是否可能靜悄悄地把普通使用者導去更便宜的替代模型，再把審計流量特別路由回真正承諾的那顆？
這篇最核心的提醒是：在 hosted LLM 時代，模型能力不只是一個 quality 問題，它也正在變成一個可被暗中替換、而且難以舉證的供應鏈完整性問題。
它在解什麼問題？
作者處理的是所謂的 silent substitution。情境很直白：
- 供應商對外宣稱自己提供的是比較強的模型
- 但實際上，日常請求可能被導去比較便宜的替代模型
- 只有在被驗證、被 probe、被抽查時，才切回真正宣稱的模型
這種做法麻煩的地方，不在於它完全不可想像，而在於它對現有驗證方法有天然優勢。很多 audit 思路其實都默默假設：你事後再來問幾個 probing question，看輸出像不像那顆模型，就能驗證服務有沒有作弊。 但只要供應商知道哪些流量是在 probe，它完全可以做平行供應：
- 普通用戶流量：送去便宜替代模型
- 驗證探針流量：送去 advertised model
這樣一來，你看到的 audit result 可能很漂亮，但用戶真正拿到的根本不是同一顆系統。
這篇的關鍵想法：不要事後猜，改成事前承諾
我覺得這篇最聰明的地方，是它沒有再走「回來後多問幾題」那種 probe-after-return 路線，而是直接換遊戲規則：在任何驗證開啟請求之前，供應商就得先對自己剛剛真正送出的那次回應留下不可抵賴的承諾。
作者提出的是一個 commit-open protocol：
- 模型先對已送出的輸出，建立某種可驗證的 feature-trace sketch
- 再把這些 sketch 透過 Merkle tree 做 commitment
- 之後 verifier 才隨機打開部分位置做檢查
這個設計的妙處在於，供應商必須先 commit，再知道你要查哪裡。因此它很難像傳統 probe 一樣，臨時把驗證請求切給另一顆模型來應付。
換句話說，這篇不是在驗「那顆模型整體風格像不像」，而是在驗：你剛才交付的那次回應，在內部特徵層面，到底是不是來自你宣稱的那種生成機制。
為什麼用 SAE feature trace，而不是只看文字輸出？
這裡就是 paper 最有意思的技術選點。作者不是只比較最終 token 或字面風格，而是用 sparse autoencoder（SAE） 的 feature trace 來做 sketch。
這背後的直覺很好懂：只看最終文字，太容易被模仿；但如果你去看生成過程在某個 probe layer 上留下來的 feature activation 痕跡，替代模型要偽裝成同一顆模型，就會困難很多。
論文裡的做法大致是：
- 在公開指定的 probe layer 取每個位置的 SAE 特徵痕跡
- 把它壓成 per-position sketch
- 對整段輸出做 commitment
- 由 verifier 隨機開一些位置，拿去和公開的 probe library 比對
作者最後不是用某個模糊的「感覺像」來判斷，而是透過固定門檻的 joint-consistency z-score 規則來決定是否可接受。這很重要，因為它把 hosted LLM audit 從印象派，往可重複、可量化的檢驗往前推了一步。
它真正補的是哪個洞？
如果把這篇放回最近這一波 agent / model / runtime security 脈絡裡看，它補的不是 prompt injection，也不是 output safety，而是另一條更底層、但很可能會越來越重要的線：inference integrity。
最近大家談 AI 供應鏈，常聚焦在：
- 第三方 tool 或 skill 有沒有被污染
- memory / context / document 會不會被注入
- runtime action boundary 有沒有鎖好
但 hosted LLM 還有一個更前面的問題：你以為自己租到的是哪個模型，和對方實際給你的，是不是同一回事？
這一點一旦出問題，影響其實不只是效能。它還會直接牽動：
- 安全性：你以為自己依賴的是比較安全、拒答行為較穩定的模型
- 合規性：你對外承諾的模型版本與實際供應不一致
- 可審計性：事故發生後很難證明當時到底是哪個 backend 在回
- 成本誠信：使用者可能為高階模型付費，卻長期拿到降級版本
最值得注意的結果
根據摘要，作者把這個方法實作在三條 backbone 上：
- Qwen3-1.7B
- Gemma-2-2B
- Gemma-2-9B（搭配 131k-feature SAE）
更重要的是，他們不是只測一種很笨的 attacker，而是測了 17 種攻擊者，涵蓋：
- 同家族 scale-up / scale-down 替換
- 跨家族 substitute model
- 低秩 adaptive LoRA 類攻擊
摘要裡最有份量的一句，是：這 17 種 attacker 都被同一個共享、跨尺度穩定的 threshold 擋下來；反過來，這些 attacker 在對照組的 SVIP-style parallel-serve baseline 下都能躲過。
這代表什麼？代表這篇不只是說「我們也做了一個 audit 方法」，而是在指出：
如果 audit 還停在事後 probe 這個邏輯裡，那麼只要服務商能分辨 probe 流量，它理論上就能長期雙軌供應、騙過你對外看到的驗證。
為什麼這個 threat model 很現實？
我認為這篇很值得發，不是因為每家模型 API 今天都一定在偷換，而是因為它抓到了一個很真實的經濟誘因：更強的模型更貴，替代模型更便宜，而 hosted inference 對使用者又是高度不透明的。
一旦市場開始大量用 API 包裝模型能力、再把能力往上包成 agent platform、security copilot、enterprise assistant，這種不透明度只會更高。客戶看到的是：
- 品牌
- 模型名稱
- SLA
- 價格
但真正回應請求的是哪個 backend、哪個 checkpoint、哪個 routing policy，通常都看不到。這讓「模型替換」很像 cloud 時代的另一種 hidden infrastructure drift，只是這次 drift 不是 CPU 或儲存層，而是推理語義本身。
它和最近 sectools.tw 主線怎麼接？
如果把這篇放進今天這波文章脈絡，我會把它看成是補在 agent runtime security 與 AI service supply chain 之間的一塊空白。
- CapSeal 講的是 secret 不該直接交給 agent；這篇則在講 你信任的模型供應本身也需要可驗證承諾。
- Conjunctive Prompt Attacks、LogJack 這類文章處理的是內容如何把 agent 帶偏；這篇則在問 連底下那顆 serving model 是不是你以為的那顆，都能不能被證明。
- KV-cache / runtime substrate 類論文談的是 serving 層的技術風險；這篇進一步把 serving 層帶到商業誠信與第三方審計問題。
所以它不是傳統意義上的「agent 被攻擊」paper，但它對 AI 安全一樣重要，因為很多上層保證都建立在你至少知道底下是哪個系統在回應。
這篇最有意思的，不是 feature engineering，而是 control placement
我最喜歡這篇的一點，是它再次證明很多 AI 安全問題最後都會回到同一個老原則：不要把檢查點放在攻擊者已經能夠特殊對待你的時刻。
傳統 probe-after-return 的問題，本質上就是 control placement 錯了：你在服務已經把東西交出去之後，才要求它配合驗證。那麼對方只要能辨識這是驗證流程，就能特別演一套給你看。
這篇把控制點前移成 commit before open，本質上和很多 runtime governance paper 想講的是同一件事：真正有用的控制，通常都必須放在行為還來不及被事後美化之前。
限制也很明確，但方向是對的
當然，這篇不是萬靈丹。光看摘要也知道，現階段仍有幾個現實問題：
- 它需要供應商願意配合輸出某種 feature-trace commitment
- 它依賴公開 probe layer 與 probe library 的設計
- 跨模型家族、跨硬體噪聲、跨 serving stack 的校準並不簡單
- 大型閉源供應商未必願意公開足夠的中間特徵接口
但這些限制不會讓我覺得它不重要，反而剛好說明：如果未來企業真的想把 hosted LLM 納入高信任工作流，審計能力遲早要從「只看輸出」進化到某種更接近 execution attestation 的層次。
最後怎麼看這篇？
Committed SAE-Feature Traces for Audited-Session Substitution Detection in Hosted LLMs 最值得帶走的，不是 SAE 或 Merkle tree 這些關鍵字本身，而是它把一個以前常被當成「商業倫理」的模糊問題，往可驗證的技術審計推進了一步。
在 hosted LLM 時代，很多安全討論都還停在內容風險、工具風險、權限風險；但這篇提醒我們，還有一條更底層的線不能漏掉：
如果你連供應商實際交付給你的模型是不是那顆承諾的模型，都沒辦法驗，那很多上層安全保證其實都站在沙上。
如果要把這篇濃縮成一句最實務的結論，我會寫成：
AI 服務的下一步安全，不只要驗模型會不會亂講，還要驗供應商有沒有偷偷把你付費信任的那顆模型換掉。
本文由 AI 產生、整理與撰寫；內容基於論文摘要、公開資訊與脈絡化解讀，建議仍搭配原始論文交叉閱讀。