介面可以變簡單，危險不能跟著變輕
把同一個平台三年內的三份公開紀錄排在一起：2023 年實習生一鍵刪掉正式叢集、2026 年 6 月 CLI 把密鑰印進 AI 對話紀錄、2026 年 8 月平台被打穿讀走使用者的環境變數。三件事的形狀一樣：平台把複雜度藏起來，危險也跟著藏起來，最後由按下按鈕的那個人承擔。這篇講我們怎麼看，以及使用者該自己守住哪一段。
- 三份公開紀錄有同一個形狀：2023 年，日常帳號就能一鍵刪掉整區正式叢集；2026 年 6 月，標成「唯讀」的指令會把整個服務的密鑰印給 AI 代理；2026 年 8 月，使用者交給平台的環境變數被集中讀走，平台自己的監控沒發現。
- 這些都不是「平台太簡單」的錯。簡單是好事，問題是危險跟著被藏起來：按下去之前，介面沒有讓人看到影響有多大。
- 使用者能守住的是最後一段：假設平台保管的密鑰可能被讀走，讓每一把被讀走時都便宜（有範圍、有預算上限、能快速撤銷），並用平台怎麼面對失敗來決定要不要繼續信任它。
三個按鈕
第一個按鈕在 2023 年 10 月 27 日。一位實習生要清掉舊的測試叢集，他的帳號同時看得到、也刪得掉正式叢集，刪除前沒有任何人或任何機制再問一次。台北區整個正式環境離線約 50 分鐘。（完整拆解）
第二個按鈕在 2026 年 6 月 1 日被人寫成 issue。平台給 AI 代理用的技能說明，把檢查環境變數的指令標成「Read-only」；這個指令確實不會改任何設定，只是會把整個服務的每一個密鑰用明文印出來，直接進到 AI 的對話紀錄。（完整拆解）
第三個按鈕是每一個使用者每天都在按的：在平台的環境變數欄位貼上一把金鑰、按儲存。2026 年 8 月 27 日，攻擊者從一個使用者部署的應用程式進門，一路走到平台的正式資料庫，讀走專案環境變數的名稱與值。平台的監控沒有發現，隔天外部回報金鑰被盜用才知道。（完整拆解）
先講我們的立場：這篇不是要說這個平台不能用，也不是要說 PaaS 不安全。三件事我們都只用平台自己公開的紀錄，而且其中兩份報告寫得比多數平台坦白。我們要講的是一個設計問題，它在任何讓事情「變簡單」的工具上都會出現：介面可以變簡單，危險不能跟著變輕。
- 2023-10-27台北區正式叢集被誤刪；官方當天發布事後報告，承諾最小權限、破壞性操作另外切換角色、雲端稽核紀錄接告警官方事後報告
- 2026-06-01agent-skills issue #67：variable list 預設明文輸出所有值，建議預設遮蔽或加 --keys-only；截至 10-17 沒有維護者回應GitHub issue
- 2026-08-27攻擊者跨過共用叢集、平台 API 金鑰、AWS root 金鑰，讀走部分正式資料庫的專案環境變數官方完整報告
- 2026-08-28接到外部回報才確認事件；報告寫明當時監控與告警沒有發現官方完整報告
- 2026-09-09完整報告發布：環境變數改為預設存在使用者的專屬主機、Legacy API Key 停用官方完整報告、狀態頁
三年、三件事，時間軸上看不出關聯；把它們放在一起，才看得出是同一件事。
危險被藏起來，不等於消失
三個按鈕有一個共同點：危險操作和日常操作長得一模一樣。刪正式叢集和刪測試叢集是同一個指令；印出全部密鑰和確認一個變數在不在是同一個指令；把一把能刷掉十萬元的金鑰存進平台，和存一個功能開關是同一個欄位。
好的介面會讓摩擦力和影響範圍成比例。刪一個測試服務按一下就好；刪一整區正式環境，應該要切換角色、輸入名稱、等第二個人核准。查一個變數名稱不需要任何確認；印出整個服務的密鑰，應該要明確加上 --reveal。這不是把介面變複雜，是讓複雜度出現在它該出現的地方。
2023 年的報告其實已經寫出了這個原則：破壞性操作要手動切換專用角色、切換時告警、關鍵資源上鎖並要求 MFA。我們看到的問題是，這個原則停在「平台內部的人」，沒有延伸到「使用平台的人」和「替使用者執行指令的 AI 代理」。
預設值要以 AI 代理為最壞的使用者
到這裡，其實已經足夠理解我們的主張。如果你關心的是自己該做什麼，可以直接往「使用者能守住的最後一段」繼續閱讀。下面兩節講平台端，會稍微技術一些。
CLI 明文輸出這件事，三年前大概不會有人當成問題：工程師在自己的終端機上看到密鑰，看完就關掉。現在執行指令的常常不是人，是 AI 代理，而代理會把看到的每一行都留在對話紀錄裡、送到模型供應商、在下一輪對話中引用。工具的威脅模型變了，預設值卻沒有跟著改。
我們的看法是：任何會被 AI 代理呼叫的工具，預設值都應該假設呼叫者會記住一切。只列名稱、遮蔽值、明確要求才顯示，這些在給人用的時代是「貼心」，在給代理用的時代是「必要」。issue #67 提出的修法並不難，難的是承認使用者已經換了。
承諾要能被追蹤
2023 年的報告承諾，要把 AWS CloudTrail 與 Google Cloud Audit Logs 匯入內部系統，對危險操作設告警規則。2026 年的報告寫的是，AWS root 金鑰被使用、服務帳戶被授予叢集管理員、正式資料庫被大量讀取，當時的監控與告警都沒有發現。
我們不知道兩份報告講的是不是同一套系統，2026 年出事的也可能是報告所說「正在退役、隔離與存取控制還沒做完」的舊環境。所以這裡不下結論，只提一個要求：承諾的控制要有公開的落實追蹤。事後報告寫得再好，如果下一份報告裡同一類訊號還是沒人看到，使用者就沒辦法從報告判斷平台有沒有變得更安全。
另一個值得對照的地方是文件。平台的安全實踐頁面（本站 2026-10-17 查）寫到客戶工作負載在隔離的容器中執行、有網路層級的隔離，也寫到正式資料以 AES-256 靜態加密；但完全沒有提到環境變數存在哪裡、誰讀得到。8 月的報告則寫明，共用叢集允許跨專案的內部連線。兩者可能說的是不同的產品線，但使用者在選平台時，分不出來。
使用者能守住的最後一段
平台端的事，使用者只能要求，不能代替它做。使用者自己能完全掌握的，是「密鑰被讀走時會損失多少」。我們的建議分三層。
第一層，假設平台保管的密鑰可能被讀走。這不是不信任某一家，是信任的正確單位：你信任的不是平台，是平台所有邊界的總和，而 8 月的事件證明，那個總和可能少於任何一道邊界。改過名字也沒用，報告寫明值的格式認得出來就在範圍內。
第二層，讓每一把被讀走時都便宜。AI 供應商的金鑰設月用量上限；雲端金鑰只給這個服務需要的權限；資料庫帳號一個服務一組、不給管理權；能用短期憑證或從密碼管理器在啟動時注入的，就不要以長期明文存在平台上。做到這一層，平台再出事，你的損失有上限。
第三層，用平台怎麼面對失敗來決定信任。看它的事後報告：時間有沒有精確到可以對照、有沒有承認自己的錯、有沒有建議使用者「全部換」而不是「收到通知的才換」、承諾的改善之後有沒有追蹤。這個平台的兩份報告在前三項做得不錯，第四項還看不到。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| Google Cloud IAM（2023 叢集誤刪） | 開發人員帳號上的正式叢集管理員權限 | 日常開發與維運 | 人員帳號的 IAM 角色綁定 | 平台的 GCP 專案 | 可刪整區正式環境 | 官方表示已收回並改為最小權限 |
| 使用者服務的環境變數（2026-06 CLI issue） | 整個服務的所有環境變數值 | 使用者應用程式連外部服務 | 終端機明文輸出，進入 AI 對話紀錄 | AI 代理對話紀錄、模型供應商請求、本機備份 | 每次輸出一整個服務 | 工具端截至 2026-10-17 未修 |
| 使用者交給平台的憑證（2026-08 資安事件） | 專案環境變數的名稱與值：AI 與第三方 API 金鑰、雲端憑證、資料庫連線與密碼、簽章金鑰 | 使用者應用程式連外部服務 | 明文環境變數（儲存於平台正式資料庫） | 平台正式資料庫 | 受影響數量未公開 | 官方建議所有仍有效者預防性輪替 |
三列放在一起看，第一列是平台內部的人拿得到太多，第二、三列是使用者的密鑰去了使用者看不到的地方。
證據等級
這篇是觀點文，事實部分可以核對，主張部分是我們的推論，要分開看。
這篇提到的項目要花多少錢
讓密鑰「被讀走時便宜」的成本，大多是一次性的人力；把長期明文搬進密碼管理服務，有公開牌價可以算。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| AWS Secrets Manager：20 把密鑰 估：20 把是小型團隊的常見數量；呼叫次數依部署頻率而定 | 20 把 | US$0.40／把／月（API 呼叫另計 US$0.05／萬次） | 每月 | 8.00 | 256 | AWS 公開定價 |
| 盤點 PaaS 上所有有效憑證並標出損失上限 估：取中間值 NT$27,500 的半天 | 約 0.5 人日 | 顧問日費 NT$20,000–35,000（估） | 一次性 | 429.69 | 13,750 | 本站假設值 |
| 為 AI 與雲端金鑰設範圍、預算上限與告警 估：多數供應商後台免費提供上限設定 | 約 0.5 人日 | 顧問日費 NT$20,000–35,000（估） | 一次性 | 429.69 | 13,750 | 本站假設值 |
| 平台再次被打穿時，沒有上限的金鑰的損失 這一格填不出來，正是要先做上面三格的原因 | — | — | — | — | — | 無 |
| 合計（僅可證明列） | 0.00 | 0 | ||||
每月幾美元加上一個人日，換的是最後一格從「填不出來」變成「有上限」。
你可以學到什麼
站在攻擊者的位置看：他喜歡的是一個所有人都把密鑰放在同一個地方、而且每一把看起來都一樣的平台。他不需要知道哪一把最貴，因為全部都能拿。
- 01介面可以變簡單，危險不能跟著變輕。好的工具讓摩擦力和影響範圍成比例：影響越大，按下去之前越要看得見。
- 02任何會被 AI 代理呼叫的工具，預設值都應該假設呼叫者會記住一切。
- 03交給平台的密鑰，信任的單位是平台所有邊界的總和；讓每一把被讀走時都便宜，是使用者唯一能完全掌握的防線。
- 04事後報告寫得坦白是好事，但信任要看承諾的控制之後有沒有被追蹤、有沒有在下一次發揮作用。
- 05選平台時，要問清楚環境變數存在哪裡、誰讀得到、金鑰能不能設範圍與到期日；文件沒寫的，就是要問的。
- 01影響範圍（blast radius）三件事共同的問題：一個動作能影響多大，介面上看不出來。
- 02成比例的摩擦力本篇的核心主張：危險越大，操作前的確認越多；不是把介面全部變複雜。
- 03安全的預設值（secure by default）使用者什麼都不改時就該安全；AI 代理時代更重要。
- 04AI 代理作為最壞使用者代理會保留並轉送讀到的一切，工具設計要以它為威脅模型。
- 05預算上限（spend limit）讓 AI 金鑰被盜用時損失有天花板；使用者端最便宜的一道防線。
- 06短期憑證（short-lived credentials）有到期日的憑證被讀走時，能用的時間有限。
- 07密碼管理服務注入（secret injection）啟動時從 Secrets Manager 之類的服務取用，不以長期明文存在平台上。
- 08共同責任（shared responsibility）平台守它的邊界，使用者守密鑰被讀走後的損失；兩邊都不能假設對方會守住。
- 09落實追蹤（remediation tracking）事後報告承諾的控制，要能在之後被驗證有沒有運作。
- 10事後報告（postmortem）評估平台時最好的資料：看它怎麼寫自己的失敗，比看它的功能頁更準。
下面五步全部唯讀，做完你會有一張「每一把密鑰被讀走時最多損失多少」的表。
全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。
- 列出你放在任何 PaaS 環境變數裡、現在還有效的憑證（只列名稱與所屬服務，不印值）看到什麼代表什麼：這張表就是平台被打穿時，攻擊者會拿到的清單。
- 每一把旁邊寫上「被讀走時最多損失多少」看到什麼代表什麼：寫不出上限的（沒有預算上限的 AI 金鑰、管理員權限的雲端金鑰、資料庫 root 密碼），就是第一批要處理的。這張表我們叫「blast-ledger-u9k」，平台下次出事時先開它。
- 到 AI 供應商後台確認每一把金鑰有沒有月用量上限看到什麼代表什麼：沒有上限，外洩時損失沒有天花板。
- 確認 AWS 帳號沒有 root 存取金鑰
aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent'看到什麼代表什麼：0 代表沒有；1 就是整個帳號都放在一把金鑰上。 - 找出你用的平台的事後報告，看有沒有精確時間、有沒有承認自己的錯、有沒有建議全部輪替、之前的承諾有沒有後續看到什麼代表什麼：找不到任何事後報告，本身就是一個答案。
來源
每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。
延伸閱讀
第二次被打穿的，是上一次沒換的那幾把
同一個部署平台不到兩個月第二次被入侵，這次讀走約 321 萬筆環境變數、32 萬筆帳號資料，創辦人宣布年底停止營運。官方報告自己寫出關鍵：八月事件後的輪替只換了「確認外洩」的金鑰，設定儲存庫裡那幾把明文的管理權杖與雲端金鑰沒換，十月攻擊者用的正是它們。這篇拆解兩條入侵路徑，以及輪替範圍該怎麼畫。
一個使用者部署的聊天機器人，一路走到平台的主資料庫
Zeabur 在 2026 年 9 月 9 日發布 8 月 27 日資安事件的完整報告：攻擊者從一個使用者部署、對外公開的 NextChat 進門，跨過共用叢集網路、平台 API 金鑰、AWS 帳號、正式環境四道邊界，讀走部分正式資料庫裡的專案環境變數。報告也寫明：當時的監控與告警沒有發現，是隔天外部回報金鑰被盜用才知道。
AI 代理只想確認一個變數在不在，CLI 把整個服務的密鑰都印進了對話紀錄
2026 年 6 月 1 日，有人在 Zeabur 官方 agent-skills repo 開了 issue #67：官方技能教 AI 代理用 variable list 查環境變數，而這個指令預設把每一個值用明文印出來。作者說，一次長時間的 Claude Code 工作階段就這樣把資料庫連線字串和第三方 API token 送進了對話紀錄。截至 10 月 17 日，issue 還開著，CLI 最新版也還沒改。