GitHub 官方工程文指出，目前平台上約三分一的拉取請求（pull request）已有 AI 代理參與；一年前少於十分一。密鑰外洩並非單純「開發者更粗心」——公開可見程式碼大約每兩秒出現一組新密鑰，過去三年按年倍增；推送防護必須用運算擴張，而不能只靠人工撤銷。來源真實性已驗證自 GitHub Blog，並以文內公開季度數據交叉核對。

本文整理其九個完整季度的推送與密鑰統計、ModernBERT 分類器如何在兩毫秒內把非結構化密鑰納入推送防護，以及對香港團隊在代理編程時代的資安含義。

GitHub／官方：三分一 PR 已有 AI 代理——ModernBERT 兩毫秒擴推送防護至非結構化密鑰；私有預覽本月擴企業

一、核心事件：代理加速寫碼，密鑰防護必須同步擴張

技術細節

GitHub 產品負責人 Erin Havens 於二零二六年十月七日撰文，聚焦「Secret Protection（密鑰防護）」如何跟上代理時代的軟件產量。文章開宗明義：開發者並非變得更粗心，而是被產量甩開；讓人寫出更多軟件的工具，也應承擔更多防護工作。

關鍵公開數據包括：

代理滲透率：今天 GitHub 上約三分一拉取請求涉及 AI 代理；一年前少於十分一。若趨勢延續，未來兩年推上 GitHub 的程式碼可能大多由代理撰寫，且未必再經人類完整閱讀。
外洩節奏：公開可見程式碼大約每兩秒出現一組新密鑰，過去三年按年倍增。
推送與憑證同步上升、單次推送盛行率未見惡化：二零二四年第二季至二零二六年第二季，受掃描推送增長約二點八四倍，帶有憑證的推送增長約二點五九倍；九個完整季度內，未能檢出「每次推送出現密鑰的比例」有統計上可辨的上升趨勢。
開發者更不願覆寫攔截：同期，開發者覆寫推送路徑攔截的比例由約百分之六點六三線性降至約百分之三點九三。
人工補救跟不上：手動撤銷密鑰的平均時間約四十日；約五分一個案超過九十日。產量倍增時，若每宗外洩仍依賴同等人力，工作量亦倍增。

現有防護分層：

合作夥伴目錄：逾一百五十家技術夥伴參與密鑰掃描合作；二零二六年第二季，公開掃描平均每秒成功回報約二十六次憑證吻合（含重複觀察）。許多發行方（例如 OpenAI API 金鑰、Google Cloud、Slack webhook、Hugging Face 使用者權杖、SendGrid 等）收到通知後可立即撤銷。
推送防護（push protection）：在密鑰進入倉庫歷史之前攔截可識別憑證。過去一個月，推送防護至少每秒攔截一次密鑰；就與發行方綁定的憑證而言，GitHub 稱攔截數量已多於漏網。
缺口：若計入更多密鑰類型，推送防護大約只能在進入歷史前擋住約三成新偵測密鑰，其餘約七成仍是「已經外洩之後」才發現——預防靠運算可擴，補救仍靠人力。

二、技術原理：四體問題與 ModernBERT 推送路徑分類

推送邊界之前，攔截成本低、決策是二元的（擋或放行）；一旦寫入可見歷史，同一字串可能對真實系統完成認證，成本上不設限。許多內部資料庫密碼等「非結構化密鑰」沒有可辨前綴，只能靠周圍程式碼與世界脈絡判斷。

GitHub 稱之為密鑰防護的「四體問題」：精準度、延遲、吞吐、成本互相耦合。適合事後審查的發現，未必值得擋住一次推送；誤報會打斷開發者並削弱下一次攔截的信任；檢查太慢或太貴，就無法放進關鍵路徑。

為此，GitHub 與 Microsoft Applied Sciences 微調 ModernBERT 分類器：在上下文中評估候選密鑰，不生成程式碼或散文。官方稱其較既有大型語言模型管線更精準，且評估一批候選可在少於兩毫秒完成，成本低至可在推送關鍵路徑大規模運行。把該模型納入推送防護後，官方指有望令可預防的密鑰數量增加逾一倍。

產品節奏（以官方為準）：

該能力現處私有預覽；本月稍後將向已購買 GitHub Secret Protection 的 Enterprise Cloud 與 GitHub Teams 組織開放，並消耗 AI credits。
已啟用 AI 密鑰偵測的組織，事後掃描會自動升級至新模型；此類警報仍含在既有密鑰掃描購買內、不另收費。
模型亦將隨 GitHub Enterprise Server 3.23 進入公開預覽，讓氣隙環境的 Secret Protection 客戶可用 AI 偵測警報。
分類器會加入 Copilot CLI 與 Copilot App 的 /security-review 指令，讓使用者在推送前處理密鑰，即使組織尚未購買 Secret Protection；AI credit 用量會歸入 Secret Protection 的用量洞察。

三、日常應用場景

1. 開發者與技術團隊

代理在緊迴圈中幾乎每個動作都可能提交或檢查點；推送延遲與密鑰攔截變成代理速度的邊界條件。團隊應把推送防護、合作夥伴自動撤銷與 /security-review 納入代理工作流預設，而不是指望事後人工翻警報。

2. 企業與隱私敏感行業

金融、醫療、法律等行業的內部連線字串、資料庫密碼往往沒有發行方前綴。非結構化密鑰的推送路徑分類，直接對應「代理寫進 Dockerfile／Kubernetes Secret／連線 URL」的風險面。氣隙或受規管環境可關注 GHES 3.23 預覽路徑。

3. 一般用戶與開源維護者

公開倉庫每兩秒級的新密鑰節奏，意味個人專案與小型開源庫同樣受波及。覆寫攔截比例下降，顯示開發者更意識到風險；平台側應用運算擴大預防，而非只靠「請小心一點」。

4. 香港與亞洲市場視角

香港金融科技、支付與外包研發團隊廣泛使用 GitHub 與編碼代理。若本地流程允許代理直接推送，應同步開啟 Secret Protection／推送防護，並把發行方自動撤銷納入事件應變。對於須數據留港的私有模型部署，仍應避免把生產密鑰寫進可由代理提交的工作樹。需要加固雲端與網絡邊界時，可參考 YSK Limited 的雲端遷移與網絡安全服務（https://ysk.hk/services/cloud-security）；單機 Linux 控制平面可搭配 YSK Server v1.1.27（https://ysk.hk/products/ysk-server）。

四、專業評價與潛在考量

優勢

用季度級推送數據反駁「AI 令開發者更粗心」的簡化敘事，改為「產量上升、單次盛行率未惡化、覆寫下降」。
把非結構化密鑰推進推送關鍵路徑，並以亞毫秒至兩毫秒級延遲回應代理迴圈的現實約束。
發行方合作＋即時撤銷，令部分外洩在開發者處理警報前已失效。

需要留意的地方

推送防護對「全部密鑰類型」仍約三成事前攔截、七成事後發現；人力補救平均約四十日的結構性問題未消失。
ModernBERT 推送防護擴展目前為私有預覽，並消耗 AI credits；完整企業覆蓋時間表以官方為準。
精準度與誤報信任仍是四體問題核心；企業應以自己的倉庫樣本驗證攔截品質，再決定預設擋或僅警報。

結語

代理編程把「每秒攔截」與「兩毫秒分類」從錦上添花變成基礎設施。GitHub 的論點清楚：創造軟件的能力在擴張時，防護容量必須用運算一起擴張，而不是要求人類按同樣斜率加班撤銷密鑰。香港團隊若已讓代理寫入共用倉庫，應優先核對推送防護、Secret Protection 與發行方自動撤銷是否就緒；雲端與主機邊界加固可連繫 https://ysk.hk/services/cloud-security ，本地閘道場景亦可參考 YSK Omni v1.0.2（https://ysk.hk/products/ysk-omni）。

參考來源

GitHub Blog（官方）：Secret protection must scale with software — https://github.blog/ai-and-ml/github-copilot/secret-protection-must-scale-with-software/
發現來源：GitHub Blog RSS — https://github.blog/feed/