O GitHub passou a disponibilizar de forma geral um novo nível de controlo para empresas com Copilot Business ou Copilot Enterprise. Os administradores podem definir quais as operações do agente que ficam bloqueadas, quais exigem uma aprovação humana em cada tentativa e quais podem avançar sem nova confirmação. O mecanismo está disponível na aplicação GitHub Copilot, no Copilot CLI e nas sessões do Visual Studio Code que usam Agent Host.
A alteração é mais importante do que uma nova opção de configuração. O GitHub afirma que as restrições definidas pela empresa não podem ser enfraquecidas por preferências do utilizador ou do espaço de trabalho, por aprovação automática nem por autorizações guardadas de ações anteriores. A decisão sobre parte dos poderes do agente deixa, assim, de ficar nas mãos da sessão local do programador e passa para uma política central.
A empresa pode separar comandos, ficheiros e acessos à rede
A documentação do GitHub define três tipos de decisão: bloquear, pedir aprovação e permitir sem perguntar. As regras podem abranger comandos de terminal, leitura de ficheiros, edição de ficheiros e domínios de rede. A precedência também está definida: uma proibição prevalece sobre um pedido de aprovação, e este prevalece sobre uma autorização.
Quando uma operação exige aprovação, essa decisão tem de ser tomada novamente no momento do pedido. Segundo o GitHub, o modo que dispensa confirmações, as definições de aprovação automática, mecanismos auxiliares ou uma autorização guardada de uma execução anterior não satisfazem essa exigência. Se a mesma operação for pedida mais tarde, o utilizador volta a ser consultado.
Isto permite distinguir tarefas rotineiras de ações sensíveis. Uma empresa pode autorizar um comando de testes bem definido, exigir confirmação antes de enviar código ou alterar um ficheiro protegido, e impedir por completo o acesso a determinado caminho ou destino de rede.
Menos espaço para contornar a política localmente, sem substituir o isolamento
Em junho, o GitHub já tinha introduzido uma definição empresarial que permitia impedir o modo de execução sem confirmações. Esse controlo era sobretudo binário: a organização podia evitar que o utilizador ativasse uma opção que dispensava os pedidos de autorização.
A atualização de setembro é mais fina. A empresa pode aplicar regras a operações concretas e dar-lhes prioridade sobre a configuração local.
A análise da Aipolix é que a fronteira de confiança dos agentes de programação em contexto empresarial mudou. A preferência definida no computador do programador deixa de ser a autoridade final para uma operação abrangida pela política. O ficheiro central de configuração passa a fazer parte do modelo de segurança e, por isso, deve ser versionado, revisto e testado com disciplina semelhante à aplicada a políticas de implantação, proteção de ramos ou controlo de identidades.
Ainda assim, autorização e isolamento não são a mesma coisa. O próprio GitHub documenta separadamente as permissões geridas e as regras de sandbox. Estas últimas controlam aspetos como caminhos do sistema de ficheiros, acesso à rede, credenciais, servidores MCP locais e o comportamento quando o isolamento não pode ser aplicado. A política de permissões decide se o agente pode tentar uma operação; o isolamento determina até onde o processo executado consegue realmente chegar.
Com várias fontes de política, a regra mais restritiva prevalece
A documentação também explica a combinação de várias fontes de configuração. Uma proibição presente em qualquer fonte gerida bloqueia a operação correspondente. Quando existem várias listas de ações autorizadas, a lista efetiva resulta da interseção entre elas, e não da soma. Em determinadas configurações geridas, uma operação suportada que não corresponda a nenhuma regra explícita passa a exigir aprovação por defeito.
Para organizações grandes, estes pormenores são relevantes. Uma equipa pode receber regras próprias quando a política empresarial permite explicitamente essa especialização, mas uma configuração local mais permissiva não consegue anular de forma silenciosa uma proibição central.
A centralização também introduz um risco operacional diferente. Uma proibição demasiado ampla pode bloquear muitos programadores; uma autorização demasiado aberta pode normalizar uma ação sensível em toda a equipa. Alterações a estas políticas devem, portanto, passar por revisão e deixar um histórico claro.
A aprovação humana passa a ser uma peça efetiva da governação
Num agente de programação, a questão não é apenas saber se o modelo consegue executar um comando ou alterar um ficheiro. Importa perceber quem autoriza a ação, durante quanto tempo vale essa decisão e se o utilizador pode escolher outro caminho para a evitar.
O novo comportamento de aprovação pontual é útil para operações com consequências relevantes. Uma autorização dada ontem para enviar código não deve transformar-se, sem intenção, numa permissão permanente para hoje.
Também não faz sentido pedir confirmação para tudo. Uma sucessão de pedidos pode levar à aprovação automática por hábito. Uma política equilibrada reserva o bloqueio para ações que o agente não deve realizar, exige aprovação quando o contexto é importante e permite diretamente apenas um conjunto limitado de operações repetitivas e de baixo risco.
Uma adoção segura precisa de autorização e isolamento
As novas permissões tornam o controlo empresarial do Copilot mais vinculativo, mas não são, por si só, uma fronteira de segurança completa. Devem ser usadas em conjunto com um ambiente isolado (sandbox), as proteções dos repositórios e dos ramos, a gestão de segredos, as restrições de rede e a auditoria das próprias alterações de política.
O teste prático é simples: um programador não deve conseguir obter uma operação que a empresa quis proteger apenas alterando uma preferência local, ativando aprovação automática, reutilizando uma autorização antiga ou mudando para outro cliente abrangido. Para operações suportadas nas superfícies baseadas em Agent Host, o GitHub fecha explicitamente várias dessas vias.
É esta a mudança central: a configuração empresarial do Copilot aproxima-se de uma camada de autorização, em vez de funcionar apenas como um conjunto de preferências. Quanto maior for a autonomia concedida aos agentes de programação, mais importante é manter essa camada independente das decisões do próprio agente e das opções de conveniência do utilizador.