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 可见范围，并在生产环境保留可追溯的批准记录。代理越能代表用户行动，身份、政策和审计就越要一起设计。
