GitHub adds proof-of-presence checks for sensitive enterprise actions

What now requires stronger confirmation

The protected examples named in coverage of the changelog include actions that can materially change an organization’s software supply-chain exposure: creating personal access tokens, editing webhooks, changing organization security settings and viewing recovery codes.¹⁵

These are not routine account preferences. They can create new credentials, redirect event flows, weaken security posture or expose account recovery paths.

The same reports note that GitHub plans to extend proof-of-presence coverage to pull request merges, though that support has been announced as forthcoming rather than currently available.¹² For DevSecOps teams, that distinction matters: merge-time proof of presence should not yet be treated as an active compensating control in compliance narratives or branch-protection designs.

Administrators can choose between re-authentication and MFA-backed confirmation, with the real assurance level depending on the identity-provider policy behind the GitHub prompt.¹ A re-authentication policy that accepts only a password provides less protection than one requiring phishing-resistant MFA, compliant device posture or other conditional-access checks.

Why GitHub is tightening privileged workflows

The move reflects a broader recognition that developer accounts are part of the enterprise attack surface, not merely collaboration identities. A compromised developer session, stolen cookie or long-lived token can become a route to source code, CI/CD configuration, release infrastructure or third-party integrations.

That is why proof of presence is most relevant when a user attempts a consequential action. As Birdcage Tech’s analysis put it, ordinary access should not silently become authority for exceptional or difficult-to-reverse changes; GitHub’s implementation applies that principle to developer-platform operations such as token creation and webhook edits.³

For software supply-chain defense, this shifts some risk management from static permission assignment to just-in-time verification. A user may have permission to create a token, but GitHub can require stronger proof that the authorized person is present when the token is created.

That does not eliminate the need to restrict token scopes, rotate credentials or monitor audit logs. But it raises the cost of abusing a hijacked session.

Fit with Copilot and agent governance

The proof-of-presence change landed alongside several GitHub updates aimed at enterprise control over AI-assisted development workflows. On September 25, GitHub added an in-product validator for Copilot enterprise managed settings, designed to catch malformed JSON, unsupported configurations and invalid team mappings that could prevent policies from being enforced.⁶

GitHub’s Copilot weekly release roundup also highlighted local sandboxing for the Copilot app, OpenTelemetry configuration through enterprise-managed settings and assisted approvals for Copilot agent sessions. In that model, low-risk tool calls can be approved automatically while higher-risk actions prompt the user.⁷

Separately, GitHub said agentic autofix now uses Copilot Memory for customers that enable it, allowing automated remediation to reuse repository-specific secure-development patterns.⁸

Taken together, these updates point to a platform pattern: AI-assisted coding and automation are expanding, while enterprise controls are being added around policy enforcement, observability, sandboxing and interactive approval. Proof of presence is part of that pattern, but it should not be confused with full agent authorization.

DVNC Dev’s analysis draws that line clearly: a fresh identity challenge can prove that a person recently satisfied an identity-provider policy, but it does not prove that an AI agent is approved to execute a specific proposal, use a narrow credential or reconcile the resulting state after execution.⁴ Security teams should treat identity freshness, action approval, workload credentialing and post-action verification as separate controls.

Does this raise the account-protection baseline?

For covered enterprises, yes. Proof of presence reduces the chance that an attacker with only a stolen session or token can complete certain high-impact account and organization changes. It also gives enterprises a way to apply identity-provider policies, such as MFA or device checks, at the point of sensitive action rather than only at login.¹

But the baseline increase is uneven. The preview’s Entra ID and EMU scope means many GitHub customers will not see the control immediately.¹² The two-hour session window also reflects a usability trade-off: it limits repeated prompts, but it is not a per-action approval record and does not remove the need for endpoint security, session monitoring and credential inventory.¹⁴

The surrounding September updates reinforce that GitHub is also investing in detection and remediation controls. CodeQL 2.27.1 added query and language-support improvements, including C/C++ and C# queries, Kotlin 2.4.20 support and GitHub Actions query behavior changes related to pinned actions.⁹ Those improvements address a different layer of supply-chain defense: finding vulnerable code and risky workflow patterns before they are exploited.

For security engineers and DevSecOps teams, the operational takeaway is straightforward: enable proof of presence where eligible, require the strongest feasible identity-provider policy, verify which actions are actually covered, and update runbooks for token creation, webhook administration, recovery-code access and organization security changes.

Then treat the feature as one control in a layered model, not as a replacement for least privilege, short-lived credentials, branch protections, code scanning, audit logging and explicit approval gates for automation.