A GitHub tornou a exclusão de conteúdos geralmente disponível, a 2 de setembro, na aplicação GitHub Copilot e no Copilot CLI. Para clientes Copilot Business e Copilot Enterprise, estas duas interfaces passam a respeitar as regras configuradas por administradores ao nível da empresa, da organização ou do repositório, evitando que os ficheiros excluídos sejam utilizados como contexto pelo Copilot.
A alteração fecha uma parte importante da lacuna de controlo, mas não cria uma fronteira universal para código sensível. A própria documentação da GitHub continua a mostrar níveis de suporte diferentes consoante a interface, indica que os modos Edit e Agent do Copilot Chat no Visual Studio Code e noutros editores ainda não suportam a funcionalidade e descreve limitações em ligações simbólicas, sistemas de ficheiros remotos e informação fornecida indiretamente pelo ambiente de desenvolvimento. Para uma organização, este controlo deve por isso ser validado por cliente, modo de utilização e localização do repositório.
A política chega à aplicação Copilot e à linha de comandos
A exclusão de conteúdos permite aos administradores indicar os ficheiros que o Copilot deve ignorar. Segundo a documentação da GitHub, os ficheiros excluídos deixam de receber sugestões em linha, o seu conteúdo não deve alimentar sugestões noutros ficheiros nem respostas do Copilot, e esses ficheiros também não são analisados pela revisão de código do Copilot.
A atualização de 2 de setembro é relevante porque a aplicação Copilot e o Copilot CLI são pontos de entrada para fluxos de trabalho com agentes, e não apenas mecanismos de preenchimento automático. A GitHub afirma que ambos passam a aplicar regras definidas ao nível da empresa, da organização e do repositório. Assim, uma regra criada para proteger partes sensíveis de um repositório pode acompanhar alguns dos fluxos em que um agente explora o código, responde a perguntas ou executa uma tarefa a partir do terminal.
A funcionalidade está disponível nos planos Copilot Business e Copilot Enterprise. Administradores de repositórios, proprietários de organizações e responsáveis ao nível Enterprise podem configurar exclusões dentro do respetivo âmbito.
A aplicação da regra continua a depender da interface
A expressão «exclusão de conteúdos» pode sugerir um controlo uniforme em todo o Copilot. A matriz de suporte publicada pela GitHub mostra que a realidade ainda é diferente.
No site GitHub e no GitHub Mobile, a funcionalidade permanece em pré-visualização pública. A aplicação GitHub Copilot e o Copilot CLI entram agora na disponibilidade geral anunciada a 2 de setembro. Em contrapartida, a GitHub indica explicitamente que os modos Edit e Agent do Copilot Chat no Visual Studio Code e noutros editores não suportam atualmente a exclusão de conteúdos.
A distinção é importante para empresas que estão a passar de sugestões de código para agentes capazes de planear alterações, editar vários ficheiros, executar comandos e utilizar ferramentas. Uma política funcionar numa interface Copilot não significa que tenha exatamente o mesmo comportamento noutra.
Informação derivada de um ficheiro excluído pode continuar disponível
A GitHub documenta ainda uma limitação menos óbvia. O Copilot pode utilizar informação semântica relacionada com um ficheiro excluído quando essa informação é fornecida indiretamente pelo ambiente de desenvolvimento. Os exemplos apresentados incluem informação de tipos, definições mostradas ao passar o cursor sobre símbolos e propriedades gerais do projeto, como a configuração de compilação.
Isto não significa que o Copilot esteja necessariamente a ler diretamente o ficheiro excluído. Significa que o IDE pode transformar conteúdo do repositório em metadados que ficam disponíveis por outro caminho. Uma análise de segurança deve, por isso, considerar não apenas o acesso aos ficheiros, mas também a informação derivada que o ambiente de desenvolvimento expõe.
A documentação acrescenta que as exclusões não se aplicam atualmente a ligações simbólicas nem a repositórios em sistemas de ficheiros remotos. A limitação é relevante para equipas que utilizam áreas de trabalho montadas remotamente, sistemas de ficheiros de rede, ambientes de desenvolvimento remotos ou estruturas de repositório com utilização intensiva de symlinks.
A governação precisa de uma matriz de controlo, não de uma única opção
A consequência prática é que a exclusão de conteúdos deve ser tratada como um controlo dependente da interface, e não como uma garantia universal de que material sensível nunca poderá influenciar o Copilot.
Uma matriz de controlo empresarial deve registar pelo menos quatro dimensões: o cliente Copilot, o modo de interação, a localização do repositório ou sistema de ficheiros e o tipo de informação que pode atravessar a fronteira. O mesmo caminho excluído pode ter uma proteção efetiva diferente quando um programador passa da revisão de código para a CLI, da CLI para um modo com agente no IDE, ou de uma cópia local para um sistema de ficheiros remoto.
Os critérios de aprovação também devem refletir esta diferença. «A exclusão de conteúdos está ativa» é um critério insuficiente para um repositório sensível. Um critério mais robusto exige que as interfaces Copilot autorizadas para esse repositório tenham sido testadas com a política da organização e que os modos sem suporte e as exceções do sistema de ficheiros estejam documentados.
O que deve ser verificado antes de usar agentes em repositórios sensíveis
Antes de permitir agentes Copilot em repositórios que contenham segredos, algoritmos proprietários, dados regulados ou código sujeito a restrições contratuais, as equipas de plataforma e segurança devem testar o comportamento de que realmente dependem.
Devem definir os clientes e modos autorizados, testar ficheiros excluídos na aplicação e na CLI, identificar qualquer utilização dos modos Edit e Agent nos editores, rever sistemas de ficheiros remotos e ligações simbólicas e decidir se a informação semântica fornecida indiretamente pelo IDE é aceitável. A revisão de código deve ser validada em separado, porque a GitHub a documenta como uma interface suportada distinta.
Esta versão amplia de forma material a camada de controlo empresarial da GitHub. O seu principal valor não está em resolver de uma vez a governação de código sensível, mas em acrescentar mais uma interface onde a política pode ser aplicada. As limitações restantes reforçam uma conclusão arquitetural importante: os controlos de governação para agentes precisam de um âmbito explícito, e esse âmbito deve ser verificado no ambiente em que o agente é realmente utilizado.