Claude Code 機密外洩：Apiiro 在 1,122 個公開 GitHub 檔案中發現憑證

Apiiro 報稱在 1,122 個公開 GitHub 設定檔中發現憑證後，Claude Code 機密外洩令 Anthropic 的已儲存批准機制受到審視。其 11 月 5 日的研究描述了一項會記住含有機密資料之命令的功能。要公開這些資料，還須進行另一個步驟：提交並推送所產生的檔案。

爭議在於實用捷徑與它所建立的敏感紀錄之間。開發者批准某項操作以完成工作，而軟件則保留了本應獲得獨立保護的資料。關於執行的決定，變成了關於儲存的決定，而使用者往往不會將兩者視為不同的選擇。

Anthropic 已確認這項疑慮，同時強調設定檔應保留於本機。Cursor 提供了一個有用的比較，因其文件同樣談及自主執行及其風險。這些產品共同面對的問題是：權限系統如何在保留便利性的同時，避免再建立一個累積憑證的位置。

Claude Code 機密外洩發現實際量度的是甚麼

Apiiro 的憑證暴露研究檢視了 104,185 個公開的 .claude/settings.local.json 副本。研究在 1,122 個被標記的檔案中識別出 1,379 項不同的機密資料。研究人員沒有測試這些憑證，因此該數字並不能證明存取權仍然有效，或曾成功入侵。

標題所量度的是暴露的檔案，而非已遭入侵的帳戶。 這個分別關乎事故應對、採購決策，以及任何對發現嚴重程度的說法。憑證的存在足以構成調查理由；其有效性及權限則決定眼前後果。

底層流程並不陌生。編碼助手提出某項操作，開發者檢視後，持續有效的批准便可減少日後的中斷。意料之外的後果會在已儲存的批准保留了開發者原以為只是暫時使用的資料時出現。

以測試環境資料庫檢查作為示例情境。開發者需要助手調查連線失敗，並批准一項包含驗證資料的命令。完成該檢查，並不需要讓憑證成為持久存在的專案成品。

然而，批准紀錄可以保留該操作正正所需的資料。它的用途聽來像行政事項，因此人們很容易在心理上把它與密碼及存取權杖分開。當審閱者以為設定只包含偏好，而非敏感的操作資料時，這種區分便會變得危險。

公開儲存庫又增加了一道界線。原本只可由開發者電腦取得的資料，變成任何能閱讀專案的人都可取得。因此，批准功能與發布流程都需要分開檢視。

若說選取該選項會自動將密碼傳送至 GitHub，便是誇大證據。據報的過程涉及先在本機持久儲存，然後透過記錄及分享專案變更的版本控制系統發布。每個階段都提供了預防機會。

但若只將問題形容為粗心提交，也同樣低估了問題。產品行為決定了有甚麼敏感資料存在，讓人可以提交。更安全的發布流程固然有幫助，但避免不必要的憑證副本，處理的是問題較早出現的部分。

相關的改變在於團隊在審閱時必須考慮的事情。代理設定應與應用程式程式碼及部署設定一併受到關注。即使檔案不包含可執行程式，它仍可透過所保留的資料影響安全。

這擴闊了敏感變更的含義。審閱者不只要考慮檔案令應用程式做甚麼，也要考慮它揭露甚麼。權限紀錄正處於兩者的交匯點。

本機設定檔是一項附帶條件的承諾

Anthropic 的本機設定文件指出，持續有效的 Bash 批准會成為 .claude/settings.local.json 中的允許規則。Bash 是用來執行程式的命令殼層。當 Claude Code 在文件所述條件下首次寫入該檔案時，會在開發者的全域 Git ignore 設定中加入排除項目。

文件另行指出，.claude/settings.json 是團隊可提交的共享專案設定。手動建立的本機檔案則需要自行排除。這些區分清楚界定了預期的界線，但亦使檔案的建立方式變得重要。

僅稱一個檔案為本機檔案，本身並不能保障私隱。 它的名稱向人表達意圖，但儲存庫控制機制才決定它會否隨專案流轉。兩者是相關的保護措施，失效條件卻不同。

全域排除屬於開發者的環境。專案層級的排除屬於儲存庫的工作流程。每當團隊期望某項安全慣例能跨越電腦、貢獻者或開發環境變動而延續時，這個分別便很重要。

以專案交接作為分析例子。原作者知道哪些檔案包含個人狀態，哪些檔案應進入原始碼控制。新貢獻者看到目錄結構，卻未必同時承繼這種理解。

當每名貢獻者都必須重新理解同一個分別時，問題便成為組織問題。依賴個人知識的規則，需要反覆關注。以共享專案政策呈現的規則，則較容易檢視及討論。

兩種做法都不能免除檢視提交內容的需要。排除是一項預防慣例，而已提交的變更才是真正的發布決定。團隊應同時評估兩者，而不是假設其中任何一項的存在便能保證另一項。

術語亦值得留意。設定通常令人聯想到顯示選項或編輯器行為等無害偏好。權限檔案可承載敏感得多的紀錄，因為其內容源自真實操作。

這種不一致為產品設計帶來壓力。如軟件會保留命令參數，就應在使用者將該檔案視為普通設定前，協助他們理解這種持久儲存。相關警告應置於建立紀錄的決定旁邊。

這裏存在合理的易用性限制。要求使用者檢視每個實作細節，會令助手更難使用，亦會鼓勵流於表面的批准。設計挑戰在於呈現重要後果，同時不讓操作本身不堪負荷。

對企業買家而言，這會成為一個具體的評估問題。管理員能否說明哪些代理檔案可安全分享、哪些應保留為個人檔案，以及哪些可能含有敏感資料？產品給出的答案，應與員工實際使用的儲存庫控制機制一致。

文件所說明的 Claude Code 權限，提供了預期的模型。實際考驗是該模型能否在日常協作中維持易於理解。文件建立預期；可觀察的行為則決定團隊能否可靠地遵循它。

這項捷徑以持久資料換取減少重複提示

持續有效的批准所帶來的便利不難理解。開發者希望助手能繼續處理日常工作，而非每一步都中斷。若系統反覆要求作出同一決定，使用者便會尋求更廣泛或更長期的授權。

核心取捨是在較少中斷與為實現此事而保留的資料之間。 即使介面將兩者一併呈現，執行權限與憑證儲存仍應分開決定。

評估這項設計的一個有用方法，是把能力與資料分開。能力描述代理可做甚麼，例如執行已批准的開發操作。資料則包括執行期間提供的具體參數及驗證資料。

保留能力未必需要保留每一項資料。然而，移除參數可能改變規則的含義。較寬泛的批准或會授權使用者從未打算容許的操作，造成另一種安全問題。

因此，僅從已儲存命令中刪除可疑文字，並不是完整的設計規格。產品必須保留使用者原本希望設定的範圍，同時避免不必要的保留。當某項操作其後再次要求權限時，所產生的行為亦必須保持易於理解。

憑證參照提供了另一個設計方向。命令可以參照另外提供的數值，而非直接嵌入該數值。這減少了批准紀錄必須包含憑證本身的需要。

參照仍須謹慎處理。程式可能輸出已解析的數值，錯誤訊息可能揭露它，或其他成品可能保留輸出結果。避免在一項紀錄中出現字面密碼，可減少暴露，但並不代表建立了完整保護。

這正是這個故事與特定按鈕以外的範圍相關之處。代理軟件會產生紀錄，以支援延續性、除錯及協作。每項紀錄都應有明確用途、受眾及與其內容相稱的保留政策。

助手表面上的記憶能力可能掩蓋了這些問題。使用者感受到的是一段持續推進工作的對話，而實作上可能建立了具不同分享規則的檔案。產品團隊需要讓具影響力的界線清晰可見。

Cursor 的背景代理安全文件提供了一個有用比較。它描述了隔離虛擬機器、互聯網存取及自動終端機執行。它亦警告，惡意指令可透過提示注入導致資料被竊取，即不可信內容重新引導代理的行為。

這個比較並不能證明 Cursor 具有 Claude Code 所報稱的批准儲存行為。它顯示競爭設計如何在執行、隔離及使用者審閱之間，以不同方式分配責任。買家應分開比較這些機制，而非只按批准模式選擇產品。

隔離限制操作執行的環境。批准決定操作是否繼續。憑證處理決定哪些敏感資料進入環境，以及其後保留哪些紀錄。

當這些控制措施的界線明確時，便能互相強化。若將某一層的成功決定視為所有其他層皆安全的證據，它們便會變得令人困惑。已獲授權的操作仍可能留下不恰當的紀錄。

因此，Claude Code 安全風險應在工作流程層面評估。有用的問題是：已批准的工作會建立甚麼資料、該資料在哪裏持久存在，以及誰日後可以取得它。

Anthropic 承認存在缺口，但自動模式並非修復證明

Boris Cherny 來自 Claude Code 團隊，他在權限安全討論中回應了這份報告。他表示 Claude Code 過往缺乏敏感資料清理功能，並建議使用自動模式及掃描儲存庫內的機密資料。他亦描述了原型開發可採取的潛在防護措施，包括基本的敏感資料偵測。

有讀者質疑，自動模式是否仍可進入有問題的批准流程。Cherny 承認這項觀察。他的評論表明團隊正作出回應，但並不代表全面修正方案已經推出。

建議採用的防護措施，需要根據其旨在預防的失效情況加以驗證。 減少手動批准與防止憑證被持續儲存，是相關但驗收標準不同的目標。針對其中一項的證據，不應取代另一項的證據。

持懷疑態度的觀點很直接：若敏感操作仍會建立包含憑證的批准紀錄，改變預設執行模式便無法令該途徑失去關聯性。回應必須處理由此產生的產物，以及提示出現的頻率。

Anthropic 強調減少權限中斷，背後亦有合理理據。反覆提示可能消耗注意力，卻未必帶來審慎覆核。改善這種體驗是值得的，前提是改善不會變成籠統的安全聲稱。

分歧部分在於應由何處執行管控。有些用戶希望採用不受代理程式判斷影響的固定限制；另一些人則傾向自動評估，以區分日常活動與敏感操作。

這些做法回答的是與已儲存紀錄是否包含密碼不同的問題。嚴格的執行邊界可以與過度資料保留並存。自動審核工具可減少中斷，但仍需要明確規則界定哪些內容會寫入磁碟。

企業評估應把這些問題分開處理。買方可以重視自動執行任務，同時仍要求可預測的儲存行為。產品應透過可觀察的結果證明兩者，而不是要求客戶從其中一項推斷另一項。

可信的驗證演練，會在受控專案中使用人工憑證，並在操作後檢查批准紀錄及其他產生的產物。它亦會檢視敏感本機檔案已被追蹤時的行為。

這些是建議的評估條件，並非 Anthropic 已完成測試的聲稱。它們說明了區分有前景的回應與已獲證實改善所需的證據。公開結果可讓客戶判斷任何改動的涵蓋範圍。

Claude Code 機密資料外洩亦帶來溝通上的挑戰。建議用戶啟用另一項控制措施固然有用，但仍未說明產品本身將承擔哪些責任。清晰的發布說明應同時交代新增保護與餘下條件。

最公平的結論應有限且可行：Anthropic 已知悉相關疑慮，用戶亦提出了相關邊緣情況，而建議改動的成效仍須觀察。現有證據既不支持漠視問題，也不支持宣稱已完全補救。

安全團隊面對的是另一類儲存庫審查

對安全團隊而言，眼前壓力在於可視性。應用程式審查通常集中於會在生產環境運行的程式碼。由代理程式產生的設定，可能在應用程式行為改變前已造成風險。

審查需要追蹤敏感資訊在整個開發流程中的流向。 設定檔是否值得仔細審查，取決於其內容與目的地。它具行政用途，並不代表其中資訊無害。

GitHub 的推送保護會在發布前封鎖受支援的敏感資料偵測結果。其文件區分供應商特定、通用、自訂及 AI 偵測模式，且各自的設定要求不同。因此，團隊需要驗證已啟用的涵蓋範圍，而非假設每項憑證都會被偵測。

有掃描器與掃描器已證實的涵蓋範圍，是不同形式的證據。可辨識的服務權杖，與嵌入指令中的一般密碼，帶來不同的偵測挑戰。以人工範例測試，可揭示已設定系統是否能辨識團隊實際使用的模式。

這改變了開發人員與安全人員之間的對話。開發人員需要能持續運作的工作流程；安全團隊則需要證據，證明敏感數值不會悄然進入原本供分享的資料。

共同目標應是可重複執行的邊界。個人代理程式狀態應有明確目的地，共享設定應有清晰審查標準，而偵測到的憑證應送達能夠撤銷它們的人員手中。

事件回應亦必須把遏止與清理分開處理。GitHub 的敏感資料移除指引優先處理撤銷或輪換已曝光的憑證。指引說明，移除歷史資料需要協調，而複本仍可能存在於複製儲存庫、分叉及其他參照中。

這個次序反映憑證與載有憑證的文件之間的差異。編輯文件會改變讀者在該位置看到的內容；撤銷則會改變憑證是否仍可授權存取。

對承受壓力的團隊而言，可見的清理行動可能令人感覺工作已完成，因為有問題的檔案從最新檢視中消失了。真正相關的安全結果是，已曝光的數值是否仍保有權限。歷史資料清理與存取審查處理的是額外後果。

當發現紀錄的人無法辨識其擁有人時，責任歸屬會變得更困難。開發人員可能認得專案名稱，卻不知道哪個系統簽發了權杖。清晰的擁有權可縮短由偵測至有效遏止的路徑。

團隊亦需要在不保留機密的前提下保存教訓。事件記錄可描述受影響的工作流程、負責的服務及預防性改動，但應避免為了令說明具體而複製敏感數值。

這項區分同樣適用於可搜尋的知識庫。有用的工程知識包括已核准的程序及過往失敗的說明。憑證應存放在為管理存取而設計的系統中，而非一般參考資料。

當回應措施有具名負責人時，Claude Code 的安全風險便較易管治。開發人員可說明任務，平台團隊可執行儲存庫慣例，服務擁有人可更換存取憑證。安全人員不應在調查期間才重建所有這些關係。

實際的組織改變，是擴大審查邊界。團隊除了檢查助手所編輯的內容，亦需要檢查它留下的內容。這使持續存在的代理程式狀態成為正常工程管治的一部分。

甚麼證據可證明曝光途徑正在關閉？

下一批有用證據應體現在產品行為、儲存庫控制措施及補救結果。這些訊號分別處理所報告流程的不同部分，合起來可顯示原有曝光途徑是否變得更難重現。

進展應以防止持續儲存及降低憑證權限來衡量。 單靠公告措辭無法證明任一結果。最有力的證據，會把特定防護措施與可觀察的改變連結起來。

首先，留意是否有 Claude Code 的文件化發布版本，改變敏感批准的儲存方式。關鍵細節是，當原本合法的指令包含驗證資料時會發生甚麼事。發布說明應交代產生的紀錄，以及仍需要用戶介入的情況。

若有證據顯示人工機密資料不再出現在已儲存的批准紀錄中，將加強產品確有實質改善的論據。若證據顯示相同數值仍會在另一條權限途徑中保留，則會收窄這項結論。兩種結果都比關於更安全自動化的一般說法更有資訊價值。

測試範圍與標題行為同樣重要。全新專案與已有被追蹤設定檔的儲存庫，代表不同的起始條件。清晰說明應識別保護措施涵蓋哪些條件。

其次，留意能證明代理程式設定及嵌入指令憑證獲得涵蓋的儲存庫控制措施，包括清晰的排除政策及經測試的敏感資料偵測。真正有意義的結果，是嘗試發布是否被阻止，或是否被導入有效審查。

單靠政策文件，執行結果仍不確定。受控演練若顯示人工憑證會觸發預期回應，便能提供更有力證據。若屢次漏檢，則會削弱對掃描作為補償性控制措施的信心。

這項訊號對競爭對手也很重要。供應商可用不同方式描述執行環境，但仍須說明其保留的產物。對產生檔案、分享邊界及憑證處理作出清晰文件說明，會令買方更易作出比較。

第三，留意補救報告是否清楚區分已移除的檔案與已失效的憑證。儲存庫外觀很容易觀察，但持續存取則需要負責服務提供的資訊。可信的後續報告應把這些結果分開處理。

Apiiro 的結果尚未在此獨立重現，其蒐集資料亦不應視為所有 Claude Code 專案的隨機樣本。所報告的群體由公開可發現的檔案構成，這限制了對更廣泛用戶群中曝光普遍程度的結論。

這些限制並未削弱核心工程疑慮：保存操作脈絡的功能，需要對敏感資料訂立清晰政策。用戶應能理解該政策，而無須在限期壓力下重建其實作方式。

對評估 Claude Code 機密資料外洩的團隊而言，應先檢視工作流程實際建立的批准紀錄。使用人工憑證檢查哪些內容會持續保留，然後驗證哪些控制措施可防止該等資料進入共享儲存庫。在真正曝光迫使問題浮現前先分配擁有權。把發現保存為同事可遵循的程序，而毋須重現敏感數值。當真正憑證出現在共享資料中，首要問題應是該憑證是否仍具權限，並由負責服務的擁有人處理。要求供應商提供同時涵蓋儲存與執行的證據。下一次最有用的審查，應回答一條具體問題：在已批准的任務完成後，甚麼敏感資訊仍然存在，以及誰能取得它？