AI 編碼代理正在改變軟體開發的速度，也正在改變機密憑證外洩的速度。GitGuardian 發布的 2026 年機密擴散現況報告指出，被標記為 AI 輔助的提交，洩漏機密的速率大約是人類撰寫提交的兩倍。成長最快的洩漏憑證類別，如今大多與 AI 服務相關。原本用來加速開發的工具，同時也加速了開發流程所依賴的金鑰外洩。這不是一個新的漏洞類型，新的變化在於 AI 讓這類錯誤發生的規模與速度都大幅提升。
機密擴散在代理式 AI 時代的變化
這裡所說的機密，指的是 API 金鑰、存取憑證、服務帳戶金鑰等各類認證資料。機密擴散（secrets sprawl）指的是這些憑證累積在比組織能夠盤點和輪換的更多系統中：寫死在原始碼檔案裡、貼進設定檔中、複製到工單系統內。過去，安全團隊主要靠事後偵測來控制這個問題：掃描器監看程式碼儲存庫、pre-commit 鉤子攔截可疑內容、發現外洩後輪換憑證。這些機制仍然重要，但 AI 代理讓「只依賴偵測」這個策略的極限暴露無遺。
AI 編碼代理可以讀取整個專案、修改檔案、產生設定、呼叫 API，也能與 MCP 伺服器互動。MCP 的全名是 Model Context Protocol（模型上下文協議），它讓 AI 應用程式得以標準化地連接外部工具與資料來源。代理的每一項額外能力，都代表一個可能需要憑證的位置，也代表憑證可能擴散的新路徑。因此，文章主張，在代理式 AI 時代，機密擴散本質上是非人類身份（Non-Human Identity，NHI）問題，而不是模型行為問題。每一次代理對其他系統採取行動，背後都有一個身份在授權。當代理查詢資料庫、呼叫 API、部署到暫存環境時，都有某個憑證在授權這些動作。組織無法預測自主系統的每一個行動，但可以控制這個系統背後的身份被允許存取什麼。
AI 代理如何暴露機密
AI 代理之所以會暴露機密，根源在於代理需要脈絡。一個無法讀取整個專案的代理，能提供的協助有限。開發者常在 .env 檔案和本機設定中保存憑證，這些檔案可能是先前除錯時留下的，從未打算進入版本控制。擁有廣泛專案存取權限的 AI 代理，在分析應用程式程式碼時，可能一併讀取這些檔案。對代理而言，含有正式環境 API 金鑰的設定檔仍是工作環境的一部分；除非明確限制存取，否則這個憑證可能對代理可見，即使它與當前任務無關。這改變了開發者工作站的安全假設：本機明文憑證不再只對開發者和明確引用它們的應用程式可見，也可能被在同一環境中運作的軟體代理取得。
代理和 MCP 的設定過程也經常引入硬編碼憑證。為了簡化 AI 應用程式與資料庫、API 及其他外部系統的連接，許多設定指引會直接要求開發者把憑證貼進設定檔。這個檔案不進入版本控制，很容易讓人以為憑證是安全的，但它仍以明文形式存在於開發者機器上，而且往往位於代理有權讀取的位置。此外，同一個機密很少只存在於一個地方：同一個金鑰可能同時出現在 .env 檔案、CI/CD 變數、甚至 Jira 工單中。由於每一份機密副本都能通過認證，只輪換儲存庫中的那一份，其他副本仍然有效。這解釋了為什麼只靠儲存庫掃描無法解決機密擴散，也說明了為什麼很大比例的機密事故其實源自程式碼儲存庫之外的協作與工單工具。
代理憑證的權限過大是另一個風險來源。代理需要足夠的存取權限才能完成工作，這會形成授予廣泛權限的壓力。原型開發階段為了避免錯誤而授予的權限，可能就此成為正式流程的一部分，沒有人會回頭檢視。在多代理系統中，風險進一步升高：持有數個代理金鑰的編排層若被攻破，可能引發連鎖反應，攻擊者繼承編排者被授權存取的一切。
治理落差與傳統防禦的極限
治理上的落差已經可以量化。Keeper Security 在 RSAC 2026 的調查中發現，46% 的受訪者表示 AI 工具可以存取關鍵系統和敏感資料，但 76% 的受訪者表示這些身份並未持續受到特權存取政策的治理。即使授予了存取權，通常伴隨該等級存取權的控制措施並不存在。這說明了問題不在於 AI 模型本身的行為，而在於組織對機器身份的治理能力沒有跟上 AI 部署的速度。
具體應對方向
文章提出了幾項具體的應對方向。首先，從開發者環境中移除靜態憑證：不要在 .env 檔案、MCP 設定或 IDE 設定中保存機密，改為在需要時從集中式機密管理平台取用。如果工作站上根本沒有明文憑證，代理就無法從開發者環境中意外讀取。其次，以短期、自動輪換的憑證取代長期金鑰：靜態金鑰一旦外洩，在有效期間內都是負債；壽命只有幾分鐘且定期輪換的憑證，能大幅縮小攻擊窗口。第三，為每個代理賦予獨立且有範圍限制的身份：共用服務帳戶讓組織幾乎無法判斷哪個代理做了哪個動作，也讓每個代理都繼承所有代理中最寬鬆的權限。應該讓每個代理只擁有任務所需的權限，並盡可能讓權限是暫時性的。文章建議把 AI 代理當成約聘人員來管理：在限定時間內，允許它處理特定資源、執行特定動作。
機密管理的範圍也必須超越程式碼儲存庫。CI/CD 基礎設施、開發者工作站、MCP 設定、工單系統和協作工具都保存著儲存庫掃描看不到的憑證，而現在很大一部分機密事故正源自這些攻擊面。敏感操作必須有人為審核：憑證存取、正式環境部署和權限變更不應完全自動化，必須經過明確批准。自動批准模式應該是有明確範圍的政策決定，而不是開發者設定一次就不再回頭的預設值。組織也應該盤點已經在運作的代理和 MCP 伺服器：許多組織實際運作的代理比想像中多，往往是個別開發者自行安裝而未經適當審查。最後，必須記錄和稽核所有代理活動：非人類身份需要與人類身份相同的存取軌跡。沒有代理使用過哪個憑證、觸及了什麼的紀錄，事故回應就無法重建入侵過程，稽核時也拿不出證據。
總結來說，AI 代理並沒有創造機密擴散，而是揭露了許多組織在機器憑證安全上缺乏策略的事實。更多掃描無法解決問題，因為掃描永遠是在機密擴散之後才發現它們。真正有幫助的是集中化、零知識的控制，涵蓋機密的儲存方式、範圍界定與到期機制。像是 Keeper Secrets Manager 這類平台，正是讓組織集中保護基礎設施機密、從開發流程中移除硬編碼憑證，並在零信任、零知識架構下控制機密使用。AI 代理會繼續以更快的速度工作，但它們背後的憑證必須更短命、更窄範圍，組織才能有效治理它們的存取。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。