O GitHub Agentic Workflows ficou disponível em GA em 28 de outubro de 2026. Antes de qualquer repo ativar, trave três pontos: quem pode liberar saídas com escrita, quais triggers entregam texto não confiável ao agente e o orçamento de créditos de IA. Por padrão o agente só lê, e toda escrita passa por um job de safe outputs.
O que o GitHub lançou em 28 de outubro de 2026?
O GitHub declarou o Agentic Workflows disponível em GA em 28 de outubro de 2026. O projeto nasceu no GitHub Next e é open source. A proposta é automatizar trabalho que exige raciocínio, como triagem de issues, análise de falhas de CI, atualização de documentação e escrita de testes. Quem executa esse trabalho são coding agents rodando dentro do GitHub Actions.
A automação é escrita em arquivos Markdown, em linguagem natural. Um compilador transforma cada arquivo em YAML padrão do Actions. Para governança, isso pesa. O resultado roda nos runner groups que você já tem e herda as restrições de policy já configuradas.
Cada workflow pode usar o GitHub Copilot ou outro coding agent. A página de arquitetura de segurança cita Copilot, Claude Code, OpenAI Codex, Google Gemini e Pi. O GA vale para GitHub Free, Team e Enterprise no github.com. Usar o engine padrão, o Copilot CLI, exige licença do Copilot.
Desde o public preview, entrou suporte a runners self-hosted do Actions Runner Controller com Docker-in-Docker. O provedor de modelo agora pode ser escolhido por workflow. Um model router pode otimizar a escolha pelo tipo de tarefa e pela dificuldade. Os agentes também podem rodar em micro-VM Cloud Hypervisor ou NVX, com enclaves para evitar vazamento de dados em workflows entre repositórios.
Para quem lidera, o efeito prático é a velocidade de adoção. Segundo o GitHub, dá para instalar a extensão da CLI e disparar o primeiro workflow em minutos. Por isso vale fechar as perguntas de policy abaixo antes de o primeiro repo testar.
Quais permissões um agentic workflow recebe por padrão?
Por padrão, um agentic workflow recebe só permissões de leitura. A referência de permissões diz que operações de escrita passam por safe outputs, que acrescentam um job extra. O GitHub dá quatro motivos para essa separação: trilha de auditoria, menor raio de impacto se o agente se comportar mal, suporte a gates de aprovação de compliance e defesa contra prompt injection.
Alguns detalhes mudam o que o revisor deve procurar. O compilador adiciona actions: read sozinho, para checar se o workflow gerado está atualizado. Com copilot-requests: write é diferente. O autor opta por ela para inferência do Copilot cobrada da organização, e o compilador não a adiciona por padrão. Escopos exclusivos de GitHub App, como administration ou workflows, precisam ser declarados sempre como leitura.
O ponto de controle de verdade é o bloco de safe outputs. A referência cataloga muitos tipos de escrita, de adicionar um comentário até criar um pull request ou fazer push na branch de um PR. Um workflow que pode subir código tem um risco bem diferente do de um workflow que só aplica labels. A mesma referência traz padrões de labels bloqueadas e um staged mode para safe outputs. Vale ler os dois antes do primeiro workflow com escrita ir para produção.
Além das permissões, o anúncio do GA lista proteções em camadas. Os agentes leem conteúdo do GitHub respeitando as regras de integrity filtering. Executam num container em sandbox, atrás do Agent Workflow Firewall. Um job dedicado de threat detection analisa todas as mudanças propostas antes de aplicá-las. A documentação de arquitetura deixa claro o modelo de ameaça. O adversário pode comprometer containers e outros componentes não confiáveis de nível de usuário, e parte-se do princípio de que o hardware não é comprometido.
Por que prompt injection importa para agentes de IA no CI?
Importa porque um agente no CI lê texto escrito por pessoas de fora do seu time. Um artigo enviado ao arXiv em 8 de maio de 2026 chama essa falha de Agentic Workflow Injection. Ela acontece quando contexto não confiável de eventos do GitHub, como corpo de issue, descrição de pull request ou comentário, entra no prompt do agente ou num input que ele consome.
Os autores descrevem dois padrões. No Prompt-to-Agent, o conteúdo não confiável chega direto à fronteira do prompt. No Prompt-to-Script, a influência do atacante passa pela saída do modelo ou do agente e chega a scripts executados depois. Por essa definição, um step comum de script que consome a saída do agente também entra na superfície de ataque.
A ferramenta dos autores, TaintAWI, analisou 13.392 agentic workflows reais de 10.792 repositórios. Ela apontou 519 vulnerabilidades potenciais, e 496 foram confirmadas como exploráveis no modelo de ameaça do artigo, uma precisão de 95,6%. Dessas, 343 eram zero-days até então desconhecidos. Os autores priorizaram 187 para divulgação, receberam 26 respostas de mantenedores e 24 casos foram aceitos ou corrigidos até a escrita do artigo.
A ligação com este lançamento está na lista de triggers. Todo workflow que começa por issue, pull request ou comentário recebe texto não confiável. A própria página de arquitetura do GitHub cita prompt injection entre as ameaças contra as quais suas camadas protegem.
O que pesa no custo do GitHub Agentic Workflows?
Pesam duas coisas citadas no anúncio do GA: o gasto de créditos de IA e a licença do Copilot exigida pelo engine padrão, o Copilot CLI. Do lado dos créditos, o comando gh aw forecast deixou de ser experimental no GA. Ele inclui os créditos de threat detection e dá faixas mensais, então a varredura de segurança aparece na estimativa.
Duas escolhas de cobrança ficam com o dono da plataforma. A primeira é o engine, já que dá para trazer outro agente por workflow no lugar do Copilot. A segunda é copilot-requests: write, que o autor ativa para inferência do Copilot cobrada da organização. O GitHub documenta à parte o usage-based billing para organizações e enterprises. A documentação do Agentic Workflows tem páginas de cost management sobre billing, rate limiting e auditoria de workflows.
Controles para definir antes de um repo aderir
| Controle | O que a documentação oferece | Decisão do dono da plataforma |
|---|---|---|
| Permissões padrão | Leitura, com escrita via safe outputs. Existe o atalho read-all |
Manter só leitura. Tratar read-all como mudança revisada |
| Saídas com escrita | Comentários, labels, criação de PR, push em branch de PR, staged mode | Liberar comentários e labels primeiro. Push de código só com revisão da plataforma |
| Permissão de cobrança | copilot-requests: write é opt-in, nunca default do compilador |
Definir quem pode adicionar |
| Gasto | gh aw forecast com créditos de threat detection e faixas mensais |
Rodar antes de ativar e registrar a faixa |
| Triggers | Corpo de issue, descrição de PR e comentários são a porta de entrada citada no estudo do arXiv | Listar todo workflow de agente disparado por esse input |
| Isolamento | Sandbox, Agent Workflow Firewall, micro-VM, enclaves | Exigir enclaves em workflows entre repositórios |
| Runners | Runner groups e policies existentes, ARC com Docker-in-Docker | Colocar agentic workflows num runner group dedicado |
O que checar nesta semana
Dê cinco dias úteis para a revisão e um único responsável.
Até terça, faça o inventário. Encontre todo workflow da organização que chama um agente de IA e marque os disparados por issues, pull requests ou comentários. Esses batem com o padrão descrito no estudo do arXiv.
Até quarta, escreva a policy padrão. Agentic workflows ficam só com leitura. Adicionar copilot-requests: write precisa de aprovação da plataforma. Qualquer safe output que cria pull request ou faz push numa branch passa pela mesma revisão de uma deploy key.
Até quinta, escolha um piloto de baixo risco num repo interno. Entre os exemplos prontos do GitHub Next há triagem, um bom ponto de partida. Rode gh aw forecast nele e registre a faixa mensal antes de o workflow entrar no ar.
Até sexta, leia as páginas de safe rollout e de compiler controls na documentação do Agentic Workflows. Decida se workflows entre repositórios precisam usar enclaves. Qualquer repo que queira ir além do piloto espera essa decisão.
Fontes
- github.blog/changelog/2026-10-28-github-agentic-workflows-generally-…, consultada em 30 de outubro de 2026.
- github.github.com/gh-aw/introduction/architecture, consultada em 30 de outubro de 2026.
- github.github.com/gh-aw/reference/permissions, consultada em 30 de outubro de 2026.
- github.github.com/gh-aw/reference/safe-outputs, consultada em 30 de outubro de 2026.
- docs.github.com/en/copilot/concepts/billing/organizations-and-enterprise…, consultada em 30 de outubro de 2026.
- arxiv.org/abs/2605.07135, consultada em 30 de outubro de 2026.