Política de segurança que não chega ao agente de código não é controle. O Copilot agora pode falhar fechado

Um administrador aperta as regras do agente de código do Copilot na segunda de manhã: sandbox ligado, uma configuração arriscada desligada. Na segunda à tarde, um desenvolvedor abre um notebook que passou o fim de semana offline. Sob qual política o agente roda?

Até agora, muitas vezes a antiga. Os clientes do Copilot guardam as managed settings em cache, o que deixa a inicialização rápida e mantém o desenvolvedor trabalhando durante uma queda breve do serviço. Também significa que uma mudança de política só chega a cada máquina quando ela atualiza da próxima vez. Para o autocomplete, a diferença quase não importava. Para um agente que roda comandos, edita arquivos e chama ferramentas, é a distância entre a política que o administrador acredita estar valendo e a que de fato é aplicada.

O que o GitHub lançou

Em 13 de outubro, o GitHub adicionou dois controles de aplicação às configurações gerenciadas do Copilot.

Atualização forçada ao iniciar. Definir forceRemoteSettingsRefresh como true, por configuração gerenciada no servidor, por MDM ou por arquivo, obriga os clientes compatíveis a buscar as configurações atuais do servidor ao iniciar, em vez de confiar no cache. “Se o cliente não consegue confirmar a política atual, ele falha fechado em vez de rodar com uma política velha ou não confirmada.” Os clientes compatíveis são o Copilot CLI, o VS Code e o app GitHub Copilot. Um pré-requisito: para valores gerenciados no servidor, a atualização forçada vale nas inicializações seguintes só depois que o cliente recebeu a configuração uma vez. A entrega por MDM ou por arquivo pode exigir uma busca nova antes do primeiro login.

Versão mínima do cliente para o sandbox. Quando a chave sandbox está nas managed settings, quem fixou versões antigas do cliente “agora será obrigado a atualizar para voltar a usar o Copilot”. O sandbox em si é um recurso local em disponibilidade geral (GA); o GitHub diz que a exigência de versão mínima vai chegar a outras chaves de governança com o tempo. Por enquanto, vale só para a chave sandbox.

Falhar fechado é uma decisão, não um padrão

Falhar fechado é o comportamento certo para um controle de segurança. É também uma escolha com custo: se o cliente não alcança o serviço de política, por um problema de rede, um proxy que bloqueia a chamada ou uma indisponibilidade, o desenvolvedor não usa o Copilot até que ele alcance. O GitHub mantém o cache como padrão por isso.

A decisão deve ser tomada por grupo de usuários, não para a empresa inteira:

• Falhe fechado onde o agente alcança código sensível, credenciais de produção ou dados regulados, e onde uma política não confirmada é pior do que uma hora sem assistente.
• Mantenha o cache onde os desenvolvedores trabalham offline com frequência e as ações permitidas ao agente já são estreitas.
• Planeje a primeira entrega. Como a primeira entrega das configurações gerenciadas no servidor precisa dar certo antes de a aplicação começar, uma máquina nova fica brevemente sob o que tinha antes. A entrega por MDM ou por arquivo fecha essa janela.

A lição geral para governança de agentes

Os controles dos agentes de código vivem cada vez mais no cliente: quais modelos são permitidos, se o sandbox está ligado, quais servidores MCP podem subir. Observamos numa atualização recente que um modelo padrão no Copilot não é uma política. Este lançamento responde à pergunta seguinte: se a política que é política de fato chegou.

Todo controle aplicado num endpoint tem três modos de falha: a política está errada, a política está velha ou o cliente é velho demais para entendê-la. Consoles centrais mostram o primeiro. Este lançamento permite fechar o segundo e começa a fechar o terceiro. As mesmas perguntas valem para todo agente que roda em máquinas de desenvolvedores, de qualquer fornecedor:

1. Por quanto tempo um cliente pode rodar com uma política em cache?
2. O que ele faz quando não consegue confirmar a atual?
3. Um cliente antigo pode ignorar uma configuração que não reconhece?

Se as respostas forem “indefinidamente”, “continua rodando” e “sim”, as políticas do console descrevem intenções, não aplicação. O argumento de contenção que fizemos em fronteiras do agente fora do modelo só se sustenta se a configuração da fronteira chegar à máquina que ela deveria proteger.