GitHub 於 2026 年 9 月 24 日公布 Proof of Presence 公開預覽，讓企業在成員進行高影響操作前，要求互動式重新驗證或多因素驗證。功能是 GitHub 企業版 sudo mode 的延伸，目的在確認「此刻有一名獲授權的人正在操作」，而不只是瀏覽器持有有效 session 或長期 token。
第一階段只適用於 github.com 和 GHEC-DR 的 managed user enterprise，並要求以 Microsoft Entra ID 作為 SAML 或 OIDC 的 SSO 身份提供者。這是一個相當具體的部署範圍，不是所有 GitHub 帳戶或所有身份系統都即時可用；企業要先核對自己的登入架構是否符合條件。
可以觸發驗證的操作包括建立 token、編輯 webhook、修改組織安全設定和查看 recovery codes。啟用後，GitHub 會把成員導回企業的 IdP，要求它完成組織指定的政策，例如再次登入、MFA 或裝置合規檢查；只有帶著驗證結果返回，該操作才會繼續。
驗證成功後，同一瀏覽器 session 可以在兩小時內繼續進行高影響操作。GitHub 表示，這種 fresh authentication 可以降低被竊 session cookie 或長期憑證被濫用的機會，也可協助受規管環境滿足敏感操作前重新驗證的要求。Pull request merge 的 Proof of Presence 支援則仍在稍後推出。
對 AI coding agent 而言，這項更新特別值得留意。GitHub 直接提到它可以阻止被劫持的 credentials 或代理在使用者不知情下多走一步，但它不是把所有代理操作都變成人工批准。代理仍然可能在工作區內讀取、修改和測試程式碼，企業需要另外設計最小權限、sandbox、branch protection 和 code review。
一個實用部署方式，是先把 token 建立、webhook 編輯和組織安全設定視為「必須新鮮身份」的邊界，並觀察自動化流程是否因驗證中斷。對非互動式 CI/CD，企業要分清楚哪些工作應使用短期、範圍受限的憑證，哪些必須由人員在管理介面完成，而不是為了方便而關閉驗證。
Proof of Presence 解決的是身份新鮮度和關鍵操作的最後一道門，不等於完整的 AI agent security。企業仍要記錄代理的指令、工具呼叫和變更結果，限制 secret 可見範圍，並在生產環境保留可追溯的批准記錄。代理越能代表使用者行動，身份、政策和審計就越要一起設計。
