AI 程式碼開發助理愈來愈普及，但便利的背後自然還是有我們提醒過很多次的資安風險。資安廠商 Apiiro 近日揭露 Coding Agents Are Leaking Your Secrets to GitHub，Claude Code 的「不要再問」授權選項，會把使用者核准的完整指令寫進專案設定檔。指令裡若含資料庫密碼或 API 金鑰，這個檔案一旦被提交到公開的 GitHub 儲存庫，等於把敏感資訊攤在陽光下。研究團隊統計，公開 GitHub 上有 104,185 份這類設定檔，其中 1,122 份藏有真實憑證，合計 1,379 個不同的 secret。
授權紀錄為什麼會變成公開檔案
當開發者請 Claude Code 檢查資料庫或呼叫 API，它提出的指令本身通常就帶著設定檔裡的金鑰或密碼。Claude Code 執行前會詢問，選項包含「Yes, and don’t ask again」。使用者按下後，工具會把這條完整指令字串寫入專案資料夾內的 .claude/settings.local.json，之後同類指令就不再詢問。
問題出在這個檔案的存放位置與 git 行為。它位在專案資料夾內，檔案本身沒有任何標記說明它是私人設定。Claude Code 建立檔案時，會把它加進開發者個人的全域 git ignore 清單，這只能涵蓋常見情境，無法涵蓋資料夾後來才變成 repo、在另一臺機器 clone、或檔案已經被提交過的狀況。它也不會寫進專案自己的 .gitignore，因此沒有任何保護會跟著專案走。
Apiiro 指出，這不是模型的行為，而是 Claude Code 工具本身的行為，用 Opus 5.5 與 Fable 5.1 都能重現。在 1,105 個含真實 secret 的 repo 中，有 539 個是 Claude 自己參與的 commit 改動了這個檔案。
外洩規模與實際案例
公開 GitHub 上有 104,185 份 .claude/settings.local.json，分布於 103,617 個 repo。其中 1,122 份、約 1.1% 含有真實憑證。這些檔案合計 1,379 個不同的 secret，包含 636 個供應商格式金鑰與 743 個公開主機的密碼或權杖。
進一步拆解，379 個是資料庫密碼，122 個是 Supabase service-role 金鑰，103 個是 Supabase 帳號權杖，另有 43 個 SSH 登入、42 個 GitHub、GitLab 與 npm 權杖、23 個 AWS 金鑰與 6 個私鑰。若把 git 歷史、團隊刻意提交的共享設定檔、以及存在 repo 裡的代理對話紀錄也算進來，總數達 2,539 個真實 secret，分布在 1,994 個 repo。
受害組織有 63 家，多為軟體公司。實際案例包括一家資料庫廠商自己的雲端 API 金鑰，具備 manage 權限且沒有到期宣告，一家 B2B 新創的生產環境 Azure Postgres 密碼，一家軟體代理商的 Square 生產權杖，一個醫療紀錄應用的雲端 Postgres 擁有者密碼，還有一個開源專案的 OpenAI 格式 API 金鑰與另一個專案的 npm 權杖。另有一個大學 repo 用 sshpass 永久核准了連到公開伺服器的 root SSH 指令。
這些檔案存在時間也很長。在含真實 secret 的中位數 repo 中，檔案首次提交是在統計日前 217 天，有 118 個 repo 超過一年。74 個 repo 的 211 個 fork 也帶著同樣的 secret。刪掉檔案同樣不能解決，較早版本仍留有 734 個 secret，分布在 509 個 repo。
掃描器抓不到的部分
Apiiro 用 gitleaks 與 TruffleHog 掃過全部 104,185 份檔案。在 1,122 份含真實 secret 的檔案中，gitleaks 標出 564 份，TruffleHog 標出 643 份，有 215 份兩者都沒抓到，大約每五份就有一份漏網。
缺口在於「指令裡的密碼」。掃描器習慣找金鑰格式，也就是供應商前綴或長隨機字串。但寫在 PGPASSWORD=、sshpass -p、mysql -p 後面的密碼，或 curl 請求裡的 bearer 標頭，只是一般指令行裡的普通字串，兩套工具大多放過。同樣的模式也出現在代理的對話紀錄、記憶檔與交接筆記裡。
檔案也不是只有 GitHub 會漏。31,053 個 Hugging Face Spaces 中有 126 個含這份檔案，其中一個的允許規則帶有資料庫服務金鑰與使用者密碼。GitLab.com 抽查 69 份公開副本，有 2 份含真實 secret。更常見的情況是檔案根本沒進 GitHub，只留在開發者機器上，而惡意程式本來就會大量收集開發機上的憑證。2025 年 9 月的 Shai-Hulud npm 蠕蟲就下載 TruffleHog 掃描受害者檔案，它標出了 1,122 份中的 643 份。
開發者與資安團隊該怎麼做
CyberQ 呼籲，開發者第一步是停止追蹤這個檔案。若它已被納入版本控制，執行 git rm --cached .claude/settings.local.json，並把路徑加進專案自己的 .gitignore。第二步是輪替檔案曾經持有的所有憑證，因為移除檔案不會清除 git 歷史、fork 與 clone。
即使檔案從未提交，也應該打開來，刪掉每一條含 secret 的規則。更根本的做法是停止把 secret 打進指令，改用 $VAR 參照 secret 管理系統提供的變數，讓規則只記錄 $DB_URL。核准時也應以樣式為主，例如 Bash(npm run:*)，而不是核准一整條帶參數的長指令。
CyberQ 建議，資安團隊則要把 .claude/、.cursor/、.gemini/、.specstory/ 與代理記憶檔視為等同 .env 的含密檔案，筆電與 repo 都要納入。預提交與 CI 的 secret 掃描要涵蓋歷史版本，並確認掃描器能抓到指令裡的密碼，不只是供應商格式的金鑰。組織的 .gitignore 範本也應預設加入這個路徑。修補順序是先輪替、再清理，並優先處理與公開主機成對出現的憑證。
CyberQ 觀點
這起事件的核心不是 AI 寫錯程式，而是工具把「使用者按過的按鈕」變成一份可被提交的檔案。便利性來自記住指令，風險也來自記住指令。只要指令裡有 secret，記憶就成了外洩管道。
對開發團隊而言，最有效的做法不是事後掃描，而是從一開始就不要讓 secret 出現在指令字串裡，並把代理產生的設定檔當成 .env 一樣對待。
