先記結論：大型語言模型中繼站（LLM API 路由器，新聞裡常寫成「中轉站」）處在用戶端和上游模型之間，2026 年的實測論文把它寫成「對每一段在途 JSON 都有完整明文可見性的應用層代理」。HTTPS 只保護你到這座代理的傳輸。金鑰一旦寫進 Prompt 或工具參數，中繼站日誌裡出現它，並不需要再破解 TLS。
一句話先回答搜尋意圖
呼叫包裡會出現 SSH 金鑰，不是因為「HTTPS 壞了」，而是因為金鑰先被寫進了會發給中繼站的明文上下文。中繼站要轉發請求，就必須讀 JSON；讀得了，就存得了、賣得了。論文原句把邊界寫死了：第三方路由器以應用層代理工作，對每一段在途 JSON 都有完整明文可見性，用戶端和上游模型之間也沒有被強制加上可驗證的密碼學完整性。
這篇文章給正在用 IDE Agent、自建閘道或「便宜中繼」調模型的開發者和維運。它不代替 隱私清洗 的操作說明，也不重複「把工單貼進聊天視窗之前先掩碼欄位」那一篇。你要帶走的是：9 月這則貼文能當證據的部分到哪、HTTPS 擋的是哪兩個端、Agent 上下文為什麼比工單更容易夾帶整把私鑰，以及怎樣在本機用 Network 和一份即將送出的文字當場對照。
9 月這則貼文實際說了什麼
據 2026 年 9 月 11 日的公開報導 轉述，研究員 Chaofan Shou（壽超凡）在 9 月 10 日發文稱：他從一家頂級中文 LLM 路由器購得一份約 6TB 的 Fable 模型呼叫資料集；其中的 SSH 金鑰、VPN 設定、阿里雲金鑰和 GitLab Token，足以讓他存取 7 個中國／獨立國協相關機構，以及 19 家中國公司。貼文舉例點了若干品牌。多家華文資安媒體在 9 月 11 日跟進，繁體新聞也沿用「中轉站」這個說法。
這一段裡，能寫進核對清單的只有三句。第一，存在「中繼站會保存、甚至打包出售呼叫紀錄」這條攻擊面，而且有人公開聲稱買到了以 TB 計的資料。第二，被點名的憑證類型——私鑰、VPN、雲端金鑰、GitLab Token——都是 Agent 除錯時最容易整段貼進上下文的東西。第三，「足以接管」是研究員的能力主張，不是一份已由第三方稽核確認的入侵通報。FastPwd 沒有核驗那 6TB 檔案，也不把點名的品牌寫成「已被攻破」。
把熱點當成標題可以，把熱點當成已經判決的案情不行。你要處理的是同一條技術鏈路：明文 Prompt 出站之後，中繼站不再是「透明管道」。
中繼站看見的是哪一層明文
官方模型 API 通常是：你的用戶端直連廠商，TLS 終點是廠商。中繼站多了一跳：用戶端先把請求打到路由器，路由器再改寫成上游廠商的呼叫。對用戶端來說，憑證和網址列（或 HTTP 函式庫的 peer）停在路由器。路由器解開 TLS 之後，看到的是完整的請求體——系統提示、使用者問題、工具名稱、參數、有時還有儲存庫路徑和 .env 片段。
Liu、Shou 等人的論文 Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain（arXiv:2604.08407，對應 CCS 2026）把兩類攻擊寫進威脅模型：改寫工具呼叫載荷（AC-1），以及把金鑰從明文載荷裡撈走（AC-2）。他們購買了 28 個來自電商和獨立店鋪的付費路由器，又從公開社群收集了 400 個免費路由器。結果是：1 個付費、8 個免費路由器主動注入惡意程式碼；17 個觸碰了研究者自己放進去的 AWS 金絲雀憑證；1 個轉走了研究者測試私鑰裡的 ETH。後續投毒實驗裡，弱設定誘餌累計暴露 99 個憑證、覆蓋 440 個 Codex 工作階段，其中 401 個已開著無需確認的 YOLO 模式。
這些數字不需要你重現實驗。它們只說明一件已經發表的事：中繼站不但能「看見」，部分節點還會「改寫」和「動用」。付費不是免檢聲明。9 月的 6TB 資料包，是同一條鏈路上「看見並留下」被公開點名的一次。
| 你看見的現象 | 它能支持的結論 | 它支持不了的結論 |
|---|---|---|
| 用戶端顯示 HTTPS／安全連線 | 到目前 TLS 終點的傳輸被加密 | 中繼站看不到 Prompt |
| 中繼站能轉發工具呼叫 | 它必須解析明文 JSON | 它只做位元組透傳、從不寫進磁碟 |
| 研究員稱買到 6TB 呼叫包 | 存在「日誌被打包出售」的公開主張 | 點名的公司已被獨立證實入侵 |
| 論文測到路由器改寫載荷 | 部分節點不只是儲存，還會注入 | 所有中繼站都在投毒 |
| 工單已經做過規則遮蔽 | 常見手機號碼、身分證字號可能被掩碼 | Agent 上下文裡的整把 SSH 私鑰也被擋住了 |
HTTPS 擋路上的人，擋不住中繼站讀正文
MDN 對 TLS 的說明把保護範圍寫成：隔著不可信網路時，加密、完整性和伺服器認證發生在用戶端和伺服器之間；用來保護 HTTP 時叫 HTTPS。握手之後，HTTP 標頭和正文在這一跳上是密文。中繼站場景裡，「伺服器」就是路由器。它必須解密，才能知道要調哪個上游、工具參數是什麼。解密之後再存日誌，不再經過第二次「你以為的端到端」。
所以，「我們全程都是 HTTPS，金鑰不會外洩」在中繼站這條鏈上不成立。正確的句子是：公網這一跳有 TLS，路上的旁路封包擷取不容易讀到 JSON；路由器行程、它的磁碟、它的營運人員，以及買到資料包的人，不在旁觀者這一列。
官方直連也不能把廠商職員從「能看見明文」裡劃掉。差別在信任邊界畫在哪：你是把正文交給模型廠商的正式介面，還是交給一個以差價、額度或「可用 Claude」為賣點的第三方。後者往往沒有和你簽過與金鑰處理相關的合約，卻先於廠商讀到同一段 JSON。改一個 base_url 就能接上，這也是為什麼開發機和 CI 上的 ANTHROPIC_BASE_URL、OPENAI_BASE_URL 值得先清點。
Agent 上下文為什麼比工單更容易夾帶整把金鑰
把工單貼進網頁版聊天視窗，人至少還會掃一眼即將送出的字。Agent 和 IDE 外掛常常自動拼上下文：目前檔案、終端機錯誤、Git remote、.env、剛才執行失敗的 ssh 指令。YOLO 或「自動核准工具」一開，私鑰可以在你沒按送出的情況下進入請求體。論文裡 401／440 個工作階段已經跑在這種模式上，不是修辭。
規則遮蔽擅長蓋住手機號碼、身分證字號、電子郵件這類有固定形態的欄位。它蓋不住「把 id_rsa 全文當成附件塞進系統提示」、也蓋不住「把 AKIA… 和對應 Secret 寫成工具參數」。上一篇講的是外發工單前先核對欄位；這篇要先問：這次 JSON 裡有沒有整段可登入的秘密。兩件事都要做，不要互相替代。
必須交給同事的一次性口令，也不該改道寫進 Agent。更合適的路徑是閱後即焚：本機加密後只把密文交給伺服器，解密金鑰接在 s.html?id={id}#{key} 的井號後面。建立和閱讀都開啟即用。重新整理顯示已被焚燬，只說明伺服器上的密文沒了，不說明接收方沒截圖——那是另一篇文章的邊界。它至少比「把口令交給會存 6TB 日誌的中繼站」少一跳明文。
不要用真實 SSH 私鑰、正式環境雲端金鑰、未輪替的 GitLab Token 或未遮蔽工單做實驗。準備一串可丟棄的金絲雀，例如 CANARY-LLM-20260916。核對的是出站邊界，不是把還能開門的鑰匙再送一遍。
當場核對：Host、JSON、即將送出的文字
口號不能當證據。下面三步可以在目前機器做完，不需要帳號。目標不是重現 6TB 交易，而是確認你自己的用戶端這次把正文打到了誰、打出去了什麼。
- 開啟開發者工具 Network，或在本機代理／終端機裡看 Agent 的 HTTPS 對端。記下 Host：是官方 API 網域，還是中繼站、自建閘道、海外轉接。憑證簽發給誰，必須和這個 Host 一致。
- 造一枚不會出現在真實業務裡的金絲雀，寫進這一次 Prompt 或工具參數，送出後用整串搜尋請求體。命中就說明這段字元已經作為業務資料離開本機。網址列或 HTTP 函式庫顯示 HTTPS，不改變這條結論。
- 把「即將送出」的文字單獨對照一遍。SSH 私鑰頭
BEGIN OPENSSH PRIVATE KEY、雲端金鑰、GitLabglpat-、VPN 設定區塊，只要還在，就不要送出去。常見手機號碼、身分證字號、電子郵件可以先走規則遮蔽；整段口令和私鑰應改佔位符，或改走閱後即焚交給人，而不是交給模型路由。
Host 名單比小鎖更接近「誰能看見」
同一家公司可能同時有官方 SDK 和員工隨手配的 base_url。只看「我們用的是某模型」不夠，要看實際請求的主機名稱。中繼站經常用自己的網域終結 TLS，再在後面用它自己的上游金鑰去調廠商。你的金鑰出現在第一跳的 JSON 裡，廠商甚至不一定是唯一讀者。
即將送出的文字才是核對對象
頁面上的「已遮蔽」「隱私模式」「不用於訓練」只改變對方怎麼留存和學習，不改變欄位已經出站。中繼站若把呼叫包賣掉，訓練開關幫不上忙。對照對象永遠是這一次請求體，不是開關文案。
打包後的 Agent 可能把請求發到本機 localhost 代理，再由代理轉出。搜不到外網 Host 時，順著本機通訊埠看下一跳。本機代理不是終點，只是把明文又遞了一手。
三種把這則熱點讀過頭的情況
第一，把研究員點名的品牌寫成「已確認被駭」。貼文是能力主張，缺少與 FastPwd 無關的第三方取證，就不要寫成判決。你能做的是輪替自己環境裡出現過的同類憑證，並停止把有效金鑰送進中繼站。
第二，把「換成官方 API」寫成「明文不會離開本機」。官方介面同樣要在伺服器上讀 Prompt。它減少的是「差價中繼站寫進磁碟並出售」這一跳，不是「模型伺服端看不見」。本機模型或本機遮蔽，才把正文留在你控制的行程裡。
第三，把 FastPwd 寫成能替你稽核中繼站。它不代理模型流量，也不提供帳號或密碼庫。它能當場做的是：在瀏覽器裡掩碼即將外發的文字，以及用閱後即焚把一次性秘密交給人。檔案加密盒用 AES-256-GCM 處理不超過 5 GB 的檔案，輸出 .lock / .enc，預設不上傳明文——那是另一條「先加密再出站」的鏈，解決不了你已經寫進 Prompt 的私鑰。
常見問題
中繼站用了 HTTPS，Prompt 是不是就是加密的？
HTTPS 只加密用戶端到目前 TLS 終點的傳輸。中繼站本身就是這一跳的終點，論文把它寫成能看見全程明文 JSON 的應用層代理。路上的旁觀者不容易讀到封包；中繼站日誌、營運人員和買到資料包的人仍可能讀到 Prompt、工具呼叫和金鑰。
6TB 資料包是不是已經證實那些公司被攻破了？
不是。9 月 10 日的公開貼文是研究員的陳述：他稱購得約 6TB 呼叫資料，其中含有足以存取若干企業與機構的憑證。本文把它當作需要核對的公開主張，不把它寫成已驗證的入侵事實。你能當場核對的，是自己這次請求有沒有把有效金鑰寫進 Prompt。
這和把工單貼進 ChatGPT 之前先遮蔽個資是同一回事嗎？
不是同一層。工單遮蔽核對的是即將貼上的文字裡還有沒有手機號碼、身分證字號、電子郵件。中繼站問題核對的是：Agent 送出的 JSON 打到了哪一台主機，SSH 私鑰和雲端 Token 有沒有作為工具參數出站。欄位掩碼擋得住工單，擋不住把整把私鑰塞進上下文。
FastPwd 能擋住中繼站賣日誌嗎？
不能。FastPwd 沒有帳號，也不代理大型語言模型流量。它能做的是：在文字離開本機前用規則掩碼常見敏感欄位，以及把必須交給同事的口令改走閱後即焚，金鑰放在 URL 的 # 後面。開啟即用。有效的 SSH 金鑰和雲端 Token 本來就不該寫進 Prompt。
把同一串金絲雀用開啟即用的工具對照一次
若你要外發的是工單、日誌或錯誤堆疊，開啟 FastPwd 的 隱私清洗 即可，無需註冊。把可丟棄的測試段落貼進去，對照掩碼結果：手機號碼、身分證字號、電子郵件、常見 API Key 形態還應不應該以原文離開。原文預設不上傳。規則蓋不住的整段口令，不要「差不多就好」，改成佔位符。
若你要把一串一次性測試口令交給同事、而不是交給模型，開啟 閱後即焚，產生 s.html?id={id}#{key}。對照 Network：請求行應只有 id，不應出現井號後面的金鑰。這解決的是「人與人傳一次秘密」，不是「讓中繼站變安全」。
下次再看見「中繼站 6TB」「中轉站呼叫包裡有 SSH」時，先問三句。第一，這次 JSON 的 TLS 終點是官方介面還是第三方路由器。第二，即將送出的文字裡還有沒有整段可登入的秘密。第三，必須給人的口令有沒有改走井號後的金鑰，而不是改道寫進 Agent。能重複的觀察，才值得寫進你們自己的評審清單。
延伸閱讀
把工單和日誌貼進 AI 之前，怎麼先核對哪些欄位會離開本機，見 把工單和日誌貼進 AI 之前，怎麼先核對哪些欄位會離開本機。瀏覽器本地加密怎麼用金絲雀搜 Network，見 瀏覽器本地加密怎麼核對明文沒有離開本機。井號後面為什麼預設不進 HTTP，見 URL 的井號後面為什麼適合放金鑰，以及什麼時候會失效。