雲端平台環境變數被拖走之後，新金鑰為什麼不該再發到聊天視窗
舊金鑰作廢只做完一半。新 API Key 一旦再貼進聊天、截圖或工單，就會留下可搜尋、可同步、可歸檔的明文副本。下面按公開事故把「第二輪外洩」拆開，並寫出當場能核對的交接邊界。不是閱後即焚的操作說明。
先分清 哪一輪 外洩
本篇只回答「輪替之後，新金鑰為什麼不該再發到聊天視窗」。不是閱後即焚的表單說明，也不是某家雲端平台的完整事故報告。
真正危險的是 第二輪
第一輪發生在託管端：舊金鑰已經被別人讀走過。第二輪發生在你自己手上：新金鑰又被寫成一條能留下來的訊息。
2026 年 8 月下旬，雲端部署平台 Zeabur 公開了一起環境變數被未授權讀取的事件。官方狀態頁寫明：攻擊者用一枚內部服務憑證，定向查詢並匯出了專案 Variables，目標是可直接使用的 AI 服務 API Key 和其他憑證。狀態頁列出的鍵名包括 OPENAI_API_KEY、ANTHROPIC_API_KEY、OPENROUTER_API_KEY、DATABASE_URL、AWS_ACCESS_KEY_ID，以及 JWT、Stripe、GitHub 等常見格式；自訂變數名只要值長得像這些憑證，也被算進暴露範圍。可對照 Zeabur 狀態頁事故說明。
iThome 2026 年 8 月 31 日報導補上了一條時間軸：公司在 8 月 26 日察覺異常，隔日呼籲使用者立刻輪替，並核對帳單與用量。同一週，科技新報轉述創辦人說明：查詢紀錄顯示攻擊者針對 AI API Key 做了定向匯出。暗網論壇上後來出現「完整資料包」的叫賣截圖，官方當時表示已掌握的證據並不支持那份材料的真實性——本文也不把它當成已證實事實。
這類事故裡，處理清單幾乎是固定的：作廢舊金鑰、檢查用量、輪替成新的。第一輪外洩已經發生在託管端，你無法把別人讀走過的字串從對方手裡收回來。真正容易被跳過的，是第二輪：新金鑰產生之後，你還要把它交給同事、貼進另一台機器的環境，或寫進臨時工單。這一步如果再走聊天視窗，等於把「剛輪替出來的明文」重新寫進一條可搜尋、可同步、可被管理員匯出的紀錄。
平台名在這裡只用來錨定時間和公開事實。結論對任何「先輪替、再交接」的場景都成立：資料庫密碼、CI Token、臨時 SSH 密碼，危險的不是「對方看得到」，而是「中間每一跳都可能留下一份完整明文」。本文不復盤某家雲端平台該如何加固，也不把 UsePwd 寫成能阻止託管端被讀的保險箱。
聊天視窗會 留下什麼
聊天軟體被設計成「說過的話還能找回來」。對日常協作這是優點，對 API Key 則是缺陷。
你把 sk- 開頭的字串貼進頻道後，至少會出現幾份副本。訊息正文會進該工作區的歷史；桌面端和手機端各自再存一份快取；有的產品會把內容送進伺服器搜尋索引，方便三個月後用「openai」兩個字撈回來。管理員匯出、法律取證、離職交接時的「聊天紀錄打包」，都會把當時那條明文一起帶走。刪除單則訊息，通常刪不掉對方已讀的推播、已下載的用戶端庫，以及截圖軟體順手留下的那一幀。
這和「信任同事」不是同一件事。同事需要那把新金鑰，才能把服務重新跑起來。問題在於：聊天通道預設按「可檢索的工作紀錄」來保存，而不是按「看完即止的一次性秘密」來保存。你在頻道裡寫「新 key 如下」，等於同時通知了所有能搜尋該頻道的人，包括後來被拉進群的人、擁有稽核匯出權限的人，以及未來某個能存取備份的人。
Slack、Discord、LINE、Teams 都會把正文留下。收回不保證對端快取消失。
主旨、附件、雲端文件留言都會被索引。一次「轉寄全部」就能再複製一份。
支援系統按工單號保存圖片。相簿備份、投影和會議錄影是另一條通道。
當場可以核對的辦法很土，但有效：打開你們團隊常用的聊天軟體，搜尋 sk-、AKIA、ghp_、Bearer 或 BEGIN PRIVATE KEY。能搜到多少則，就說明過去有多少次「先發再說」。這些紀錄不會因為你已經在雲端控制台點過 Rotate 而自動作廢——舊金鑰在託管端失效，聊天裡的那份字串卻還在。
外發工單或把聊天紀錄貼進公開頻道前，正文裡的 Token、手機號碼和身分證字號可以用隱私清理在當前分頁做脫敏對照。清理原文預設不上傳。這一步解決的是「發出去的文字還帶不帶秘密」，解決不了「秘密本身該不該進聊天」。
把金鑰從聊天裡刪掉，不等於外洩結束。對端可能已經複製、截圖或寫進自己的密碼管理器。本文討論的是「不要製造新的明文副本」，不是「刪訊息就能收回已讀過的秘密」。
輪替時哪一步 最容易再漏
事故通知信通常只寫「立刻輪替並檢查帳單」。真正漏掉的，是輪替之後那 20 分鐘裡的交接動作。
把常見應變流程攤開，危險點並不在「登入廠商控制台產生新 Key」這一下，而在前後幾步。有人會先把舊 Key 截圖發給同事確認「是不是這一把」；有人會把控制台整頁截下來，位址列、其他專案名和帳單數字一起進相簿；有人產生新 Key 後，因為「同事不在座位」，先丟進群裡說「先頂著」。這三步都會把明文寫成可長期保存的物件。
另一條更容易被忽略的路徑是雲端硬碟和儲存庫。有人把 .env 直接丟進共用資料夾，或把含金鑰的示例提交進臨時代碼分支。雲端同步會在每台已登入裝置上再落一份；Git 歷史即使後來改掉檔案，舊提交裡的字串仍在。單檔不超過 5 GB 的本機備份，應先在當前分頁打成密文再存，而不是把明文 .env 當普通文件上傳。UsePwd 的檔案加密盒用 AES-256-GCM 做串流本機加密，輸出 .lock / .enc，檔案預設不上傳。那是「自己留一份密文檔」，不是「把金鑰塞進聊天」。
Zeabur 事故裡，使用者最先感知到的往往不是「變數被匯出」這條紀錄，而是 AI 帳單突然跳用量。公開報導裡已有人在官方通知發出前就發現額度耗盡。這說明：舊金鑰可能已經被拿去請求過。此時如果把新金鑰再用同一條聊天通道發出去，攻擊者並不需要再入侵一次託管平台——他們只要能看到你團隊平時怎麼交接，就可能等到下一把。
新密碼本身也要夠隨機。隨機模式長度 6–128 字元，預設 16 字元；低於 8 字元時工具會提示安全性較低。產生走密碼產生器，在當前分頁完成，不必註冊。產生之後不要順手「存到瀏覽器」再截一張密碼管理器的畫面發給別人：那又回到截圖通道。
明文貼上和本機加密 差在哪
你必須把一段短秘密交給另一個人，又不希望通道歷史裡留下能直接使用的字串。先對照留下的是什麼，再選工具。
聊天視窗交出的是明文。接收方複製方便，發送方也方便，代價是工作區、搜尋和備份各持一份。郵件附件同樣如此：.env 或記事本一旦作為附件發出，郵件伺服器和雙方用戶端都有完整檔案。
一次性加密連結交出的是「密文編號 + 只在本機的解密材料」。UsePwd 閱後即焚在當前分頁用 Web Crypto 按 AES-256-GCM 加密文字，再把密文交給伺服器；解密金鑰接在位址 s.html?id={id}#{key} 的 # 之後。建立頁和閱讀頁都開啟即用，雙方都不用註冊。伺服器只暫存密文、有效小時數和閱讀次數，看不到明文，也沒有帳號體系可以「按使用者找回」。
把金鑰放在 # 後面，解決的是「託管端存取紀錄和 HTTP 請求列」這一層：瀏覽器不會把片段當作請求的一部分發出去。原理拆解見已有文章URL 的 # 片段為什麼不會出現在伺服器日誌裡。本篇要補的是另一層：即便金鑰不進 UsePwd 的請求列，你把完整連結貼進聊天後，聊天軟體仍然保存整串位址。誰拿到完整連結，誰就能在次數用盡前打開閱讀頁解密。閱後即焚限制的是伺服器上密文的壽命和次數，不是接收方是否截圖、是否轉發。
歷史可搜尋。作廢雲端舊 Key 之後，聊天裡的字串還在。
次數用盡後伺服器刪除密文。連結失效，不等於聊天紀錄被擦掉。
密文檔可進雲端硬碟。口令仍須另通道交接，不要寫在同一則訊息裡。
因此，閱後即焚適合「看完即止的短秘密」：新 API Key、臨時資料庫密碼、一次性驗證碼。它比把 sk- 直接貼進群更乾淨，因為通道歷史裡不再是能直接呼叫廠商 API 的字串；對方打開並達到設定次數後，伺服器上的密文刪除，遲來的搜尋結果打不開明文。它仍然要求你信任發送通道本身——完整連結不要發到公開頻道，也不要連同口令截圖一起發。
UsePwd 沒有帳號，沒有密碼庫，也不能按使用者找回口令。連結丟了、片段被截斷、次數用盡，伺服器都無法替你還原明文。需要長期保存、多裝置同步或緊急找回時，應使用專門的密碼管理器，不要把本站理解成帳號系統。身分說明見關於。
本機加密交接不能挽回已經在託管端被匯出的舊金鑰。舊的必須先作廢。本文只討論新金鑰怎麼交給同事，避免第二輪明文殘留。
當場怎麼 核對交接
目標不是證明「全世界都看不到」，而是證明：這次交接沒有在聊天歷史裡留下可直接使用的明文。
-
01
先作廢舊金鑰，再產生新的
在對應廠商控制台撤銷已暴露的 Key。不要用真實生產金鑰做下面的練習。示例字串只要你自己認得出來即可，例如
demo-not-a-real-key-2026。 -
02
打開閱後即焚，不要先打開聊天
進入閱後即焚。頁面開啟即可用，不必登入。把示例文字加密成一條連結。形態應是
s.html?id={id}#{key}：問號後只有編號，金鑰只在#之後。 -
03
把連結發給接收方，不要把示例文字再貼一遍
聊天視窗裡應只出現完整 URL。若你習慣先打字「key 是 xxx，連結在下面」，就等於同時留下明文和連結，一次性材料失去意義。
-
04
接收方打開後，回看頻道搜尋
在該頻道搜尋示例字串本身。應當搜不到正文裡的那串字，只能搜到連結。再搜尋
s.html?id=，確認你沒有把連結截斷到#之前——缺了片段，對方只能取到密文，無法在本機解開。 -
05
需要時再用網路面板看請求
建立時的 POST 正文應是密文和兩個數字，不是示例文字；隨後的 GET 路徑裡只有
id。這一步核的是「金鑰有沒有進 HTTP」，與安全說明互補。生產環境可能還有發往/tj/的訪問分析，載荷是頁面與按鈕名，不是明文。
工單場景多一步：發給支援人員的截圖裡，用隱私清理先對照 Token 是否仍以完整形式出現。清理在當前分頁完成，原文不寫進分析。核對的是「像素裡還有沒有能直接貼上使用的金鑰」，不是「工單系統安不安全」。
什麼時候連連結也 不該用
一次性連結減少的是「通道歷史裡的明文金鑰」，不是「世界上所有能看見螢幕的人」。
若秘密需要被長期保存、在多台裝置之間同步，或將來必須能找回，不要用閱後即焚，也不要依賴聊天紀錄當保險箱。那是密碼管理器的工作。UsePwd 不提供帳號或密碼庫，次數用盡或連結遺失後無法代為復原。
若秘密是高價值主金鑰、根憑證或能轉走資金的錢包助記詞，連結和聊天都不夠。當面口述、離線媒體，或只在雙方已經建立的端對端通道裡傳。片段方案擋不住本機已被控制、瀏覽器擴充功能能讀當前頁面，也擋不住你把完整位址投影到會議室牆上。
檔案備份走另一條路徑：明文 .env 先在本機打成 .lock / .enc，再進雲端硬碟；解鎖口令用不同於檔案本身的通道交接。兩條工具不要混成同一種保證：焚鏈管短秘密的次數，檔案盒管你自己留著的密文檔。
回到這篇的問題。雲端平台環境變數被拖走之後，舊金鑰必須作廢，這沒有捷徑。新金鑰不該再發到聊天視窗，是因為聊天預設保存可搜尋的明文，而輪替的意義就是讓舊字串立刻失效——你不該在同一分鐘裡，再製造一份活得更久的副本。需要一次性交給同事時，用本機加密、開啟即用的閱後即焚；需要自己留備份時，用檔案加密盒。兩頁和本篇一樣，頂欄右側只有語言切換，沒有登入入口。
讀完去 核對通道
文章回答「新金鑰為什麼不該再發到聊天視窗」。要產生一條可焚毀的加密連結，打開閱後即焚即可，不必先註冊。