GitHub Copilot agora atribui atividade ao usuário na telemetria OpenTelemetry sem capturar prompts

Fala aí, beleza? Agora as empresas conseguem saber QUEM usou o Copilot sem precisar ler o que a pessoa escreveu 😀

Em 12/10/2026 o GitHub publicou no changelog o anúncio Client telemetry user attribution and configurable capture, e ele mexe direto na telemetria do Copilot

O recurso é voltado a administradores enterprise e funciona pelos managed settings: dá pra atribuir a atividade do Copilot a um usuário sem coletar prompts, respostas ou conteúdo de ferramentas

E junto vieram controles finos pra decidir, classe por classe, o que é capturado…

O que é a configuração telemetry.capture.identity do Copilot

A telemetry.capture.identity é a chave que liga a identidade do usuário nos dados OpenTelemetry (OTel)

Que OpenTelemetry? É o formato que o Copilot usa pra exportar dados de uso pra um coletor escolhido pela empresa, configurado pela propriedade telemetry dos managed settings

Quando ligada, ela adiciona 3 atributos a esses dados:

• user.name: o nome da conta Copilot autenticada, que hoje é o login do GitHub
• process.user.name: a conta do sistema operacional local
• host.name: o nome da máquina local

O pulo do gato tá aqui: a identidade entra SEM o conteúdo

Você fica sabendo que a atividade veio do login X, na conta local Y, na máquina Z, mas sem coletar prompts, respostas ou o que as ferramentas fizeram

E dois detalhes importantes:

• A captura de identidade vem desligada por padrão
• Ela é separada do identificador pseudônimo que já existia, ou seja, não é apresentada como substituta dele: é uma camada à parte que o admin decide ligar

As cinco classes de captura que o admin pode ligar e desligar

Além da identidade, o admin agora controla de forma independente cinco classes de conteúdo:

• prompts: prompts de usuário, de sistema e de desenvolvedor, além do contexto de entrada suportado
• responses: respostas do assistente e conteúdo de raciocínio suportado
• toolArguments: argumentos brutos de ferramentas, comandos, schemas de ferramentas e identificadores de ferramentas, servidores MCP, plugins e hooks
• toolOutput: resultados de ferramentas e detalhes de erros de execução
• policyDetail: detalhes brutos de política, como caminhos de sistema de arquivos do sandbox

Todas vêm desligadas por padrão

Então nada é capturado até alguém ligar explicitamente, classe por classe 🙂

Em quais clientes os controles finos funcionam?

O anúncio cita três lugares onde as cinco classes de captura são aplicadas de forma independente:

• Copilot CLI
• GitHub Copilot app
• Sessões do VS Code usando Agent Host

Se você acompanha as novidades do Copilot CLI e app por aqui, são justamente esses clientes que entram na jogada

Quem manda na configuração: precedência e o captureContent legado

Aqui tem uma regra simples e que evita muita dor de cabeça

Valor gerenciado explícito vence tudo: ele prevalece sobre configurações locais, configuração do SDK e variáveis de ambiente

Ou seja, quando o admin define um valor explícito nos managed settings, configuração local, do SDK ou variável de ambiente não sobrepõe esse valor

E o captureContent antigo?

Continua existindo, mas agora como atalho legado

O captureContent liga as cinco classes de conteúdo de uma vez, só que nunca liga a identidade

Tome cuidado! Se a ideia é atribuir atividade a pessoas, ligar captureContent achando que a identidade vem junto não resolve: a telemetry.capture.identity precisa ser definida à parte

E o contrário também vale: captureContent liga conteúdo, que é exatamente a parte sensível. Se você só quer saber quem usou, ele faz MAIS do que você precisa

Subpropriedades documentadas de telemetry

Pra referência, o exemplo oficial da referência de enterprise managed settings traz estas subpropriedades de telemetry:

• enabled
• endpoint: URL do coletor OTLP
• protocol: no exemplo oficial aparece http/protobuf
• capture: objeto com identity, prompts, responses, toolArguments, toolOutput, policyDetail
• captureContent
• lockCaptureContent
• serviceName
• resourceAttributes
• headers

Como isso se encaixa no suporte a OpenTelemetry que o Copilot já tinha

Essa novidade não caiu do céu, ela é mais um degrau numa sequência que o GitHub vem montando:

O primeiro passo foi o anúncio da exportação OpenTelemetry gerenciada pra VS Code e CLI, e agora chega o controle de QUEM e do QUE

Segundo a documentação de OpenTelemetry do Copilot, com essa exportação a empresa consegue:

• Analisar sessões de agentes, com traces que mostram o fluxo da sessão, incluindo chamadas ao modelo e uso de ferramentas
• Impor a configuração de telemetria de forma centralizada, via managed settings, nos clientes suportados

O que faltava era ligar essas sessões a uma pessoa sem abrir o conteúdo, e é isso que fecha agora

O que muda para quem administra ou audita agentes de IA na empresa

O impacto é bem diferente dependendo de onde você senta, então bora separar

Admin enterprise

Passa a ter atribuição por pessoa (login, conta local e máquina) e controle granular de cinco classes de conteúdo

E o valor definido nos managed settings fica acima do que estiver configurado localmente, no SDK ou em variável de ambiente

Time de segurança e compliance

Dá pra auditar agentes sabendo quem fez o quê, sem precisar coletar prompts, respostas ou conteúdo de ferramentas

Isso é MUITO mais fácil de justificar internamente do que guardar tudo que o dev digitou 😛

Desenvolvedor

Se o admin não ligar nada, nada muda: identidade e todas as classes vêm desligadas

Se o admin ligar, o valor gerenciado vale sobre a sua configuração local, então não adianta mexer no ambiente pra contornar

Limitações e o alerta de privacidade do GitHub

O próprio GitHub faz um alerta que vale ler com calma

Captura de prompts, ferramentas e política pode incluir:

• Código-fonte
• Conteúdo de arquivos
• Comandos
• Resultados de ferramentas
• Caminhos de workspace ou de perfil de usuário

A recomendação oficial é habilitar só as classes necessárias pro caso de auditoria e enviar os dados a um endpoint de coleta aprovado

Traduzindo: ligar tudo porque sim é jogar código da empresa num coletor que talvez nem devesse receber isso…

Tem também limitação de escopo:

• O recurso é voltado a administradores enterprise
• As cinco classes de captura independentes foram citadas só pra Copilot CLI, GitHub Copilot app e VS Code com Agent Host

No VS Code fora do Agent Host (o harness de agente local), a identidade (telemetry.capture.identity) e o captureContent legado funcionam normalmente: só as cinco classes de captura independentes não são aplicadas separadamente ali

Já quem administra o Copilot para JetBrains ou outro IDE não deve assumir que esses controles existem lá: a documentação consultada não confirma suporte às classes nem à identidade nesses clientes

Próximo passo para ativar a atribuição no Copilot

Recapitulando: a telemetria do Copilot agora consegue dizer quem usou sem dizer o que foi escrito, e o admin escolhe classe por classe o que entra

Se tu administra o Copilot na empresa, o caminho mais seguro fica assim:

1. Se o objetivo é só saber quem usou, comece pela telemetry.capture.identity e deixe as classes de conteúdo desligadas
2. Avalie classe por classe antes de ligar qualquer captura de conteúdo, lembrando que captureContent liga as cinco de uma vez (e mesmo assim não liga a identidade)
3. Confirme que o endpoint (a URL do coletor OTLP) aponta pra um coletor aprovado pela empresa
4. Consulte a referência de enterprise managed settings e o guia de monitoramento de agentes com OpenTelemetry do GitHub pra ver a sintaxe exata antes de mexer no arquivo

Auditoria de agente com o mínimo de dado possível, massa demais 🙂

Até o próximo post!