AIDEFEND in Action AIA-0116 實證研究發布於 AIA: 2026年10月26日

Compaction Smuggling：壓縮對話成為轉移隱藏推理內容的管道

Xint 測試了 OpenAI API 的對話壓縮功能，也就是把先前工作整理成後續模型可接續使用的內容。研究者利用可由用戶端指定的壓縮指示，將 gpt-5.6-sol 受保護的推理內容轉存為加密壓縮項目，再交給 gpt-4.1 或 gpt-4o 回傳可讀文字。這是以研究者自己的題目進行的受控 API 測試，未展示竊取其他使用者的對話。Xint 表示，問題已於 2026 年 10 月 23 日以未公開細節的方式修補。

Privacy LeakageData GovernanceSession IsolationAI Infrastructure

5 項對應的 AIDEFEND 防禦手法

來源: Stealing OpenAI Reasoning Traces via Compaction Smuggling

作者: Tim Becker

原文發布: 2026年10月26日

威脅分析

同一份受保護內容換了載體：研究者先取得加密推理項目，再要求同模型的壓縮功能保留該內容，且不附原始題目。產生的新壓縮項目被較舊的接收模型接受，接著回傳文字。過程沒有取得加密金鑰。
回傳結果一致，仍有驗證限制：兩個接收模型配合兩種提示，得到一致的表示內容。這支持模型確實回傳了壓縮內容，但原始明文無法取得，因此不能證明每個 token 都與原推理相同。已測試題目也都是合成資料。
不同研究不能合併成同一事件：較早的 Stolen Thoughts 區塊重用，以及 GhostCompact 計費問題，各有不同前提與結果。OpenAI 九月公開的活動報告只是背景，不能證明該次活動使用了本篇這條路徑。Xint 表示 OpenAI 已在 10 月 23 日修補，細節未公開；本篇沒有獨立驗證實作方式或目前是否仍能重現。

適用的 5 項 AIDEFEND 防禦手法

AID-I-004.007

Task-Bounded Context Segmentation & Secret Demotion

高

在供應商將推理資料交給壓縮器前，把高權限中間推理內容留在伺服器專用區，不讓受用戶端指示影響的摘要模型讀取。只提供已核准可顯示的任務與結果，或不能用來取回原文的參照；不能讓用戶端把隱藏推理標成可見工作內容。這需要在解密內容組裝成模型輸入前，接上供應商元件，並取得可信的處理階段與來源清單。只加文字標籤、卻仍讓壓縮器讀到原文，並沒有隔離效果。排除隱藏內容可能降低接續工作的品質，部署前須評估。

AID-H-037.001

Reasoning-Trace Confidentiality & Storage Controls

高

模型供應商可由伺服器標記隱藏推理內容，以及衍生出的每個壓縮項目，禁止它們經一般顯示或日誌路徑揭露，只允許獨立審核過的摘要。改欄位名稱、JSON 編碼或空白格式，都不能移除限制；缺少可信來源標記或核准時就拒絕。範例只過濾 reasoning_trace 欄位，會漏掉本案的 solution 欄位，因此正式元件必須依可信來源與衍生關係分類，管住壓縮器明文及最後解碼模型的回傳。單純使用 API 的客戶，無法在提供者的不透明項目內補上這項控制。

AID-H-037.003

Provider Reasoning-Block Round-Trip Integrity

高

供應商可在每次使用不透明項目前，驗證原始位元組及其簽發帳號、模型／路由、對話、區塊類型、政策與期限。推理內容轉成新的壓縮載體時，仍須保留受保護的來源，拒絕轉交未經審查的接收模型，例如本案的較舊解碼模型。合法模型切換可另產生通過審核、已移除保密內容的資料。單純簽章正確或位元組未變，本案仍能通過；綁定必須涵蓋衍生項目與所有直接 API 路徑，不能只保護某一個應用程式代理。

AID-I-004.008

Context Summary & Compaction Integrity

高

供應商可在簽發或重用新的加密壓縮項目前，要求符合封閉的摘要規格、核對已核准輸入的完整來源，並用範圍明確、能得出確定結果的規則檢查一致性；無法驗證的結果先隔離。任意 solution 物件或夾帶推理的自由文字都不能只因 JSON 格式正確就通過。G001 流程必須取得 G002 的驗證結果，可信政策由獨立來源重建；失敗時只能保留已核准的可見訊息，不能又取回造成外洩的隱藏推理。這需要加密前的檢查介面，或停用不支援的壓縮路徑，不是要求客戶閘道檢查密文。

AID-M-007.002

Release Conformance Gate for Safety Boundaries

高

壓縮器、推理模型或接收端元件發布前，供應商可針對真正部署的組合，依已簽署的保密範圍規格，執行完整測試。涵蓋原始項目轉成壓縮項目、再交給解碼模型的流程，以及不同接收模型、編碼欄位、串流、拒絕與備援路徑。由不同管理身分的觀察者檢查真正回傳的位元組與受保護內容存取；任何違規或案例缺漏都阻擋發布。結果只證明測試範圍內的發布符合性，不是所有攻擊都不可能成功，也沒有揭露 OpenAI 未公開的修補方式。

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

模型供應商與推論平臺開發者，應盤點所有能解密隱藏推理、轉換內容、簽發新不透明項目，或接收它來接續推論的元件。每一次轉換都必須維持相同的受保護來源政策，也涵蓋合作夥伴代管與直接 API 路徑。
盡可能讓受用戶端指示影響的壓縮器無法讀取原始隱藏推理。若接續工作確實需要保留該內容，就只允許經審查的轉換與接收模型；無法驗證保密限制時，直接拒絕，不簽發可任意轉移的內容。
發布前，以受控資料測試推理轉壓縮、再交給接收模型的流程，涵蓋欄位改名、編碼、模型切換與串流，並由獨立監測元件觀察真正回傳內容。同時量測接續品質、模型切換功能及禁止揭露的結果。本篇提出的是部署檢查，沒有主張已對 OpenAI 未公開的修補實作完成測試。
應用程式開發者可以把不透明項目留在伺服器，所有流量都經過自己的閘道時，再強制套用綁定路由的封裝。一般 API 使用者無法檢查供應商的隱藏明文，也無法自行修補整個提供者服務；應取得目前供應商的證據，並分清各篇相關研究的範圍。

結論

AIDEFEND 將這次內容轉換，對應到來源隔離、推理保密、範圍明確的壓縮驗證、接收模型綁定，以及發布符合性檢查。供應商掌握解密與使用內容的元件時，就能在這些位置強制執行限制。受保護內容換成新的加密包裝後，仍不應因此讓限制較少的模型取得揭露權限。

最後更新: 2026年10月26日