> ## Content Index
> Fetch the complete content index at: https://enteruaf.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# GitHub adds a human checkpoint before high-impact account actions
- URL: https://enteruaf.com/github-proof-presence/
- Published: 2026-09-26T09:24:08.000Z
- Updated: 2026-09-26T09:24:08.000Z
- Description: GitHub’s enterprise preview requires a fresh identity-provider challenge before selected high-impact actions. It adds a useful checkpoint against stolen sessions, with narrow eligibility and no proof that a person reviewed an agent’s reasoning.
- Author: UAF Editorial
- Tags: Security, Autonomy

**GitHub’s enterprise preview requires a fresh identity-provider challenge before selected high-impact actions. It adds a useful checkpoint against stolen sessions, with narrow eligibility and no proof that a person reviewed an agent’s reasoning.**

A stolen session can look perfectly legitimate to the software receiving it. GitHub’s new enterprise preview tries to insert a fresh identity check at the moment an account is about to do something consequential.

The feature, called proof of presence, was announced on 24 September. In a narrowly scoped public preview, an enterprise can require reauthentication or a multi-factor challenge before selected actions on GitHub Enterprise Cloud accounts. The examples include creating a token, editing webhooks, changing organization security settings and viewing recovery codes. The feature sends the user to the organization’s identity provider, where its configured policy decides what proof is required. A successful challenge permits further high-impact actions in that browser session for two hours, according to [GitHub’s announcement](https://github.blog/changelog/2026-09-24-require-proof-of-presence-for-high-impact-actions/?ref=enteruaf.com).

The preview is limited to enterprises using managed users and Microsoft Entra ID for single sign-on through SAML or OIDC. GitHub says protection for pull request merges is still coming.

## A valid session is not a fresh decision

Many online services treat possession of a valid session or token as enough authority to proceed. That is convenient until a cookie is stolen, a credential is hijacked or an automated agent can use an already authenticated session. Proof of presence adds a new question: has the account holder recently satisfied the organization’s identity policy before this sensitive operation?

This is a useful security boundary. Tokens and cookies can survive long after the person who created them last made a conscious choice. Reauthentication or MFA raises the cost of using those credentials for some important actions. The check is especially relevant as more software agents operate through tools and accounts designed for people.

But “proof of presence” is a carefully bounded phrase. A fresh login challenge can show that someone satisfied an identity provider’s rule. It does not show that the person understood the specific change, read an agent’s reasoning, or intended the resulting configuration. Depending on policy, reauthentication may involve only signing in again; stronger MFA can require an additional factor. The control’s value depends on which actions are protected, how often a challenge is required and what the organization asks from its users.

## Useful boundary, limited reach

The preview’s eligibility narrows who can use it today. It does not cover every GitHub account or identity provider, and the two-hour session period means the fresh check is not repeated for every sensitive action. GitHub’s own announcement describes it as an added protection against compromised or hijacked credentials and agents taking an extra step without the user’s knowledge; independent effectiveness data was not part of the release note.

That leaves a broader design lesson. An agent’s permissions should be constrained before it acts, and high-impact operations should have a reviewable boundary where identity, scope and intent can be checked. Reauthentication addresses one part of that problem: whether a recent person-controlled identity challenge occurred. It does not replace narrow permissions, audit logs, incident response or a clear record of what the agent asked to do.

The launch is modest by design: a fresh checkpoint on selected enterprise actions, not a general solution to agent security. The distinction is useful. A machine can inherit a session. Making it pause for a fresh human credential is one way to remind the system that access and intent are not the same thing.