O GitHub publicou nesta quarta-feira, 10 de setembro de 2026, duas rotas REST em prévia pública para ligar ou desligar o AI Scan, varredura de segurança com inteligência artificial, em pull requests, o pedido para revisar uma mudança no código. Antes, quem queria padronizar a checagem em dezenas ou centenas de repositórios precisava repetir a configuração na interface web; agora a política pode ser lida e alterada por script.
A novidade entrou no changelog oficial do GitHub na tarde de 10 de setembro e apareceu em reportagens independentes no dia seguinte, incluindo análise de 11 de setembro sobre o impacto para equipes de qualidade. O recurso complementa o code scanning já existente e mira administradores de organizações que usam GitHub Advanced Security, o pacote pago de proteção de código da plataforma.
O changelog do GitHub publicado em 10 de setembro de 2026 confirma as rotas `/orgs/{org}/code-scanning/ai-scan` e `/repos/{owner}/{repo}/code-scanning/ai-scan`, a hierarquia em que a organização prevalece sobre o repositório e a exclusão do Enterprise Server. A TechTimes, em 11 de setembro, registra de forma independente o timing em relação ao Enterprise Server 3.22 de 8 de setembro.
Do clique manual ao script de política
As rotas novas ficam em `/orgs/{org}/code-scanning/ai-scan`, para o nível da organização, e `/repos/{owner}/{repo}/code-scanning/ai-scan`, para um repositório específico. Pelo REST, a API de comunicação por HTTP que o GitHub expõe para automação, a equipe consulta se a varredura está ativa e envia atualizações sem abrir cada projeto na web.
A configuração da organização funciona como interruptor geral: se o AI Scan estiver desligado lá, nenhum repositório consegue religá-lo sozinho. Isso evita exceções escondidas quando a empresa decide manter a varredura desativada em parte do portfólio, mas ainda permite ligar o recurso só nos repositórios escolhidos enquanto a política global permanece aberta.
O GitHub descreve a entrega como prévia pública, ou seja, a interface e o comportamento ainda podem mudar antes de virar recurso estável. Mesmo assim, o anúncio já transforma uma opção de painel em dado que pode entrar em pipelines de infraestrutura como código, auditoria e conformidade interna.
O que o AI Scan faz no pedido de revisão
O AI Scan não substitui o CodeQL, motor de análise estática que o GitHub usa no code scanning tradicional. Segundo a documentação citada por veículos especializados em 11 de setembro, a varredura com IA complementa essa cobertura e procura falhas de segurança adicionais no diff do pull request, o conjunto de linhas que entram ou saem da base de código naquele pedido.
Os alertas aparecem no próprio pull request, não como uma fila separada de pendências do repositório. Eles são consultivos: não bloqueiam o merge automaticamente e, na prévia atual, também não podem ser usados como exigência rígida em rulesets, as regras que definem quando uma alteração pode ser incorporada.
A varredura completa do repositório inteiro continua fora do escopo deste modo. O foco é o trecho que alguém está tentando mesclar agora, o que combina com o fluxo de revisão antes do deploy, mas exige leitura humana porque falsos positivos ainda são possíveis, conforme a própria documentação alerta.
Licenças, créditos e pré-requisitos
Ativar o AI Scan por API não basta ter um plano gratuito do GitHub. A prévia exige GitHub Advanced Security na organização, licença do Copilot e consumo de créditos de IA além das licenças base. Também pede permissão de empresa, opt-in da organização e a configuração padrão do CodeQL já habilitada.
Para quem administra custos, isso significa que ligar a varredura em massa pode aumentar o uso de créditos de IA além da assinatura de segurança. O GitHub não publicou, no changelog de 10 de setembro, uma tabela de consumo por pull request analisado; o gasto real só aparece quando a equipe pilota em alguns repositórios e acompanha o painel de uso.
A combinação Advanced Security mais Copilot posiciona o recurso no meio do caminho entre proteção clássica e assistentes de programação. Não é um scanner gratuito nem um substituto do Copilot: a IA entra como camada extra de detecção em cima de uma base de code scanning já paga.
Quem fica de fora nesta rodada
O anúncio limita a prévia ao github.com, a versão hospedada na nuvem. GitHub Enterprise Server, a instalação que empresas rodam em servidores próprios, não recebeu as rotas nem o AI Scan para pull requests nesta entrega, e o changelog não traz data para uma versão futura.
O timing chama atenção porque o Enterprise Server 3.22 chegou à disponibilidade geral em 8 de setembro de 2026, dois dias antes das APIs. Aquela atualização trouxe suporte ao Copilot CLI em ambientes isolados da internet e melhorias de gestão de equipes, mas deixou de fora tanto o AI Scan quanto os endpoints REST anunciados em 10 de setembro.
Organizações que dependem de instâncias self-hosted por exigência regulatória, residência de dados ou redes fechadas precisam aguardar um release futuro do Enterprise Server. Até lá, scripts escritos para a nuvem não funcionam no ambiente local, e políticas de segurança precisam continuar manuais ou baseadas nas ferramentas já suportadas na versão 3.22.
Reportagens de 11 de setembro destacam essa lacuna como ponto central para times híbridos, que misturam repositórios na nuvem com servidores internos. Não há promessa de paridade imediata entre os dois mundos.
Como equipes podem testar sem abrir tudo de uma vez
A API permite rollout seletivo: ligar a varredura primeiro em repositórios piloto, medir ruído de alertas e só então expandir para o restante do portfólio. Análises publicadas em 11 de setembro recomendam registrar tanto a flag da organização quanto a de cada repositório ao investigar por que um pull request não recebeu resultado.
Também sugerem separar dois testes. Um confirma se a política foi aplicada de fato, desligando no nível da organização e verificando se nenhum repositório consegue reativar sozinho. Outro mede utilidade, enviando pull requests controlados com falhas conhecidas e versões seguras para estimar falsos positivos e tempo de revisão humana.
Como os achados não bloqueiam merge, o AI Scan entra como sinal extra, não como portão final. Pipelines de integração contínua, testes automatizados e revisão de pares continuam responsáveis por impedir código quebrado ou inseguro de chegar à produção.
Prévia pública e feedback aberto
O GitHub convida discussão na GitHub Community, fórum oficial da empresa, para feedback sobre a prévia. Isso indica que nomes de campos, códigos de erro ou requisitos de licença ainda podem mudar antes de uma disponibilidade geral.
Quem escreve automação agora deve versionar os scripts como qualquer integração em prévia: fixar a data do changelog consultado, tratar respostas de erro como parte do monitoramento e evitar assumir paridade futura com Enterprise Server sem anúncio explícito.
A prévia também não garante que todos os tipos de vulnerabilidade relevantes para o negócio serão detectados. Ela amplia a superfície coberta pelo code scanning tradicional, mas continua dependente dos modelos e regras que o GitHub associa ao AI Scan na data do anúncio.
Do painel ao pipeline de onboarding
Para desenvolvedores que nunca administraram centenas de repositórios, a mudança parece técnica demais até aparecer o cenário concreto: uma empresa compra outra startup e herda duzentos projetos de uma vez. Sem API, alguém precisaria clicar repositório por repositório; com as rotas novas, a política entra no mesmo script que cria equipes, permissões e proteções de branch.
O ganho imediato é auditável. Logs de infraestrutura como código passam a mostrar quando a varredura foi ligada, por qual administrador e em qual escopo. Isso ajuda auditorias internas e respostas a clientes que perguntam se todo repositório exposto recebe análise antes do merge.
Quem só mantém um ou dois projetos pessoais provavelmente continuará usando o painel web. A novidade importa quando escala, compliance e repetibilidade entram na conversa, não quando a pessoa revisa sozinha o próprio pull request no fim da tarde.
Limites que ainda pedem revisão humana
Mesmo com automação de política, o conteúdo do alerta continua sendo interpretado por alguém da equipe. A documentação consultada em 11 de setembro deixa claro que achados são consultivos e que falsos positivos podem aparecer, especialmente em código que usa padrões incomuns ou bibliotecas pouco comuns.
Também não há, nesta entrega, varredura de repositório inteiro pelo AI Scan. Se a preocupação for código legado que nunca passa por pull request, a API nova não resolve sozinha; ela organiza o que acontece na porta de entrada das mudanças, não um inventário completo de dívida de segurança.
Na próxima incorporação de repositórios, quem cuida da segurança pode incluir a varredura de IA no mesmo script que cria permissões e proteções, em vez de repetir cliques projeto por projeto.