這起事件的核心，不是「AI 自己偷走密碼」，而是編碼代理取得更大的本機與外部系統操作能力後，認證資料也跟著散落到傳統安全控管看不到的位置。當 Cursor、Claude Code、GitHub Copilot CLI 能讀檔、執行指令，並透過 Model Context Protocol（MCP）連接程式庫、資料庫、雲端與 SaaS，開發者電腦就不再只是寫程式的終端，而成為多組機器身分與權限的集中點。
來源事實：憑證留下的是一條「端點足跡」
GitGuardian 的調查指出，API 金鑰、權杖與連線字串可能出現在 MCP 設定、環境變數、提示內容、指令輸出、除錯日誌、工作階段紀錄、Shell 歷史與暫存檔。部分檔案會進入 Git，但使用者家目錄中的設定與紀錄通常不會經過程式庫或 CI 掃描。該公司聲稱在公開 MCP 相關設定檔中找到 24,008 組不重複祕密，其中 2,117 組仍有效；Claude Code 輔助的公開提交出現祕密的比率為 3.2%，全體公開 GitHub 提交基準則為 1.5%。原始調查與產品說明見：https://blog.gitguardian.com/ai-coding-agents-credential-security/
這些數字必須放回來源脈絡理解：GitGuardian 本身販售祕密偵測與端點保護產品，3.2% 與 1.5% 是其觀察結果，並不能證明 Claude Code「造成」外洩。原文也明確承認沒有建立因果關係。因此，可確認的是 AI 輔助提交與較高的觀察外洩率同時出現，而不是工具必然導致洩密。
運作機制：安全儲存與周邊憑證是兩件事
三款工具並非完全以明文保存主要登入權杖。以 Copilot CLI 為例，GitHub 官方文件說明其預設使用 macOS Keychain、Windows Credential Manager 或 Linux Secret Service；但若系統沒有可用的金鑰圈，例如部分無頭 Linux 環境，使用者可將權杖存入 ~/.copilot/config.json 明文檔案。環境變數中的權杖還會優先於金鑰圈內容：https://docs.github.com/en/copilot/how-tos/copilot-cli/set-up-copilot-cli/authenticate-copilot-cli
Copilot 官方另列出 logs/、工作階段狀態、指令歷史、SQLite 儲存庫、MCP OAuth 備援資料及權限決策等本機項目。這證實問題不能只用「登入權杖有沒有進金鑰圈」判斷：https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-config-dir-reference
Claude Code 官方文件則顯示，專案層級的 .mcp.json 可提交到版本控制供團隊共享，也支援以 ${VAR} 引用環境變數；但設定格式同時容許環境欄位與認證標頭。換言之，工具提供較安全的間接引用，不等於能阻止使用者把真實權杖直接寫入設定：https://code.claude.com/docs/en/mcp?ref=blog.gitguardian.com
為何現在值得注意
合理推論：風險上升的原因不是新增一種檔案，而是權限、速度與規模同時改變。過去 IDE 多半消費程式碼；代理現在可以啟動本機程序、讀取更多目錄，並帶著使用者授予的身分呼叫外部服務。每增加一個 MCP 連線，就可能增加一組非人類身分、權限範圍與生命週期，既有的程式庫掃描卻只看得到其中一部分。
另一份由 Hush Security 進行的調查，分析約 82,000 份公開 MCP 設定檔，發現受檢憑證欄位中有 12% 直接寫入疑似憑證字串，當中 55% 沒有可供傳統規則辨識的供應商格式。該研究未向服務商驗證憑證是否有效，且 GitHub 搜尋只涵蓋預設分支、排除 fork 並受查詢上限影響，所以不能與 GitGuardian 的「有效憑證」數直接相比；但它獨立支持了「明文設定確實普遍存在、格式比傳統掃描規則更分散」這項風險判斷：https://www.hush.security/state-of-mcp/
實際影響與容易忽略的限制
若外洩的是低權限、短效且限定單一服務的權杖，衝擊可能受控；若是長效 GitHub PAT、雲端金鑰、資料庫連線字串或跨專案共用權杖，攻擊者可能讀取私有原始碼、存取資料或利用雲端資源。刪掉目前檔案並不等於完成修復：Git 歷史、其他開發者的複本、日誌與備份仍可能保留原值，正確事件處理順序應包含撤銷或輪替，再清除各處副本。
但端點掃描也不是萬靈丹。它可能遇到誤判、隱私與效能取捨，也無法取代 IAM、祕密管理器、EDR、程式庫掃描或 MCP 伺服器本身的授權檢查。OWASP 的 MCP 安全建議強調每個伺服器使用獨立且最小權限的憑證、優先採短效權杖、使用作業系統安全儲存，並在日誌中遮蔽祕密；同時還要限制本機伺服器的檔案與網路存取：https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html
對台灣開發團隊的意義
作者觀點：台灣團隊最該調整的不是「禁用 AI」，而是把開發者筆電視為正式的身分與祕密管理範圍。新創、接案商、供應鏈廠商與跨國研發中心常同時接觸客戶 Git、雲端帳號及內部系統；一台電腦上的代理設定，可能跨越原本分離的信任邊界。
- 盤點實際使用的編碼代理、MCP 伺服器、設定位置與可搬移的狀態目錄，不只檢查專案資料夾。
- 禁止在可提交的 MCP 設定中直接寫入祕密，改用安全儲存、執行階段注入或短效 OAuth；每個整合使用獨立、最小權限憑證。
- 保留 pre-commit 與 CI 掃描，同時將經核准的端點掃描納入管理；日誌、歷史與暫存檔須有遮蔽及保存期限。
- 發現外洩時，以「撤銷、輪替、查閱使用紀錄、清除副本」處理，不把刪檔或重新提交視為結案。
後續觀察指標
接下來可追蹤四件事：各工具是否預設拒絕明文憑證、企業管理政策能否統一限制 MCP 來源與權限、短效且按服務切割的 OAuth 是否取代長效 PAT，以及端點發現的祕密中有多少能在時限內完成撤銷。真正能衡量改善的，不是掃描出多少筆，而是未受管理的代理與長效高權限憑證是否持續下降。