Claude Code 憑證外洩解讀：永久批准為何留下密碼？Anthropic 回應與防線（2026）

2026 年 11 月 5 日，Apiiro 的 Shmulik Cohen 與 Matan Giladi 發布了〈Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub〉，把 Claude Code 憑證外洩的焦點放在一個容易忽略的地方：你按下「以後別再問」之後，批准內容究竟存在哪裡。原文於 11 月 8 日補上 Claude Code 團隊的回應。

先讀研究發現，再對照 Anthropic 與 Git 的文件，最後判斷應該改哪一道防線。核心問題很具體：允許執行一個動作，和允許長期保存它用到的密碼，是兩個不同決定。

一、Claude Code 憑證外洩：批准，如何變成留存？

This is Claude Code’s own behavior, not the model’s:

中文：這是 Claude Code 執行工具本身的行為，而不是模型本身的行為。

Apiiro，原文機制說明；冒號後另接其測試敘述。

這句話值得留下，因為它把問題從「模型會不會說錯話」移到「產品會把哪些內容寫進檔案」。Anthropic 的權限文件證實：選擇永久批准時，規則會存入 .claude/settings.local.json；Bash 的批准可跨未來工作階段生效。規則可以精確匹配命令，也可以使用模式。若把含密碼的命令字串存成規則，密碼便跟著成為持久資料。

可以把它想成門房留下通行名單。名單需要記住「誰可以做哪件事」，卻不該順便抄下保險箱密碼。執行當下需要一份憑證，並不代表批准紀錄也需要保留其明文。這是保存格式與資料流的設計問題，不能靠換一個推理分數更高的模型來推定已解決。

二、2,539 是調查結果，不能直接當成入侵數

Apiiro 於 11 月 1～3 日搜尋公開 GitHub：104,185 份本機設定檔中，1,122 份含其判定的秘密值，合計 1,379 個；擴及歷史與其他 Agent 產物後，報告為 1,994 個儲存庫、2,539 個不同秘密值。這些是研究方的統計，本文未獨立重掃。

其方法結合格式、公開主機脈絡、排除規則與遮蔽後的 LLM 複核；部分其他產物僅用規則分類。作者明言未使用憑證或連線測試。因此，這份研究支持「敏感值被公開」，不等同逐一證實仍有效、有人登入成功，或已有多少組織遭入侵。

這個界線不會讓風險消失。對防守者而言，公開的鑰匙即使尚未證實被使用，也值得撤換；對報導者而言，卻不能把「看起來像可用鑰匙」直接寫成「已經有人進門」。應變可以保守，對事實的描述仍要精準。

報告還稱兩款掃描器都漏掉部分檔案，並把範圍延伸到對話、記憶與交接產物。它要推動的改變，是把 Agent 的紀錄一併納入秘密值管理，而非只盯著 .env。Apiiro 本身販售應用安全產品，這讓我們更需要查方法與分母，而不是把商業動機當成推翻結果的證據。

三、官方回應談的是防護方向，交付狀態要另外認

Boris Cherny 在 11 月 7 日的 Hacker News 回應中表示，團隊過去未做秘密值清理，正在思考如何預防；也建議使用 Auto Mode 與秘密值掃描。另一則回覆提到，會先對幾種方法做原型、了解取捨，再出貨。

Going to prototype a few of these to understand the tradeoffs better before we ship something.

中文：會先把其中幾種方法做成原型，更了解取捨，再交付。

Boris Cherny，Hacker News 討論串中的回覆

讀這段 團隊公開討論，應把「正在評估」放在正確時態。它證明負責人回應了問題，也說明候選方向；它本身不是某個已發布版本通過防漏驗收的證明。本文截至 2026 年 11 月 9 日查閱的證據，採用這個有限判斷，不把原型承諾改寫成修補完成。

同樣地，官方安全文件把 Auto Mode 描述為由另一個分類器審查動作；Sandbox 文件則說明作業系統層的檔案與網路限制。兩者各有工作：前者審查動作，後者限制 Shell 可達範圍。要知道秘密值是否會進入批准檔、輸出或成品，仍得檢查實際保存路徑與產物。

四、Claude Code 憑證外洩的關鍵：本機排除與專案邊界

這裡需要修正一種過度簡化：不能說 Claude Code 完全不處理 Git 排除。目前官方設定文件明列，工具在 Git 儲存庫首次寫入本機設定檔時，會把對應模式加入使用者的全域 Git 排除檔；若自行建立，則應自行加入排除。共享的 .claude/settings.json 與個人的 settings.local.json，用途也不同。

但「這台電腦會忽略它」和「這個專案到哪裡都會忽略它」是不同保證。Git 官方文件說明，全域排除屬於使用者設定；需要隨 clone 分發的模式應放進專案的 .gitignore。更關鍵的是，忽略規則不影響已經被 Git 追蹤的檔案。先確認追蹤狀態，才知道補一行排除能解決哪一段問題。

因此，單憑「工具預設會忽略」，無法倒推出每一份公開副本一定由使用者手動建立。那需要逐案的建立時間、追蹤紀錄與工具版本。反過來，找到公開副本，也不能推定每個版本在所有環境都不會排除。對產品責任與使用者責任的判斷，最好落到可重跑的情境，而不是猜誰按了哪顆按鈕。

五、AlphaLab 的判讀：把授權和秘密值分開設計

我同意：設定與紀錄應列入機密資料清冊

這起事件有價值的提醒，是批准紀錄也可能成為資料副本。對維運團隊而言，清冊應沿著流程走：輸入從哪裡來、誰能讀、工具如何取得憑證、哪些內容落盤、哪些檔案會離開電腦。只檢查原始憑證檔，容易錯過後來產生的副本。Geiger 設定曝險盤點可補足清冊思路，但掃描報告本身同樣需要控管。

我存疑：換成自動批准，就能回答全部問題

降低人工確認疲勞有其價值；但「哪個動作值得執行」與「哪些字元值得保存」需要不同驗收。更好的評估題應是：含假憑證的命令經過批准後，設定、對話、日誌與交件各留下什麼？這是建議的測試設計，本文未對 Claude Code 執行重現，也未接觸外洩帳戶。

執行隔離與秘密值生命週期也應分開看。一個動作可能被允許，憑證卻仍應短效、限權、可撤銷；一個秘密值可能沒有進入 Git，卻仍可能落在備份與封裝成品。Auto Mode 與 Sandbox 的分工以及 Agent 撤權與既有 Token 的界線，分別補上這兩層問題。

下一份好證據，應證明秘密值走到哪裡為止

我會追蹤的驗收很具體：工具版本固定、使用合成秘密值，分別測未追蹤、已追蹤與跨機器 clone 的專案；記錄批准前後的檔案差異，再檢查歷史與輸出成品。通過某個案例，只對那個配置成立。廠商若公開這類測試，比一句「更安全」更能幫團隊決定是否導入。

六、現在先做什麼：先讓公開的鑰匙失效

如果你懷疑憑證已公開，先到發行服務撤銷或輪替，核對用途與存取紀錄，再安排清理。GitHub 的處理指南也是先撤銷／輪替，再評估歷史清除；只刪最新檔案，無法收回他人的 clone 與 fork。處理歷史需要協調，別在緊急狀況直接對共享儲存庫強推。

接著在自己的專案私下檢查本機與共享設定、暫存變更及歷史：不要把整份含值輸出貼進聊天、工單或新的公開報告。對尚未曝光的憑證，優先讓受控執行工具從秘密值管理取得所需值，批准規則只描述必要動作。即使改用環境變數，也要避免展開、除錯輸出或工具紀錄再次寫出真值。

最後，啟用適用於儲存庫的 GitHub 秘密值掃描，並用合成資料驗證團隊使用的掃描規則。掃描、提交檢查、權限限制與憑證輪替各擋不同階段；不要把其中一道通過，當成其他階段的證明。要理解這些檢查如何放回執行循環，可以接著讀 Agent Harness 的分工與 最小 Harness 實作。

今天最值得做的一件事，是確認你的永久批准紀錄，究竟只記了動作，還是也留下了鑰匙。如果已經公開，先換鑰匙；如果還留在本機，先把保存路徑整理清楚，再談提高自動化程度。