Desde 25 de setembro de 2026, o agentic autofix do GitHub passou a usar o Copilot Memory quando esse recurso está habilitado. Na prática, a sessão de correção pode consultar memórias já existentes para obter contexto útil sobre o repositório e, depois de produzir uma correção, pode registrar o padrão dessa solução como memória para uso futuro. O ganho potencial é tornar novas correções mais alinhadas às convenções e aos padrões de segurança já observados no projeto. Para quem revisa essas mudanças, porém, isso acrescenta uma nova camada ao trabalho: além de conferir o diff, é importante considerar qual contexto persistente pode ter influenciado a proposta.
O que mudou no agentic autofix
O agentic autofix já funcionava como um fluxo de remediação orientado por agente. Ao atribuir um alerta de code scanning ao Copilot, o agente pode explorar arquivos relevantes da base, gerar uma correção, validar o resultado e iterar antes de abrir uma pull request para revisão. A integração anunciada em 25 de setembro adiciona o Copilot Memory a esse ciclo para clientes que o habilitaram.
Segundo o changelog do GitHub, o agentic autofix agora revisa memórias existentes em busca de contexto que possa ajudar a resolver alertas de segurança. Quando cria uma correção, também armazena o padrão usado como memória para uso posterior. O GitHub afirma ainda que essas memórias podem ajudar a resolver outros alertas e alimentar recursos compatíveis do Copilot, como a revisão de código e o cloud agent, com padrões de desenvolvimento seguro específicos do repositório.
Por que isso muda a revisão das correções
Antes dessa integração, a avaliação de uma correção já exigia verificar se o patch realmente eliminava o problema sem introduzir regressões. Com memória persistente, a proposta também pode refletir convenções inferidas em trabalhos anteriores. Isso pode melhorar consistência, mas transforma parte do contexto em algo reutilizável entre interações.
Para a revisão humana, o ponto principal é não tratar a recorrência de um padrão como prova de que ele continua correto. Uma correção semelhante pode ter funcionado antes e ainda assim não ser apropriada para outro trecho, outro fluxo de dados ou outra fronteira de confiança. O GitHub documenta que fatos de repositório armazenados pelo Copilot Memory têm citações para o código que os sustenta e são validados novamente na branch atual antes do uso. Essa validação reduz o risco de contexto obsoleto, mas não substitui a análise da pull request.
O que revisar em uma pull request criada pelo agentic autofix
- Se a vulnerabilidade foi realmente encerrada: confirme a relação entre o alerta original, a causa raiz e a alteração proposta. A validação automática é um sinal importante, mas deve ser lida junto com o diff e com os resultados de análise apresentados.
- Se o padrão aprendido cabe naquele contexto: procure abstrações, helpers, convenções ou decisões arquiteturais que podem ter sido reaproveitados. Um padrão adequado em um módulo pode ser inadequado em outro.
- Se surgiram mudanças laterais: o agentic autofix pode explorar arquivos além do ponto inicial do alerta. Revise escopo, chamadas relacionadas, configuração, testes e efeitos indiretos.
- Se os testes cobrem o comportamento relevante: valide caminhos de sucesso e falha, entradas hostis, autorização, tratamento de erro e casos limite coerentes com a vulnerabilidade.
- Se a correção altera fronteiras de confiança: preste atenção especial a autenticação, autorização, serialização, consultas, arquivos, comandos, rede, segredos e validação de entrada.
- Se a explicação do agente corresponde ao código: não aceite o resumo da pull request como substituto da leitura do patch. A descrição deve ser consistente com a alteração efetiva e com os resultados de validação.
Copilot Memory não é apenas histórico de correções
O Copilot Memory pode armazenar fatos no nível do repositório, como convenções de código, decisões de arquitetura, comandos de build e regras específicas do projeto, além de preferências no nível do usuário. A documentação informa que recursos compatíveis podem compartilhar esse conhecimento. Por exemplo, algo aprendido em uma interação pode posteriormente ajudar outro recurso do Copilot a interpretar o mesmo repositório.
Há limites de escopo importantes. Fatos no nível do repositório só podem ser usados em operações no mesmo repositório e podem ser revisados e excluídos pelos proprietários do repositório. O GitHub também informa que fatos ou preferências que não forem usados são apagados automaticamente após 28 dias, embora esse prazo possa ser reiniciado quando uma entrada é validada e usada novamente.
Governança: habilitação, revisão e exclusão de memórias
O Copilot Memory está em prévia pública. Para assinaturas Copilot gerenciadas por organização ou empresa, a documentação atual indica que o recurso fica desativado por padrão até ser permitido por um administrador. Depois disso, usuários podem desabilitá-lo em suas próprias configurações. Administradores e proprietários de repositório também têm mecanismos para revisar e excluir fatos armazenados no nível do repositório.
Esse controle é relevante para equipes de segurança porque o contexto reutilizado passa a fazer parte do ambiente que influencia futuras sugestões. Uma prática útil é tratar a curadoria de memórias como parte da governança do Copilot: remover fatos incorretos ou desatualizados e manter instruções explícitas para requisitos que não devem depender apenas de inferência automática.
Como a equipe pode adaptar o processo de revisão
A integração não elimina as etapas tradicionais de secure code review. Ela muda a origem de parte do contexto usado para gerar o patch. Por isso, equipes que adotam o agentic autofix podem registrar na checklist de revisão três perguntas adicionais: qual convenção parece ter orientado esta correção, essa convenção ainda é válida para este trecho e existe algum fato armazenado no Copilot Memory que deveria ser corrigido ou removido?
Também vale separar memória de instruções normativas. O GitHub apresenta o Copilot Memory como conhecimento aprendido ao longo das interações, enquanto instruções personalizadas continuam sendo o mecanismo explícito para regras que a equipe deseja impor. Para controles críticos, requisitos de segurança e decisões arquiteturais obrigatórias, uma instrução versionada e revisável tende a ser uma referência mais clara do que depender somente do que o agente aprendeu.
O que permanece em aberto durante a prévia pública
Tanto o agentic autofix quanto o Copilot Memory continuam em prévia pública e podem mudar. A atualização de 25 de setembro confirma a integração e o reaproveitamento de padrões, mas não transforma cada memória em uma regra de segurança garantida. O valor prático está em fornecer contexto adicional ao agente, enquanto a responsabilidade de decidir se a correção é apropriada continua no fluxo de revisão e merge da equipe.
