TL;DR: O Azure SRE Agent agora suporta conexão com GitHub Enterprise Cloud via Bring Your Own GitHub App, substituindo tokens pessoais por uma identidade de serviço governada. A chave privada fica no Azure Key Vault, tokens são curtos (1h) e as permissões são declaradas. Isso permite que o agente acesse código, infraestrutura e runbooks com rastreabilidade total — essencial para conformidade e auditoria em empresas brasileiras que operam em ambientes corporativos gerenciados.
E se o seu SRE agent pudesse acessar os repositórios corporativos da sua empresa da mesma forma que seus pipelines CI/CD — com uma identidade de serviço governada, e não um token pessoal?
O Azure SRE Agent conecta-se aos seus repositórios GitHub para construir um contexto rico sobre o código-fonte, definições de infraestrutura, configurações de deployment, skills, runbooks e histórico operacional dos seus sistemas. Esse contexto é o que transforma troubleshooting genérico em root cause analysis que aponta exatamente para o arquivo, o commit, a mudança de configuração. Esta funcionalidade faz parte dos anúncios do Azure SRE Agent no Build 2026.
Para equipes no github.com, a conexão é feita com um rápido OAuth. Agora, a Microsoft estende esse mesmo contexto profundo para o GitHub Enterprise Cloud e apresenta o Bring Your Own GitHub App como um modelo de autenticação de primeira classe para equipes corporativas que precisam de acesso governado e baseado em aplicações aos seus repositórios.
Por que usar uma GitHub App é melhor para identidade corporativa?
Grandes organizações rodam no GitHub Enterprise Cloud com EMU (Enterprise Managed Users). Nesses ambientes, cada identidade é gerenciada centralmente, tokens são escopados por política, rotacionados em prazo e vinculados a pessoas específicas.
Quando um SRE agent precisa acessar seus repositórios, a identidade que ele usa importa. Com uma GitHub App, o agente opera sob uma identidade de serviço registrada e pertencente à sua organização. Cada operação no repositório — cada clone, cada consulta a issues, cada leitura de arquivo — é atribuída à instalação do App, não a um engenheiro individual. As equipes de segurança e compliance podem rastrear a atividade do agente até uma identidade de serviço governada, e os logs de auditoria refletem exatamente o que aconteceu.
GitHub Apps são o mesmo modelo de identidade que as empresas já usam para pipelines CI/CD, automação de deployment e ferramentas internas. O BYO App estende isso para o SRE Agent.
Como funciona a autenticação com BYO App?
Quando você traz sua própria GitHub App para o Azure SRE Agent, o fluxo de autenticação usa tokens de curta duração com permissões explícitas: sua organização registra uma GitHub App em sua instância GHE (ou no github.com) com as permissões específicas de repositório que você escolher: Contents Read, Metadata Read e, opcionalmente, Issues ou Pull Requests.
A chave privada do App fica no Azure Key Vault. A managed identity do agente lê o PEM em tempo de execução, gera um JWT e troca por um token de instalação que expira em cerca de 1 hora. A chave privada nunca sai do Key Vault.
As permissões são declaradas, não herdadas. O App tem exatamente o acesso configurado no registro. O agente não consegue ultrapassar esses limites, independentemente de quem o configurou.
O refresh do token é automático. Nenhum token humano para expirar, nenhuma cadeia de refresh para manter. O agente gera novos tokens de instalação conforme necessário.
Para organizações que gerenciam múltiplas instâncias do GitHub — por exemplo, uma para platform engineering e outra para times de aplicação — cada instância recebe sua própria GitHub App com seu próprio segredo no Key Vault. Você pode atribuir uma user-assigned managed identity diferente por App para isolamento de segurança. Desconectar um host não afeta os outros.
O que o agente faz com o acesso ao GitHub?
Uma vez conectado, o agente usa o GitHub para muito mais do que código-fonte. Os repositórios contêm os artefatos que definem como seus serviços funcionam e como o agente raciocina sobre eles:
- Código-fonte e definições de infraestrutura. O agente lê código de aplicação, templates Bicep, configurações Terraform e Dockerfiles para entender o que um serviço realmente faz — não o que a documentação diz.
- Skills e runbooks. As equipes armazenam skills do agente, planos de resposta e runbooks operacionais como arquivos em repositórios. O acesso ao GitHub permite que o agente carregue e atualize esses artefatos diretamente.
- Histórico de configuração e deployment. Helm charts, definições de pipeline, configs de ambiente e manifests de release dão ao agente o contexto para correlacionar um incidente com o que mudou e quando.
- Issues e pull requests. O agente pode buscar issues por problemas conhecidos, verificar PRs recentes em busca de candidatos a regressão e criar issues ou PRs quando identifica uma correção.
Logs dizem ao agente o que aconteceu. Código diz por quê. Seus skills e runbooks dizem o que fazer a respeito.
A diferença com o BYO App é a identidade sob a qual tudo isso acontece. Essas operações ocorrem sob a identidade do App da sua organização, com as permissões que você declarou, a trilha de auditoria que você governa e o ciclo de vida da chave que você controla.
Como funciona para hosts do GitHub Enterprise Cloud?
Para domínios do GitHub Enterprise Cloud (*.ghe.com), o assistente Code Access seleciona automaticamente o BYO App como método de autenticação. Isso é proposital: hosts GHE Cloud usam exclusivamente autenticação baseada em App.
O setup:
- Crie uma GitHub App em sua instância GHE. Defina Contents: Read e Metadata: Read como mínimo. Instale-a nos repositórios que o agente precisa.
- Armazene a chave privada no Azure Key Vault — conteúdo PEM completo como um secret.
- Conceda à managed identity do agente a função Key Vault Secrets User nesse vault.
- Informe o Client ID e a URI do secret no Code Access. O agente valida as credenciais e carrega seus repositórios.
O BYO App no github.com funciona da mesma forma — útil quando a política da sua organização exige autenticação baseada em App mesmo para GitHub público.
Recursos
- Criar novo SRE Agent — https://aka.ms/sreagent
- Documentação do SRE Agent — https://aka.ms/sreagent/newdocs
- Receitas do SRE Agent — https://aka.ms/sreagent/recipes
- Anúncios do Build 2026 — https://aka.ms/Build26/blog/SREAgent
Perguntas Frequentes
-
Por que usar uma GitHub App em vez de um token pessoal para conectar o SRE Agent?
- Porque a identidade é de serviço, registrada e pertencente à organização. Cada operação é atribuída ao App, não a um engenheiro individual. Tokens são curtos (1h), a chave privada fica no Key Vault, e as permissões são declaradas – o agente nunca ultrapassa os limites configurados.
-
Como funciona o fluxo de autenticação do BYO App com Azure SRE Agent?
- A organização registra uma GitHub App no GHE ou github.com com permissões específicas (Contents Read, Metadata Read). A chave privada é armazenada no Azure Key Vault. A managed identity do agente lê o PEM, gera um JWT e troca por um token de instalação que expira em cerca de 1 hora – tudo automático, sem token humano.
-
Quais permissões mínimas são necessárias para o agente funcionar?
- Contents: Read e Metadata: Read. Opcionalmente, Issues e Pull Requests podem ser adicionadas. As permissões são declaradas no registro da App e o agente não consegue acessar nada além do que foi configurado.
-
O que o agente faz com o acesso ao GitHub?
- Lê código-fonte, templates Bicep, configurações Terraform, Dockerfiles, Helm charts, runbooks, históricos de deploy, issues e PRs. Ele correlaciona incidentes com mudanças exatas e pode criar issues ou PRs corretivos. Tudo ocorre sob a identidade governada da App.
-
Como configurar para múltiplas instâncias GitHub Enterprise?
- Cada instância do GitHub recebe sua própria GitHub App com segredo próprio no Key Vault. É possível atribuir uma user-assigned managed identity diferente por App para isolamento de segurança. Desconectar uma instância não afeta as outras.
Artigo originalmente publicado por dchelupati em Azure Updates - Latest from Azure Charts.
