如果團隊開始讓 coding agent 改檔、跑測試、送出 PR，最先跟不上速度的，可能是憑證外洩後的人工補救。

GitHub 觀察 2024 年第二季到 2026 年第二季的公開推送：受篩查的 push 數量變成 2.84 倍，檢出憑證的 push 變成 2.59 倍。九個完整季度裡，每次 push 檢出憑證的比例沒有統計上可辨識的趨勢。這組數字無法證明 agent 讓人更粗心，也不能拿來宣稱風險降低。它說明的麻煩很直接：即使單次推送的檢出比例沒有明顯變化，總量增加，待處理的事件仍會跟著增加。

把檢查放在憑證進入遠端歷史之前

例如，agent 幫忙補整合測試，順手修改環境設定範例，把原本應該是佔位字串的位置填成真的憑證。開 PR 時才掃出來，敏感值可能已經進入遠端 repository 的提交歷史。刪掉檔案裡那一行，憑證也不會自動失效；團隊還得依發行方流程撤銷、重發，並檢查使用紀錄。

我會把檢查放在三個位置：本機 commit 前先掃一次，push 時由遠端保護機制擋下可辨識的憑證，PR 或後續掃描再接住漏網案例。push 的位置特別關鍵，因為變更還沒進遠端歷史，可以直接退回修改者處理。

這道防線仍有邊界。GitHub 把更多憑證類型納入統計後，push protection 約在進入 repository 歷史前擋下 30% 的新檢出憑證；其餘約 70% 是事後才找到。這是 GitHub 自身偵測範圍內的數字，不能當成任何團隊部署後的保證攔截率。

擋得住，也要讓工程師願意留下這道防線

只把規則調到「寧可全擋」不見得有效。誤判太多，大家就會習慣覆寫；每次 push 都要等很久，檢查可能被繞過。偵測準確度、延遲、吞吐量和成本得一起看，尤其當 agent 一天可能產生多次推送時。

GitHub 在 10 月 7 日介紹的非結構化憑證分類器，當時仍是 private preview。文中提到的低於 2 毫秒，是評估一批候選值的模型時間，不能當成整次 push 的耗時，也不能假設所有帳戶都已能使用這項阻擋能力。團隊挑工具時，應查自己的方案、支援的憑證類型與覆寫紀錄，再決定哪些結果適合直接阻擋。

Stack Overflow 2026 年開發者調查中，48% 的受訪者表示，答案容易驗證時才會信任 AI。掃描器也不能只丟一句「有問題」：它得指出檔案位置、判斷依據與處理方式；有人覆寫時，也要留下理由。否則開發者無從判斷這是誤判，還是自己真的把憑證帶進了變更。

用一個不含真憑證的 repo 驗收

我會先拿測試 repository 做一次演練，使用掃描工具文件允許的無效樣本，絕不拿真 token 試。驗收紀錄不用寫成一份厚重的資安報告，能回答下面幾件事就夠：

演練結束後，我想看見的不只是掃描器有沒有亮紅燈，還有漏檢發生時誰接手、誰撤銷憑證、多久完成。agent 可以產生更多變更，一個綠色檢查標記卻證明不了歷史裡沒有敏感值。

把可自動化的阻擋放在 push 前，人才能把注意力留給誤判、未知格式和已經暴露的憑證。這比在每個 PR 下面提醒一句「請小心不要提交金鑰」更能跟上交付速度。

來源備註

• GitHub：Secret protection must scale with software：公開推送、憑證檢出與 push protection 的統計範圍。
• Stack Overflow Developer Survey 2026：AI：受訪者對 AI 可驗證性的回答。
• GitHub：The next developer interface is ambient intelligence：coding agent 進入 PR 工作流的產品背景。