GitHub Copilot passa a aceitar autenticação servidor a servidor via GitHub Apps (preview público)

Fala aí, beleza? O GitHub anunciou em 27/10/2026, em preview público, a autenticação servidor a servidor no GitHub Copilot para GitHub Apps instalados em organizações, segundo o changelog oficial

Na prática: serviços e agentes feitos com o GitHub Copilot SDK agora fazem requisições em nome da organização, sem usar as credenciais de um usuário logado 🙂

O que mudou na autenticação do GitHub Copilot SDK

A identidade passa a ser da carga de trabalho, e não de uma pessoa

O GitHub chama isso de workload-owned identity: segundo o anúncio, agentes e serviços automatizados conseguem operar em escala maior sem amarrar a autenticação ou o uso a usuários individuais

E por que isso importa?

Porque pipeline e bot pendurado na conta de um dev é aquele tipo de coisa que funciona lindo até o dia em que a pessoa sai do time ou troca de permissão, né? Com o app como identidade, o agente deixa de depender da conta de alguém

Se você ainda tá se situando no produto, vale ler antes o que é o GitHub Copilot e depois voltar aqui

Status atual: preview público, e até 28/10/2026 não apareceu nenhuma reversão ou mudança de status

Como funciona a autenticação servidor a servidor com GitHub Apps

São três peças, segundo a documentação oficial: permissão, instalação e token

1. Permissão: o GitHub App recebe a permissão de organização Copilot Requests, em modo somente leitura
2. Instalação: o app é instalado na organização que vai ser cobrada pelo uso. Segundo a documentação, essa organização precisa estar habilitada para requisições do Copilot vindas de instalações de GitHub App
3. Token: um installation access token de curta duração (prefixo ghs_) é gerado e passado para a opção explícita do SDK (gitHubToken, github_token ou equivalente, dependendo da linguagem)

Se liga nesse detalhe, porque inverte a lógica que parece mais intuitiva: a variável de ambiente COPILOT_GITHUB_TOKEN só entra em cena quando você está conectando a um runtime existente via URI, e não é o caminho padrão para passar o installation token

Outro ponto que pega muita gente: installation tokens expiram após uma hora

Antes de expirar, você precisa gerar um token novo. Daí depende de como o SDK tá rodando: em processo filho, reinicia o cliente do SDK com o token novo; em runtime in-process ou runtime existente, reinicia o runtime host com o token novo

Os detalhes ficam na página Server-to-server authentication do Copilot SDK no GitHub Docs

Quem paga e quem controla o uso do Copilot pelos apps

O uso feito pelo app é atribuído e cobrado à organização dona da instalação

E os guardrails (limites) da organização continuam valendo: políticas de modelo, orçamentos e controles de gasto se aplicam ao app também

As políticas de modelo ganham ainda mais peso com agente rodando sozinho, ainda mais quando um modelo sai de linha, como no caso do MAI-Code-1-Flash descontinuado no Copilot

Do lado dos owners da organização, o controle fica assim:

• ver quais apps têm acesso
• identificar o uso de cada app nos relatórios CSV de uso de IA pelo campo app_client_id
• cortar o acesso suspendendo ou desinstalando o app

Quem ganha mais com isso?

Times que rodam agentes, bots e automações em escala, e owners que precisam auditar custo por app em vez de tentar adivinhar qual dev disparou o quê haha

Limitações do preview antes de levar para produção

O que está confirmado até agora:

• o recurso está em preview público
• vale só para GitHub Apps instalados em organizações
• o token dura uma hora e a renovação exige reiniciar o cliente do SDK (processo filho) ou o runtime host (runtime in-process ou existente), o que pesa em processos de longa duração

Tome cuidado: se o seu agente fica rodando por horas, a renovação precisa estar planejada desde o começo, senão ele cai no meio do caminho

Antes de colocar em produção, confira a documentação oficial, porque preview pode mudar

Até o momento, não encontramos confirmação de data de disponibilidade geral (GA) para esse recurso

Vídeo de apoio

Se a parte de GitHub em si ainda tá meio nebulosa pra você, tem uma aula do curso de Next.js aqui do canal mostrando como enviar um projeto para o GitHub

Dá pra revisar o básico do fluxo com GitHub antes de partir pros GitHub Apps 😀

Próximo passo para quem roda agentes com o Copilot SDK

Bora pra prática?

Começa mapeando quais automações hoje usam token de um desenvolvedor, porque essas são as candidatas naturais a migrar

Depois crie ou ajuste um GitHub App com a permissão de organização Copilot Requests somente leitura e instale na organização que vai ser cobrada

Planeje a renovação do token a cada hora, já prevendo se vai precisar reiniciar o cliente do SDK (processo filho) ou o runtime host (runtime in-process ou existente)

E por fim, valide no CSV de uso de IA se o consumo aparece atribuído ao app pelo app_client_id

Se tudo bater, tu tem um agente com identidade própria, custo rastreável e sem depender da conta de ninguém, muito massa né?

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.