用 AI 工具會不會洩漏公司資料？從金鑰外洩案例看該怎麼設防

想把 ChatGPT、Claude，或是 Cursor、Claude Code 這類 AI 編程工具用在公司工作上，最怕的不是工具不好用，而是貼進去的文件、程式碼、API 金鑰會不會不知不覺外流。這個風險其實可以拆成三層來看：你主動貼給模型的內容、工具端替你保存的憑證與環境變數、第三方平台本身被駭。前兩層是你可以控制的，第三層則要靠挑對供應商和把金鑰管理做好來降低傷害。

AI 工具的資料安全風險，其實分三層

第一層：你主動貼進對話框的內容。 這是最直觀的風險，也是最容易忽略的——打開聊天視窗把整份合約、客戶名單或一段含密鑰的程式碼貼上去，資料就已經離開你的掌控範圍，接下來完全看供應商怎麼處理。

第二層：工具端幫你保存的憑證與環境變數。 這一層比較隱性。當你把 AI 編程工具接上自己的 API 金鑰，或是把專案的環境變數交給雲端部署平台代管，這些憑證就不再只存在你的電腦裡，而是放進了供應商的雲端工作區。供應商的管理方式會直接決定這些金鑰有多安全。

第三層：第三方平台本身被駭。 就算你自己的程式碼、用法都沒問題，平台端的系統如果有漏洞或治理缺失，攻擊者照樣可以拿到大量客戶的資料和憑證。這一層完全不是使用者能控制的,只能靠挑選有基本資安把關的供應商來降低機率。

案例一：AI 程式碼代理平臺 OpenCode，約 1.4% 使用者的金鑰可能外洩

2026 年 10 月 16 日，AI 程式碼代理平臺 OpenCode 發生資料外洩，約有 1.4% 的使用者受到影響，波及的是使用者接上的 OpenAI、Anthropic、Google 這三家服務的 API 金鑰。事後已經有使用者回報，自己的帳戶出現非本人發出的 API 請求，以及異常的費用扣款。OpenCode 也已經聯繫 OpenAI、Anthropic、Google 三家協助處理後續。

這個案例講的正是第二層風險：使用者原本是為了讓 AI 編程工具能呼叫模型服務,才把自己的金鑰接上平台,結果平台的資安事件讓這些金鑰反而變成攻擊者可以拿去用的東西,費用算在原始擁有者頭上。如果你平常會用 AI 編程工具,Codex、Cursor、Claude Code 這類工具的比較也值得先看過一輪,了解各家工具怎麼處理金鑰再決定要不要接上。

案例二：Zeabur 兩度遭駭，逾 321 萬筆環境變數被讀取

台灣的雲端部署平台 Zeabur，在 2026 年 10 月 14 日（UTC 時間）發生更嚴重的事件，攻擊者讀取了逾 321 萬筆環境變數和 32 萬筆帳號資料。值得注意的是,這已經是 Zeabur 第二次出事,而 8 月那次資安事件後,部分憑證其實並沒有完成輪替。

事後調查公布的原因分成兩個層面：一是共享叢集的管理介面對外開放,管理權杖沒有設有效期限,讓外部可以存取 9 個區域的共享叢集,攻擊者藉此讀取容器內的環境變數；二是內部憑證長期有效且以明文保存,其中 GCP 伺服器初始化設定的 root 密碼也是明文保存,這個問題早在 9 月 3 日就被發現,但沒有及時修正。

受影響的規模相當大：攻擊者在 865 個資料庫服務容器內執行讀取指令,以 root 權限登入 101 台 GCP 專用伺服器（涉及 92 名使用者）,在其中 50 台伺服器植入自己控制的 SSH 金鑰,還建立了 5 台虛擬機掛載 16 份客戶伺服器磁碟複本。更讓人在意的是監控上的缺失——從攻擊者首次使用內部憑證,到 Zeabur 啟動調查,中間相隔約 36 小時,期間完全沒有觸發任何安全警示,直到接獲使用者回報才展開調查。

這起事件最後的結局是,Zeabur 創辦人在 10 月 17 日宣布平臺將從 12 月 1 日起逐步停止服務,12 月 31 日前關閉全部專用伺服器與共享叢集。而這家公司在 2025 年 11 月才剛完成 200 萬美元的種子輪融資,不到一年就因為資安事件走到停業。

Zeabur 的案例把第二層風險講得很清楚：把環境變數、資料庫憑證交給平台代管,省下的是自己管理的麻煩,但承擔的是平台治理品質的風險。管理權杖沒有效期、憑證明文保存、監控機制形同虛設、事件後憑證沒有真正輪替,每一項都不是使用者能事先察覺的。

第三層風險不只發生在 AI 相關平台

第三層「平台本身被駭」的風險,並不是只有 AI 工具供應商才會遇到。

這些案例有個共通點：出事的往往不是「AI 本身不安全」,而是後端系統缺乏基本的存取控制、憑證管理鬆散,或是開發工具的供應鏈被動了手腳。AI 工具只是讓這些既有的管理缺失被放大、被看見。

AI Agent 工具的額外風險

如果你用的不只是聊天機器人,而是能自己執行動作的 AI 代理（AI Agent）,風險還會多一層。資通安全署提醒過幾種特別針對代理工具的威脅：惡意指令可能暗藏在外部網頁或社群留言裡,誘導 AI 代理執行刪除檔案、竄改系統設定這類危險操作；第三方的 Skill 擴充功能也可能被偽裝上架,安裝後植入後門或惡意程式；AI 代理長時間運作時,系統會自動壓縮早期的對話內容,結果連當初設定好的安全守則、權限限制都可能被「忘掉」。另外像是 OpenClaw 曾出現的 CVE-2026-25253 漏洞,攻擊者可以誘導使用者瀏覽惡意網頁,再對管理員權限進行暴力破解,而且不會觸發瀏覽器的安全警報,這個漏洞已經在 2026 年 1 月 29 日修補完成。

這些風險跟「貼資料給聊天視窗」是不同層級的問題，如果你正打算在公司導入 AI Agent，建議先看過 AI Agent 導入前要搞懂什麼的權限與風險檢查清單，以及 Vibe Coding 的風險說明，再決定要開放代理哪些權限。

評估一個 AI 工具時,該先問清楚什麼

在把內部或客戶資料上傳給任何 AI 工具之前,應該先確認資料的權限、保存方式,以及分享安排。具體可以先問供應商這幾件事：

• 我的資料會保存多久？會不會被用來訓練模型？
• 誰有權限存取我上傳的內容？
• 我能不能刪除或匯出已經上傳的資料？

敏感資料也應該先依公司政策分類,再決定能不能用。像是客戶資料、員工資料、合約、銀行資料,以及尚未公開的商業內容,原則上不應該直接貼進聊天工具,等確認供應商的資料處理安排之後再視情況決定。

金鑰與憑證管理的實作清單

金鑰（API key、資料庫憑證、SSH 金鑰、證書等）理想上應該集中存儲、供應、審計、輪換、管理，而不是散落在各個專案裡各自為政。具體可以從這幾件事開始：

生命週期要有明確流程。 每一支金鑰從創建、輪換、撤銷到過期,都該有清楚的規則,而不是建立之後就放著不管。

傳輸一律用加密通道。 金鑰切勿以明文傳輸,一定要透過 TLS。Zeabur 事件裡內部憑證和 root 密碼都是明文保存,就是這個原則沒被落實的直接後果。

定期輪換,但要分清對象。 原則是被盜的憑證只應該在短時間內有效,所以機器與系統之間使用的憑證應該定期輪換；但使用者的個人登入憑證,除非懷疑或有證據顯示已經被盜用,不需要為了輪換而輪換,過度頻繁反而增加管理成本。

留下完整的審計紀錄。 誰請求了這支金鑰、用在哪個系統和角色、有沒有獲批、何時使用、何時過期、有沒有人嘗試重用已過期的金鑰、何時更新及由誰更新——這些都該有紀錄可查。

盡量自動化,減少人手直接碰金鑰本身。 建立密鑰管道、使用動態產生的臨時密鑰、把靜態密鑰的輪換自動化,都是為了降低人為疏失或外洩的機會。

選對存放位置。 金鑰可以存放在 CI/CD 工具內建的密鑰功能（像 GitHub、GitLab、Jenkins），或是專用的密鑰管理系統（像 AWS Secrets Manager、GCP Secret Manager、Azure Key Vault、Hashicorp Vault、Conjur），也可以設計成由程式在執行時才去檢索,而不是寫死在程式碼裡。

CI/CD 環境要特別小心「大密鑰」。 長期存在、影響範圍廣、價值又高的密鑰是最大的風險來源,應該限制能接觸這類共享密鑰的人數,建立日誌和警報規則監控是否有異常提取或濫用,並確認專案被分叉（fork）之後不會把密鑰也複製出去。

備份要加密、要演練。 建立自動化的備份程序,定期執行並實際測試能不能順利復原,備份本身要加密,存放在存取權限受限的安全位置,同時也該事先規劃好緊急狀況下的「破窗」流程,不要等事情發生才臨時決定誰能動用緊急權限。

如果用的是公有雲,AWS 推薦用 Secrets Manager,權限可以在單支密鑰的層級授予,想要更高安全性的話還有 Nitro Enclaves 可以建立受信任的執行環境,或是用 CloudHSM 取得更多密鑰控制權；GCP 則推薦用 Secret Manager,同樣支援在密鑰層級授予權限。

接上 AI Agent 或編程工具時的額外防護

除了金鑰管理的通則,如果是把 AI 代理或編程工具接進日常工作流,還可以多做幾件事：

• 環境隔離：避免在存放機密資料或日常作業的環境直接安裝 AI 代理，應該部署在獨立電腦、虛擬機或容器裡。
• 帳號權限最小化：為 AI 代理註冊專屬的獨立帳號,避免直接用個人帳號,盡量搭配有時效性的臨時授權憑證。
• 高風險操作設人工審核：存取憑證、發送郵件、執行系統指令這類操作,應該強制啟用人工審核,不要讓代理自己說做就做。
• 親自審查第三方擴充功能：安裝任何第三方 Skill 之前先做安全掃描,留意內容裡是否要求下載不明檔案或連線到不明網站。
• 把安全守則寫進長期記憶：定期備份核心記憶檔案,確保重要的安全限制每次啟動運作時都會被強制載入,避免長時間運作後因為自動壓縮早期內容而被遺忘。

外洩之後,第一件事是讓金鑰失效

從 OpenCode 事件可以看到,三家模型供應商的處理方式是先封鎖受影響的金鑰。這其實呼應了金鑰管理的基本原則：被盜的憑證只要存在越久,風險就越高,所以一旦懷疑金鑰外洩,第一步應該是讓它失效（撤銷或輪換），而不是先花時間確認損害範圍再處理。之後再透過審計紀錄,回頭追查這支金鑰是誰在用、什麼時候用、有沒有異常的使用行為。

比起事發後手忙腳亂,更重要的是在事件發生之前,就先把「破窗」流程規劃好——誰有權限在緊急狀況下立刻撤銷金鑰、重新產生憑證,流程要多快能走完,平時就該想清楚,而不是等出事才現場討論。

把 AI 工具用進工作流程,風險不是「用就會洩密」,而是每一層風險有沒有被認真對待：該貼的資料先確認供應商怎麼處理,該管的金鑰集中管理並定期檢視,該隔離的 AI 代理給獨立環境和最小權限。這些事情做到位,AI 工具才能真正變成生產力,而不是變成資安事件的起點。