GitHub announced a public preview of Proof of Presence on September 24, 2026. Enterprises can require interactive re-authentication or a multi-factor challenge before members perform high-impact actions. The feature extends GitHub Enterprise’s sudo mode and is designed to confirm that an authorized person is acting at that moment, rather than relying only on a valid browser session or long-lived token.
The first scope is specific: managed-user enterprises on github.com and GHEC-DR that use Microsoft Entra ID as their SAML or OIDC SSO identity provider. It is not an immediate control for every GitHub account or identity system, so organizations need to check their authentication architecture before planning a rollout.
Actions that can trigger the challenge include creating a token, editing webhooks, changing organization security settings, and viewing recovery codes. GitHub redirects the member to the enterprise IdP, where the configured policy may require another sign-in, MFA, or a device-compliance check. The action proceeds only when the member returns with proof that the policy was satisfied.
After a successful challenge, the same browser session can continue high-impact actions for two hours. GitHub says fresh authentication can reduce abuse of stolen session cookies and long-lived credentials and can help regulated organizations meet requirements for re-authentication before sensitive operations. Support for proof of presence before pull-request merges is coming later.
The change is especially relevant to AI coding agents. GitHub says it can help block compromised credentials or an agent from going one step further without the user’s knowledge, but it does not turn every agent action into a human approval. Agents may still read, modify, and test code inside their workspace, so organizations need separate controls such as least privilege, sandboxing, branch protection, and review.
A practical rollout is to treat token creation, webhook editing, and organization security settings as fresh-identity boundaries and observe which automations are interrupted. For non-interactive CI/CD, teams should decide which jobs use short-lived, narrowly scoped credentials and which actions must be completed by a person in an administrative interface, rather than disabling the check for convenience.
Proof of Presence closes a gap around identity freshness and critical actions; it is not a complete AI-agent security model. Organizations still need to log agent instructions, tool calls, and resulting changes, limit secret visibility, and retain traceable approvals in production. The more an agent can act for a user, the more identity, policy, and audit design need to be treated as one system.
