摘要：GitHub 在 2026 年 9 月 24 日为 GitHub Enterprise Cloud 上线 proof of presence 公开预览。开启后，企业成员在创建令牌、编辑 Webhook、修改组织安全设置、查看恢复码等高风险操作前，必须回到身份源重新完成一次认证。该能力目前只覆盖使用 Microsoft Entra ID 做 SSO 的托管用户（EMU）企业，位于 github.com 与 GHEC-DR；通过校验后，同一浏览器会话两个小时内不再重复挑战。
很长一段时间里，企业安全团队对 GitHub 会话的攻击面只能做一件事：把强制 MFA 打开，然后祈祷没人偷走会话 cookie。攻击者拿到的不是一个密码，而是一个已经通过 MFA 的浏览器会话——之后他在 GitHub 上的每一次点击，系统都认为是本人。
9 月 24 日，GitHub 为 GitHub Enterprise Cloud 加了一层新的判断：不再只检查「这个会话是否有效」，而是检查「此刻操作的人，是否刚刚在身份源那边证明过自己」。这项能力叫 proof of presence，官方把它描述为 sudo 模式的一次扩展。本文要说清楚的是：它究竟卡住了哪一步动作、企业里谁的工作流会变慢、以及它现在还不能做什么。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么：一条企业设置，把 sudo 校验从密码换成身份源
这仍然是一次公开预览。可用范围相当窄：只有托管用户（EMU）企业、且 SSO 身份源使用 Microsoft Entra ID（通过 SAML 或 OIDC）的企业，才能在 github.com 与 GHEC-DR 上开启。其余企业现在看不到这个开关。
管理员在设置里做的是一个二选一：Re-authentication，要求成员回到身份源重新认证一次，按官方说法「密码可能就够」；MFA，要求成员重新认证之外，再通过一个额外因子，例如验证器应用或生物识别。真正决定强度的其实是身份源那边的策略——GitHub 把策略判断交给 Entra ID，企业可以在 IdP 里自定义哪些操作需要什么级别的验证。
触发后的行为是同步阻塞式的：成员被重定向到身份源，只有在带着「已满足所需策略」的结果回来时，GitHub 才放行这次操作。官方给出的高风险动作示例包括创建令牌、编辑 Webhook、修改组织安全设置、查看恢复码。通过一次校验后，同一个浏览器会话在两个小时内可以继续做其他高风险操作，不必反复挑战——这一设计和既有的 sudo 模式保持一致。
一个具体场景：周一早上的安全设置变更
设想一个已经开启 Re-authentication 档的企业。周一早上，平台组的一名工程师要在组织设置里收紧一条安全策略。他此前已经在浏览器里登录过 GitHub，会话是热的。点下保存的那一刻，页面不会保存，而是把他重定向到公司的 Entra ID 登录页；他完成一次认证，被弹回 GitHub，这条设置才真正写入。
同一时刻，如果他正在用命令行创建个人访问令牌，也会遇到同样的关卡。有意思的是「查看恢复码」也在清单里——这是一个过去几乎无人设防的动作，但恢复码一旦泄露，攻击者可以绕过 MFA 直接接管账户。把读取动作纳入校验，说明 GitHub 的判断标准是「能重置或绕过认证的动作」，而不是「能改代码的动作」。
为什么这会改变企业里的工作流
对 SRE 和平台工程师来说，最直接的变化是「自动化路径被切开」。过去，一个运维在浏览器里登录一次，一整天可以连续做几十次设置变更；开启之后，敏感操作会周期性要求他中断手上的事，跳到 IdP 走一遍认证。两小时的会话窗口是一个折中：既不至于每次都问，也保证了一个被窃取的长期会话不能在无人察觉的情况下反复使用。
对安全团队来说，这次更新把责任部分转移到了 IdP。谁能通过 Re-authentication、谁能通过 MFA，取决于企业自己在 Entra ID 里配置的条件访问策略，而不是 GitHub 侧的固定规则。这意味着同一套 proof of presence 设置，在两家公司里可能产出完全不同的安全强度和用户体验。
对审计与合规场景，官方给出的动机里有一条很具体：这一能力帮助企业满足「敏感操作前需要重新认证」类的要求，文中点名了 FDA Part 11 这类框架。合规检查通常要求「证明是你本人、并且是刚刚证明的」，会话有效性截图在过去很难满足这类要求，重新走一遍 IdP 留下的记录可以。
限制、边界与人应该在哪儿接手
首先，这不是一个「打开就全局生效」的开关。它的前置条件很硬：EMU 企业、Entra ID 作为 SSO 身份源、github.com 或 GHEC-DR。个人账户、团队版、以及用别的 IdP 的企业，现在都还不在范围内。
其次，官方明确说「在合并 Pull Request 前支持 proof of presence」这件事是 coming soon，也就是尚未生效。今天被卡住的是令牌、Webhook、组织安全设置、恢复码这类账户与配置层面的动作，而不是代码合并这个最频繁的动作。反过来说，等这条补上之后，PR 合并的体验会再次变化——这也是需要提前和开发团队打招呼的地方。
第三，Re-authentication 档位的实际强度取决于 IdP：「密码可能就够」意味着如果企业只配了密码，那这层校验挡不住已经拿到密码的攻击者。要真正对齐「防会话窃取」的初衷，应该选 MFA 档或把 IdP 策略收紧。
最后是人接管的边界。这项能力会制造新的失败模式：成员在紧张时刻被弹去 IdP、认证失败、或者 IdP 不可用，操作就被堵住。企业需要为「紧急变更但认证走不通」预留一条明确的、有记录的人工通道，而不是让工程师去找绕过开关的办法。
如何试用
如果所在企业符合条件，管理员可以在企业设置的安全相关页面里找到 proof of presence 区块，先在单个企业上选 Re-authentication 或 MFA 开启，观察一周内的挑战频率与失败率，再决定是否扩大到全部高风险动作。GitHub 同时给出了配置文档和开发者社区讨论帖，用于反馈具体哪些动作应该被纳入清单。
信息来源
- GitHub Changelog：Require proof of presence for high-impact actions（2026-09-24）— https://github.blog/changelog/2026-09-24-require-proof-of-presence-for-high-impact-actions
- GitHub Docs：Configuring proof of presence（企业安全加固文档）
- GitHub Community Discussion #64212（proof of presence 讨论帖）
HiFox ：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 Hifox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。