GitHub pede nova prova de identidade antes de ações críticas

O GitHub abriu em 24 de setembro de 2026 a prévia pública do Proof of Presence para o GitHub Enterprise Cloud, segundo o comunicado de lançamento. O recurso permite exigir uma nova autenticação pelo Microsoft Entra ID antes de ações de alto impacto. Nesta fase, a prévia está restrita a empresas com Enterprise Managed Users (EMU) no github.com ou no GitHub Enterprise Cloud com residência de dados (GHEC-DR) que usam Entra ID para login único por SAML ou OIDC.

Para o administrador, a mudança é que uma sessão aberta pode deixar de ser suficiente para concluir uma operação protegida. Quando a verificação é necessária, o membro é enviado ao Entra ID, cumpre a exigência definida pela empresa e retorna ao GitHub. A empresa escolhe entre solicitar nova autenticação ou exigir também autenticação multifator (MFA); o efeito de cada opção depende das políticas e dos métodos disponíveis no provedor de identidade.

Quais ações passam pelo desafio

O Proof of Presence acrescenta uma verificação pelo provedor de identidade ao modo sudo, que o GitHub usa em operações sensíveis. Os exemplos do lançamento incluem criar um token, editar webhooks, alterar configurações de segurança de uma organização e visualizar códigos de recuperação. A documentação relaciona a proteção às ações que já acionam o modo sudo, em vez de apresentar uma lista de operações que cada empresa possa selecionar individualmente.

O desafio ocorre perto da ação: o GitHub só permite sua continuação quando o membro volta do Entra ID após cumprir a política exigida. Isso pode impedir que alguém de posse apenas de uma sessão sequestrada conclua uma alteração sensível. A verificação, porém, não elimina o roubo de sessões nem revoga por si só credenciais que já tenham sido expostas.

A análise da Birdcage Tech observa que, depois de um desafio bem-sucedido, a confirmação permanece válida por duas horas na mesma sessão do navegador. Nesse intervalo, outras ações protegidas podem prosseguir sem um novo pedido de Proof of Presence. Assim, a barreira reduz o alcance de uma sessão comprometida antes da verificação, mas não equivale a uma aprovação separada para cada alteração posterior.

Quem pode usar a prévia

O recorte do lançamento é mais estreito que a categoria geral GitHub Enterprise Cloud: a empresa precisa usar EMU e Microsoft Entra ID como provedor de login único, nas implantações mencionadas pelo GitHub. Uma assinatura Enterprise Cloud, isoladamente, não confirma acesso ao recurso. Quem usa outro provedor de identidade ou contas fora do recorte anunciado não deve presumir que a opção esteja disponível.

Há uma diferença de alcance entre as páginas oficiais que merece atenção. A documentação geral de configuração também descreve pré-requisitos de login único para empresas que usam contas pessoais, enquanto o comunicado da prévia delimita expressamente a disponibilidade inicial a EMU. Para uma implantação agora, o recorte específico do lançamento é a referência mais segura; a menção a contas pessoais na documentação não confirma que elas participem desta prévia. O recurso ainda pode mudar durante esse período.

O que preparar no Entra ID

A exigência escolhida no GitHub só será tão forte quanto a política de autenticação aplicada no Entra ID. Em Re-authentication, o membro precisa autenticar-se novamente, mas a senha pode satisfazer o desafio se a política da empresa permitir. Em MFA, ele também precisa completar um fator adicional configurado no provedor, como um aplicativo autenticador ou uma verificação biométrica. Selecionar MFA no menu do GitHub não registra automaticamente um método para quem ainda não o possui.

Antes da ativação, vale conferir se o login único funciona para as identidades que administram a empresa e se elas conseguem cumprir a exigência escolhida. As políticas de acesso condicional do Entra ID também precisam permitir que o desafio seja concluído e que o membro retorne ao GitHub. Se a empresa impõe conformidade do dispositivo, esse requisito deve ser validado com os dispositivos usados pelos administradores; uma condição impossível de satisfazer bloqueará a ação legítima junto com a indevida.

O ponto de decisão é a experiência real do membro, não apenas o nome da opção selecionada. Uma equipe que pretende exigir um fator adicional deve verificar quais métodos seus administradores têm registrados e como procederão se um deles ficar indisponível. Já uma política que aceita somente a senha oferece uma confirmação recente, mas não a mesma exigência de MFA. Essa distinção importa porque o GitHub delega ao provedor de identidade a verificação de que a política foi cumprida.

Ativação empresarial e rota de recuperação

A documentação de configuração do GitHub orienta o administrador a abrir Settings na conta empresarial, entrar em Authentication security e escolher Re-authentication ou MFA no menu Proof of presence. A política se aplica à empresa inteira. A página não descreve uma ativação limitada a uma organização específica dentro da mesma conta empresarial.

Por isso, a implantação gradual é sobretudo um trabalho de preparação no Entra ID. Uma sequência prudente é validar o login único e os métodos de autenticação com administradores representativos, comunicar a mudança a quem executa operações protegidas e acompanhar falhas de autenticação depois que a política empresarial for ligada. Se houver um ambiente empresarial separado para ensaio, ele pode ajudar a verificar o fluxo completo antes da ativação na conta principal. Essas etapas são uma recomendação operacional, não fases de implantação oferecidas pelo recurso.

A contingência precisa distinguir os dois sistemas. Uma conta administrativa de emergência no Entra ID pode permitir a correção de uma política do provedor que tenha bloqueado os administradores habituais, desde que seu acesso tenha sido preparado e testado. Essa conta não se torna automaticamente administradora do GitHub nem dispensa o desafio do Proof of Presence. Também convém manter identificados os responsáveis pela administração da conta empresarial: se um membro não consegue completar a verificação, será preciso tratar a causa no GitHub ou no provedor de identidade antes de retomar a operação.

O que permanece fora da prévia

A verificação antes da mesclagem de pull requests foi indicada como uma ampliação futura, sem data informada. Portanto, a prévia atual não deve ser tratada como uma barreira já aplicada ao ato de mesclar código. O alcance confirmado é o das ações protegidas pelo modo sudo nas empresas EMU com Entra ID incluídas no lançamento; não há prazo anunciado para ampliar o suporte a outros provedores de identidade.

Leia também:

• Ghost creators ganham escala — a identidade virou parte do risco
• Kit MCP pode alterar sua lista: como limitar permissões antes de conectar a IA
• Política de IA em uma página: sete regras antes de liberar o uso