Como ativar o AI Scan em pull requests só nos repositórios que importam pela API do GitHub

Fala aí, beleza? O GitHub soltou um conjunto de endpoints REST em preview público pra gerenciar a ativação do AI Scan em pull requests, e isso muda bastante a vida de quem cuida de segurança em organização grande

Porque até então a conversa era essa: entrar na interface, repositório por repositório, clicar, salvar, repetir

Com 5 repositórios, beleza

Com 200, boa sorte 😅

O changelog do GitHub de 10/09/2026 anunciou os endpoints de organização e de repositório pra ler e atualizar essa ativação de forma programática, em lote, só nos repositórios que você escolher

Neste guia eu vou direto ao ponto: o que o recurso é, os pré-requisitos reais (licença, política, permissão, escopo de token), a ORDEM correta de ativação e como confirmar o estado depois que você aplicou

O que é o AI Scan em pull requests e o que mudou com a API

O AI Scan é um motor de varredura baseado em IA que roda em pull requests

Ele não substitui o CodeQL, ele complementa: a proposta é achar vulnerabilidades em linguagens e frameworks que não estão cobertos pela análise do CodeQL

E roda automaticamente quando um pull request é aberto ou atualizado, sem alguém precisar disparar nada na mão

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que mudou de julho pra setembro:

O recurso em si já tinha sido anunciado antes: em 14/07/2026 saiu o changelog contando que o code scanning passou a exibir detecções de segurança com IA em pull requests, também em preview público

O que entrou agora, em 10/09/2026, foi a camada de gestão: os endpoints REST

São dois:

• /orgs/{org}/code-scanning/ai-scan (nível de organização)
• /repos/{owner}/{repo}/code-scanning/ai-scan (nível de repositório)

Os dois suportam GET pra ler o estado e PATCH pra atualizar

A divisão de responsabilidade é a parte que mais gera confusão, então já deixo cravado aqui: a organização controla SE os scans de pull request podem rodar, e o repositório liga ou desliga individualmente

A configuração de repositório não sobrepõe um estado desligado na organização

Ou seja: ligar no repo com a org desligada não resolve nada

Onde isso funciona (e onde não funciona):

O preview público está disponível no github.com para clientes do GitHub Advanced Security

GitHub Enterprise Server não é suportado neste lançamento

E os endpoints estão em preview público, sujeitos a mudança, então vale reler a doc antes de embutir isso num pipeline que você não quer ver quebrar

Pré-requisitos: licenças, permissões e escopos de token

Antes de chamar qualquer endpoint, roda esse checklist

A maioria dos erros que aparecem aqui não é erro de sintaxe do curl, é pré-requisito faltando

Licenças. Durante o preview público, as detecções de segurança com IA exigem licença de GitHub Advanced Security E licença de GitHub Copilot

O uso consome AI credits, e isso pesa na decisão de ligar em tudo de uma vez

Política do enterprise. O enterprise owner precisa permitir as detecções com IA na política do enterprise

Por padrão, não é permitido no nível do enterprise, e é desabilitado nos níveis de organização e de repositório

Tudo começa desligado, de propósito

Quem pode chamar. Pra usar o endpoint de organização, o usuário autenticado precisa ser owner ou security manager da organização

Escopos e permissões. Aqui é onde as pessoas se enrolam, então segue a tabela:

Se você já configurou chave de API em outra ferramenta, a lógica é a mesma: o token carrega exatamente o que ele tem permissão de fazer, nem mais nem menos

A diferença é que aqui o token errado não te dá um resultado ruim, ele te dá uma porta fechada

CodeQL default setup. Pra as detecções com IA rodarem em pull requests, o repositório precisa estar com o CodeQL default setup habilitado

A ordem oficial dos pré-requisitos é essa: 1) enterprise owner permite na política do enterprise, 2) recurso habilitado no nível da organização, 3) repositório com CodeQL default setup habilitado

Decorou essa ordem? Metade do trabalho tá feito

Passo a passo: ativar o AI Scan pela API REST

A URL base é a API pública do GitHub

Nos exemplos abaixo eu uso $GITHUB_TOKEN como variável de ambiente, troca ORG, OWNER e REPO pelos teus valores

1. Leia o estado atual da organização antes de mexer em qualquer coisa

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/orgs/ORG/code-scanning/ai-scan

O erro comum deste passo: sair direto pro PATCH sem saber de onde você está partindo

O GET é barato e te diz se o problema é permissão (token sem escopo, usuário que não é owner nem security manager) antes de você tentar escrever

2. Ative no nível da organização com PATCH

curl -L -X PATCH \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/orgs/ORG/code-scanning/ai-scan \
  -d '{"pr_scan":"enabled"}'

O corpo de atualização usa o campo pr_scan com os valores enabled ou disabled

Como o recurso está em preview público e sujeito a mudança, confere o corpo esperado na doc antes de automatizar isso pra 200 repositórios

O erro comum deste passo: a configuração de organização respeita a política de enterprise, e a ativação é REJEITADA quando o enterprise não permite o AI Scan

Se isso acontecer, não adianta insistir no curl, o caminho é falar com o enterprise owner

3. Garanta o CodeQL default setup nos repositórios alvo

Esse é pré-requisito das detecções com IA rodarem no pull request

O erro comum deste passo: ligar o AI Scan no repositório, ver a chamada responder bonitinho e depois estranhar por que nada aparece no PR

Sem CodeQL default setup habilitado no repositório, o pré-requisito não está cumprido

4. Ative em cada repositório escolhido

curl -L -X PATCH \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/repos/OWNER/REPO/code-scanning/ai-scan \
  -d '{"pr_scan":"enabled"}'

Aqui mora a graça toda: você liga só onde importa, em vez de espalhar por tudo

O erro comum deste passo: começar por aqui, com a organização ainda desligada

Lembra da regra dura? Configuração de repositório não sobrepõe estado desligado na organização

Primeiro a org, depois o repo, sempre nessa ordem

5. Desligue um repositório específico trocando o valor

curl -L -X PATCH \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/repos/OWNER/REPO/code-scanning/ai-scan \
  -d '{"pr_scan":"disabled"}'

Mesmo endpoint, mesmo campo, valor disabled

Útil quando um repositório entrou no piloto e você quer tirar ele sem mexer no resto da organização

Como confirmar o estado depois de aplicar

Aplicou, agora confere

Não confia só no retorno do PATCH, faz a leitura

Conferindo a organização e um repositório:

# organização
curl -s \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/orgs/ORG/code-scanning/ai-scan

# repositório
curl -s \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/repos/OWNER/REPO/code-scanning/ai-scan

Como isso é preview público sujeito a mudança, o conselho é ler a resposta inteira em vez de fixar teu script num campo específico que pode virar outro nome semana que vem

Auditando vários repositórios de uma vez:

Pra checar uma lista, o caminho direto é iterar sobre os repositórios que você já mantém mapeados

for repo in api-gateway checkout-service billing-worker; do
  echo "== $repo"
  curl -s \
    -H "Accept: application/vnd.github+json" \
    -H "Authorization: Bearer $GITHUB_TOKEN" \
    https://api.github.com/repos/ORG/$repo/code-scanning/ai-scan
  echo
done

Quem já automatizou rotina de vários repositórios remotos no git sabe que a parte chata nunca é o comando, é manter a lista honesta

Tome cuidado com a interpretação! A leitura do repositório só faz sentido junto com a leitura da organização

Um repositório pode aparecer ligado enquanto a organização está desligada, e nesse cenário o que vale é o nível de organização, porque a configuração do repositório não sobrepõe o estado desligado da org

Sempre lê os dois antes de dizer "tá tudo certo"

Quando vale ativar em lote pela API (e quando não vale)

Nem todo mundo precisa disso, e tá tudo bem

Vale quando:

• Rollout gradual por criticidade. Você liga primeiro nos repositórios que tocam autenticação, pagamento e dado sensível, e só depois expande
• Organização com muitos repositórios. Configurar um por um na interface deixa de ser trabalho e vira penitência
• Auditoria periódica. Rodar o GET numa lista e registrar quem está com o scan ligado é o tipo de coisa que ninguém faz na mão duas vezes
• Piloto restrito por causa de custo. O uso das detecções com IA consome AI credits, então começar num recorte pequeno e medir antes de escalar é decisão sóbria, não frescura

Não vale quando:

• Você tem poucos repositórios: montar token, escopo e script pra três repos é mais trabalho do que resolver na interface
• Você está no GitHub Enterprise Server: não é suportado neste lançamento, então não tem API pra chamar
• Você não é cliente do GitHub Advanced Security: o preview público é pra esse público no github.com

E pra começar do zero na carreira, esse vídeo do canal mostra 3 coisas que não importam tanto assim pra você ser dev, num papo reto sobre prioridade de quem está entrando na área

Conclusão

A ordem é a chave de tudo aqui, e ela é curtinha:

1. Enterprise permite as detecções com IA na política
2. Organização habilita via PATCH no endpoint /orgs/{org}/code-scanning/ai-scan
3. Repositório com CodeQL default setup habilitado liga via PATCH no /repos/{owner}/{repo}/code-scanning/ai-scan

Inverteu a ordem, você vai ficar debugando token achando que é problema de permissão quando na verdade é a organização desligada segurando tudo

E o lembrete honesto: isso é preview público, sujeito a mudança, sem GA registrado até 13/09/2026, só no github.com pra clientes do GitHub Advanced Security

O próximo passo prático é escolher um repositório piloto, ativar, conferir com GET nos dois níveis e acompanhar o que aparece nos pull requests

Se tiver opinião ou tropeçar em algo, tem a discussão oficial na GitHub Community pra deixar feedback do recurso, que é justamente o que o GitHub pede em preview

Segurança automatizada é massa, mas ligada no lugar certo, na ordem certa 😀

até o próximo post!